Solutions for Insufficient Disk Space Issue of Frequency Response Analysis
Issue Description:
If a Frequency Response Analysis takes too long time to finish, or if it crashes and complains about insufficient disk space, or it gives warning as below. Then it’s time to review the output request commands, as suggested in the statements following the warning.
*** WARNING # 1970
Current run may fail due to insufficient disk space.
Estimated disk space requirement = 2,284,147 MB
Estimated disk space available = 1,792,255 MB
Suggestions to reduce disk space requirements:
- For static analysis - reduce the number of loadcases.
- For eigenvalue/buckling analysis - reduce frequency range in EIGRL card or number of modes requested.
- For FRF analysis - reduce the number of loading frequencies.
- For transient analysis - reduce the number of output time steps.
Observation:
Review the example definition below for MFREQ analysis, to see if there is anything we can improve.
- DISPLACEMENT(PUNCH,PHASE) = ALL
- DISPLACEMENT(H3D,PHASE,ROTA) = ALL
- ELFORCE(H3D)=ALL
- ESE(H3D)=ALL
- STRESS(H3D)=ALL
- FREQ1 32 1.0 1.0 199
The below is my observation:
- Rotational displacement results are output, which is not necessary in most scenario.
- Requesting response of many types for ALL nodes/elements at all 200 loading frequencies.
- Duplicated output of DISPLACEMENT for PUNCH and H3D formats.
Basically, it’s not created in good practice because it’s challenging the computational resource.
If a static analysis generates 100 MB results file, the above definition of same model might generate 200 GB results file.
These output request commands might be carried over from static analysis or preloading non-linear analysis where it should be fine. However, in a Dynamic Analysis, requesting response of many types for all nodes/elements at hundreds of loading frequencies(or time steps in a transient analysis) leads to huge disk space requirement and even failure of analysis.
Some Solutions:
- RTOP: Request only the top #% stress/ESE values be output.
- PEAKOUT: Define criteria used for the automatic identification of loading frequencies at which result peaks occur. Only the results at these frequencies are output.
- FREQi:
- Use FREQ to request output for all nodes/elements at only a smaller set of frequencies of interest.
- Combine different types of FREQi cards, e.g., a coarse FREQ1 card + a tight FREQ4 around peaks. In this way, all FREQi entries with the same set identification number can be used. Duplicate frequencies will be ignored.
- SET: Request output for a set of nodes/elements.
- NOROTA: Rotational displacement results are not output-it’s fine for most use cases.
Using a demo vehicle model, a comparison was carried out to demonstrate how the above solutions reduce computational time, disk space usage and output file size. Results are show in the table below.
| OUTPUT & FREQ | ELAPSED TIME/MINUTE | MAXIMUM DISK SPACE USED/MB | OUTPUT FILE SIZE/MB |
RUN 01 Baseline | DISPLACEMENT(PUNCH,PHASE) = ALL | 36 | 23,500 | 22,000 |
RUN 02 | DISPLACEMENT(H3D,PHASE,NOROTA) = ALL | 7 | 11,746 | 746 |
RUN 03 | DISPLACEMENT(H3D,PHASE,NOROTA, | 4 | 9,714 | 42 |
RUN 04 | DISPLACEMENT(H3D,PHASE,NOROTA) = ALL | 1 | 1,532 | 42 |
RUN 05 | DISPLACEMENT(H3D,PHASE,NOROTA) = 1 FREQ1 32 1.0 1.0 199 | 1 | 1,515 | 1 |
Model Information:
Total # of Grids (Structural) : 18524
Total # of Grids (Acoustic) : 59247
Total # of Elements : 82889
Machine Information:
16 CPU, 32 GB RAM
Further Reading on Computational Efficiency:
Direct Matrix Input (Superelements) (altair.com)