COMB_SISM_MODAL and memory consumption

Cherblanc

While carrying out a spectral analysis (ASSEMBLAGE + CALC_MODES + COMB_SISM_MODAL), the highest memory use is observed with the COMB_SISM_MODAL operator. From my mind, the most complicated part is the calculation of modes and the combination of modes should be relatively straigthforward.
I my case, the memory use is given below and I am limited by the combination of modes and not by their calculation, which is quite annoying.

Résultat commande #0031 (CALC_MODES): modes ('<00000057>') de type <ModeResult>
Mémoire (Mo) : 21974.50 / 3452.69 / 6987.43 / 2344.53 (VmPeak / VmSize / Optimum / Minimum)
Fin commande #0031 user+syst: 4296.10s (syst: 2331.09s, elaps: 709.73s)

Résultat commande #0047 (COMB_SISM_MODAL): combin ('<0000005a>') de type <MultipleElasticResult>
Mémoire (Mo) : 60756.68 / 13077.04 / 17700.41 / 8811.20 (VmPeak / VmSize / Optimum / Minimum)
Fin commande #0047 user+syst: 151.79s (syst: 66.25s, elaps: 217.96s)

I use Code_Aster 16.7.0 through the singularity container (salome_meca-lgpl-2024.1.0-1-20240327-scibian-11.sif).
Is it a normal behavior ?
I am not sure it was the case in previous version of Code_Aster, 14.6 for instance.

Thanks for your help

Sound_Spinning

Cherblanc
How many nodes do you have in your model?

Your modal is already using 22GB RAM, how many modes? Then in a dyn forced response if all is in memory then it matters how many time/freq points you need to keep to the 'easy solve' part results. I've seen the same on any type of linear dyns response.
You could try splitting the forced response into 2 runs? Or less solution points?

Cherblanc

My model has 747739 nodes and 404011 TETRA10. It's maybe high but MEF calculation goes well.
I do not carry out a dynamical calculation, it is just a combination of modes using an acceleration spectrum. So there is no time step.
I could effectively lower the mesh size, but I did not observe similar behavior in previous version of Code_Aster. My limitations was the memory cost of modal computation, not the combination of modes. That's why I am asking if something has changed in the COMB_SISM_MODAL operator.
Thank you for your help

nicolas_p

Cherblanc

The problem is known. A correction is expected for salome_meca2025

Note that COMB_SISM_MODAL has been fully rewritten in v16 and a bug has been introduce

Cherblanc

Hi,
Thank you for your post, it makes me confident for the future.
When salome_meca2025 will be available ?

nicolas_p

Cherblanc

version 17.4 and 16.8 are scheduled for December 2025 and smeca2025 in January/February 2026