Simulation data management mobile app fails to sync large simulation files

PLM ENOVIA
, , , , , , , ,
1

We’re running ENOVIA 3DEXPERIENCE R2020x with the mobile app for simulation review. Our engineers in the field are experiencing consistent failures when trying to sync large simulation result files (typically 150-300 MB) back to the server.

The upload process starts normally but fails around 60-70% completion with a generic “sync failed” error. Smaller files under 50 MB sync without issues. We’ve noticed the failures happen more frequently on cellular connections versus WiFi.

I’m particularly concerned about:

  • Whether the mobile app supports chunked or resumable uploads for large files
  • If there are server-side timeout configurations we need to adjust
  • How to improve upload reliability for our remote simulation teams

Has anyone successfully configured ENOVIA mobile for large simulation data synchronization? What settings or approaches worked for your deployment?

system 2

We ran into this exact issue last year with our mobile simulation workflow. The problem isn’t just timeouts - it’s the combination of network reliability, server configuration, and the mobile app’s upload implementation in R2020x.

Here’s what we implemented to solve large file upload reliability:

Server Timeout Configuration: Increase these parameters in your 3DSpace configuration:


wt.httpgw.timeout=900000
wt.method.server.timeout=900000
com.matrixone.servlet.timeout=900000

Also configure your web server (Apache/IIS) timeout to at least 15 minutes for upload endpoints.

Chunked Upload Support: R2020x mobile doesn’t natively support resumable uploads, but you can implement it via custom REST service:


// Pseudocode - Chunked upload implementation:
1. Client splits file into 10MB chunks with metadata
2. POST each chunk to /resources/v1/modeler/documents/files/chunks
3. Include headers: X-Chunk-Number, X-Total-Chunks, X-Upload-ID
4. Server stores chunks in temp location with upload session ID
5. Final POST assembles chunks into complete file
6. Server validates checksum and creates document object
// Requires custom MQL service - see ENOVIA Customization Guide 8.3

Mobile App Configuration: Modify the mobile app’s config file (iOS: config.plist, Android: config.xml) to increase client-side timeout:

  • Set network timeout to 600 seconds minimum
  • Enable retry logic with exponential backoff
  • Configure chunk size if using custom implementation

Network Optimization: For cellular connections:

  • Implement upload queue with WiFi preference
  • Add pre-upload file size warning (>100 MB)
  • Enable background upload capability so app switching doesn’t cancel transfer
  • Use compression for simulation result files (as mentioned by sim_data_specialist)

Monitoring and Diagnostics: Add logging to track upload progress:

  • Client-side: Log chunk completion percentage
  • Server-side: Monitor temp file assembly and cleanup
  • Alert on repeated failures for specific users/files

We also upgraded to R2022x six months later which includes native support for resumable uploads via the tus.io protocol. If you’re planning upgrades, that’s the cleanest long-term solution. For R2020x, the chunked upload approach with increased timeouts solved our reliability issues - we went from 40% failure rate to under 5% for files up to 500 MB.

The key is addressing all three aspects: server timeout configuration for reliability, chunked upload support for large files, and proper mobile app settings for network resilience. Test thoroughly on cellular networks since that’s where most failures occur.

This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen similar issues with large file uploads in R2020x mobile. The default configuration isn’t optimized for files over 100 MB. Check your server’s HTTP timeout settings first - they’re usually set too conservatively. Also verify your load balancer timeout if you’re using one. The mobile app does have retry logic but it’s not true resumable upload in that release.

4

What’s the exact error message in the mobile app logs? On Android you can pull logs via ADB, iOS requires debug build. Also check the 3DSpace server logs around the time of failure - look for timeout exceptions or memory issues. The 60-70% failure point suggests either a fixed timeout being hit or network interruption on cellular. We had to increase several timeout parameters in our deployment.

5

The R2020x mobile app uses standard HTTP POST for uploads without native chunking support. For large simulation files, we implemented a workaround using the REST API with custom chunking on the client side. You’ll need to modify the mobile app’s upload handler to split files into smaller segments (we used 10 MB chunks) and reassemble server-side. This requires custom development but dramatically improved reliability for our simulation workflows. The alternative is upgrading to R2022x or later which has better large file handling built-in.

torres_func2 6

“Tested this on R2020x with Apache timeout set to 900 seconds alongside the wt.httpgw.timeout parameter, and large simulation file syncing finally completed without dropping.”

7

Check your reverse proxy and application server timeouts. We had Apache timeout set to 60 seconds which caused identical symptoms. Increased to 600 seconds for large file endpoints. Also verify mobile app’s request timeout configuration and ensure your cellular network allows sustained connections. Some carriers throttle or disconnect long-running uploads.

8

Have you considered compressing the simulation results before upload? Many FEA output formats compress well - we achieved 60-70% size reduction on our NASTRAN and ABAQUS results using standard ZIP compression. This brought most files under the 100 MB threshold where mobile sync works reliably. Not a perfect solution but it’s operationally simpler than implementing custom chunking. You can automate compression in your simulation post-processing scripts.

ashley_dass 9

The 60-70% failure point suggests either a fixed timeout being hit or network interruption on cellular.