Large modal analysis of a shell diaphragm – mesh size vs number of requested modes

Analysis issues
1

I am performing a modal analysis in CalculiX of a loudspeaker diaphragm modeled as a single shell using PrePoMaX as front end.

Model characteristics:

  • Circular diaphragm, diameter: 75 mm
  • Shell model
  • Approximately 5306 shell elements
  • Number of equations: 70771
  • 3 DOF per node (U1, U2, U3)
  • Solver: Pardiso
  • 8 CPU cores

The first eigenfrequency is approximately 320 Hz.

My goal is to obtain all acoustically relevant modes up to about 10 kHz. Since many of the extracted modes are dominated by in-plane motion (U1/U2), while I am mainly interested in out-of-plane motion (U3), I need to extract a large number of modes and later filter them based on U3 participation.

With 1044 extracted modes, the highest frequency obtained is approximately 6637 Hz.
That analysis took 42 minutes.

I am currently running a solution with 2000 requested modes, but it is still running after 12 hours.

My question is:

For a model of this size (70771 equations), what is typically the limiting factor in CalculiX eigenvalue analyses?

  1. The mesh density / number of equations?
  2. The number of requested eigenmodes?
  3. Memory consumption in ARPACK/Pardiso?

Would it generally be more efficient to:

  • keep the current mesh and request more modes,
    or
  • refine the mesh and request fewer modes?

I am particularly interested in practical experience from users who have run modal analyses with 1000–3000 extracted modes.

Any advice on estimating the number of modes required to reliably cover a target frequency range would also be appreciated.

2

There is a similar example here: https://www.youtube.com/watch?v=oBaDbQPh6Tk

It would be good to mesh it in a structured/transfinite way with quads and perform a mesh convergence study to find the influence of the mesh size on the frequencies (as shown in the aforementioned video). Then you can use a minimum required mesh density and increase the number of modes. The bottleneck here must be the number of modes.

Ideally, you should split the extraction into separate frequency regions (steps).

3

Thank-, Calc_em!

I didn’t catch how you get the “reduced integration”; can you elaborate on that?

Yes, I suspected that. My problem is that most of the modes are not interesting, as they mainly involve U1 and U2. So out of 1000 modes, I only have about 15 that have any significant U3 movement.
I have a Python script that can crunch the dat-file and only output those modes.
But with 1000 modes I only get to about 6600 Hz and I want at least 10000 Hz.

Well, the frequency for the first eigenmode must be at the least the lower bound; otherwise, I get indexing faults.

4

Reduced integration elements have less integration points (where stress and strain is calculated). They are more computationally efficient and not prone to shear or volumetric locking, but they are also less accurate and have to be used carefully, with sufficiently refined meshes.

Their names just include “R” at the end (e.g. S4R instead of S4R). In PrePoMax, they can be selected when editing parts in the FE Model tab.

Unfortunately, there are no settings to limit the extraction to specific modes. All or a given number in the specified range will be extracted.

This seems to be a bug. In Abaqus, you can split such analysis into multiple steps with different frequency ranges.

Can you share your .inp (and maybe .pmx) file for some testing ?

5

I succeeded with 1.5 mm mesh and 1600 modes but only got to 8190 Hz for mode 1600.
The analysis took 50 minutes.

If I have a coarser mesh the result is not reliable, and later stages in my simulation require at least 1.5 mm.

So now I’m trying 1800 modes.
pmx- and inp-files here for that analysis.

6

Actually, 1800 modes worked as well. Probably because I followed your advice and went for a quad mesh.
But still not 10000 Hz. Now trying 2000 modes.

7

I succeeded with a 1.0 quad mesh, and 2423 modes brought me up to 10 kHz.

I got 23 dominant U3 modes:


DAT Cruncher v3.3

Input file : Tweeter-PEN 1.0 2500.dat
Cutoff     : 40.0 dB
Min sep    : 20.0 Hz

Mode         Freq(Hz)    dF(Hz)   ddF(Hz)   Rel(dB) Members
--------------------------------------------------------------------------
     1         320         -         -       0.0   1
     9         735     414.6         -      -7.2   9
    25        1152     417.0      +2.5     -11.1   25
    51        1569     417.6      +0.6     -13.8   51
    84        1987     417.8      +0.2     -15.9   84
   127        2405     418.0      +0.1     -17.5   127
   182        2823     418.1      +0.1     -18.9   182
   240        3241     418.2      +0.1     -20.1   240
   307        3660     418.3      +0.2     -21.2   307
   386        4078     418.5      +0.2     -22.1   386
   475        4497     418.8      +0.3     -22.9   475
   567        4916     419.1      +0.3     -23.7   567
   674        5336     419.6      +0.5     -24.4   674
   787        5756     420.2      +0.6     -25.1   787
   918        6177     420.8      +0.6     -25.7   918
  1044        6598     421.5      +0.8     -26.3   1044
  1182        7021     422.6      +1.1     -26.8   1182
  1334        7444     423.4      +0.8     -28.1   1334,1336
  1489        7869     425.3      +1.9     -28.0   1489
  1661        8296     426.3      +1.0     -28.4   1661
  1841        8725     429.1      +2.8     -29.2   1841
  2027        9156     431.2      +2.1     -29.8   2026,2027
  2222        9589     433.2      +2.0     -30.1   2222

Modes found    : 2423
Modes selected : 23
1 Like
8

One issue remains, though.

Why can’t the CalculiX analysis start at higher frequencies than the first modes’?

9

CalculiX makes use of the eigenvalue solver ARPACK to compute the frequencies.
The method that is being used works iteratively, starting from the lowest frequency. Computing the next higher frequency requires all the previous ones. Since the first few frequencies are usually the ones people are most interested in, this is fine in most of the cases.

If you request frequencies in a specific range in CalculiX, this will only affect the output. CalculiX simply computes the number of frequencies requested and filters between the specified ranges. If the requested number is too low, it can happen that no frequencies end up in the .dat file (since none in the specified range have been found / the requested number was too low).

There is no simple way to compute a frequency range in ARPACK. Though it provides a method to compute eigenvalues around a point somewhere in the spectrum (shift invert mode), it is not implemented in CalculiX and at least to my knowledge not straightforward to do.

10

Ok, then I know.

If I do have a frequency range that doesn’t include the low end of the eigenvalues, an index fault occurs that PrepoMaX cannot handle, and the analysis stops.

As I need more than 2000 modes to get to the highest 2HD frequency of the tweeter, computation takes very long once I add the SSD steps—practically forever.

1 Like
11

Is this an issue in CalculiX or PrePoMaX? Could you provide some more details please.

1 Like
12

It seems that when there’s no eigenvalue found at all in a frequency range, I get this when I try to show the result:

MWSnap158 2026-06-06, 11_02_15
MWSnap158 2026-06-06, 11_02_15468×188 10.9 KB

The dat-file is then empty (Eigenvalues part) apart from the headers. Which it should, I presume.

                    S T E P       2


 E I G E N V A L U E   O U T P U T

MODE NO    EIGENVALUE                       FREQUENCY
REAL PART            IMAGINARY PART
(RAD/TIME)      (CYCLES/TIME     (RAD/TIME)

 P A R T I C I P A T I O N   F A C T O R S

MODE NO. X-COMPONENT Y-COMPONENT Z-COMPONENT X-ROTATION Y-ROTATION Z-ROTATION

  1   0.2407944E-08  -0.8953614E-09  -0.4646718E-03   0.1745686E-04   0.1135426E-04   0.5207383E-07
  2   0.1264255E-05   0.7486552E-08   0.9240755E-06   0.1683276E-05   0.7039507E-02  -0.1116990E-06

The output window says:
06/06/26 11:36:07
06/06/26 11:36:07 *** Warning ***
06/06/26 11:36:07
06/06/26 11:36:07 Index was outside the bounds of the array.

So it is probably PrePoMax that doesn’t handle this with a proper warning.

If I ensure that there is at least one eigenvalue within the frequency range, the eigenvalues are found in the dat-file:


                        S T E P       2


     E I G E N V A L U E   O U T P U T

 MODE NO    EIGENVALUE                       FREQUENCY   
                                     REAL PART            IMAGINARY PART
                           (RAD/TIME)      (CYCLES/TIME     (RAD/TIME)

     10   0.2723373E+08   0.5218595E+04   0.8305651E+03   0.0000000E+00

So, I must know what I’m looking for in order to be able to use frequency ranges.

Here’s another analysis:

MWSnap159 2026-06-06, 13_08_37
MWSnap159 2026-06-06, 13_08_37355×554 25.8 KB

With this dat-file:


                        S T E P       2


     E I G E N V A L U E   O U T P U T

 MODE NO    EIGENVALUE                       FREQUENCY   
                                     REAL PART            IMAGINARY PART
                           (RAD/TIME)      (CYCLES/TIME     (RAD/TIME)

    175   0.6326464E+09   0.2515246E+05   0.4003139E+04   0.0000000E+00
    176   0.6383528E+09   0.2526564E+05   0.4021152E+04   0.0000000E+00
    177   0.6398923E+09   0.2529609E+05   0.4025998E+04   0.0000000E+00
    178   0.6404985E+09   0.2530807E+05   0.4027905E+04   0.0000000E+00
    179   0.6428975E+09   0.2535542E+05   0.4035441E+04   0.0000000E+00
    180   0.6580691E+09   0.2565286E+05   0.4082779E+04   0.0000000E+00
    181   0.6658442E+09   0.2580396E+05   0.4106827E+04   0.0000000E+00
    182   0.6676501E+09   0.2583893E+05   0.4112393E+04   0.0000000E+00
    183   0.6696349E+09   0.2587731E+05   0.4118501E+04   0.0000000E+00
    184   0.6727069E+09   0.2593659E+05   0.4127937E+04   0.0000000E+00
    185   0.6801569E+09   0.2607982E+05   0.4150732E+04   0.0000000E+00
    186   0.6889005E+09   0.2624691E+05   0.4177326E+04   0.0000000E+00
    187   0.6897687E+09   0.2626345E+05   0.4179958E+04   0.0000000E+00
    188   0.6927954E+09   0.2632101E+05   0.4189118E+04   0.0000000E+00
    189   0.6947377E+09   0.2635788E+05   0.4194987E+04   0.0000000E+00
    190   0.6965404E+09   0.2639205E+05   0.4200426E+04   0.0000000E+00
    191   0.6972277E+09   0.2640507E+05   0.4202497E+04   0.0000000E+00
    192   0.7000988E+09   0.2645938E+05   0.4211141E+04   0.0000000E+00
    193   0.7001447E+09   0.2646025E+05   0.4211279E+04   0.0000000E+00
    194   0.7008288E+09   0.2647317E+05   0.4213336E+04   0.0000000E+00
    195   0.7017812E+09   0.2649115E+05   0.4216198E+04   0.0000000E+00
    196   0.7019004E+09   0.2649340E+05   0.4216556E+04   0.0000000E+00
    197   0.7025241E+09   0.2650517E+05   0.4218429E+04   0.0000000E+00
    198   0.7043211E+09   0.2653905E+05   0.4223821E+04   0.0000000E+00
    199   0.7065546E+09   0.2658110E+05   0.4230513E+04   0.0000000E+00
    200   0.7109695E+09   0.2666401E+05   0.4243709E+04   0.0000000E+00

     P A R T I C I P A T I O N   F A C T O R S
13

Ok, thanks for following up! Yes, in order to use the frequency ranges, you have to know what you’re looking for (but again, it only affects the .dat / .frd output). In Abaqus, it looks like you can specify a shift to target a specific eigenvalue - we’ll have to check if something like this can be implemented in a meaningful way in CalculiX, too.

What you already observed: the modal basis in the .eig file will always include the number of requested modes in *FREQUENCY. So specifying a frequency range will not lead to a reduced basis in a subsequent SSD step.

1 Like