The run fails with a segmentaiton error in the dynamic analysis step. I can’t see anything obvioulsy wrong in the input, but maybe I am missing something?

Note:

I am able to run the other modal dynamic examples without errors (beamdy1, beamdy2, beamdy3, beamdy4, beamdy5, beamdy6, beamdy17).

I set CCX_LOG_ALLOC=1 , but must admit not sure what to do with the output.

Any ideas as to the cause of the error would be very much appreciated, as well as solutions / work arounds. Thanks.

Indeed, you are right, the shell elements are probably causing the error here (as I am able to run the solid element “beamdy” examples without difficulty)… But the geometry that I am meshing is 2D and so I do not want to transition to 3D elements from the start.

The manual (section 6.9.5 Modal dynamic analysis) seems to imply that *MODAL DYNAMIC should work with shell elements - and that is exactly the use-case I am trying to solve here. So to me this looks like a bug.

To investigate this further, I ran a straight forward *DYNAMIC analysis of the “shellf.inp” test example, with the following step definition:

*STEP,NLGEOM=NO
*DYNAMIC,DIRECT
1.E-5,1.E-4
*CLOAD,AMPLITUDE=A1
15,3,1.E-6
*NODE PRINT,NSET=N15
U
*END STEP

This worked without problem and generates sensible data.

I noticed an interesting difference in the .12d output files between this run and the modal dynamic analysis:

the *MODAL DYNAMIC analysis generates mean rotation MPCs at the SPC’d and loaded nodes

the *DYNAMIC analysis generates knots at the SPC locations only

Questions:

Is there a way to force knot generation rather than MPCs? Assuming this might solve the problem.

As an alternative workaround, is there a fast way of generating and saving an expanded shell model for further analysis? That way, I could run the frequency analysis directly on the 3D model to feed the dynamic modal analysis.

@OliviaS I don’t think there is a fast way to do number 2. I’ve experienced similar issues in the past and what I end up doing is expanding them manually and applying proper boundary conditions.

Thanks @jbr and @dichtstoff for the comments on option 2). I might try to do this manually for a specific model of interest, but since the cgx/ccx analysis I would like to use is part of a parametric loop where geometry and mesh change, I might give automating this a go aswell at some point and maybe share the code with the community (since other people might run into simmilar problems with shells).

In the meantime, I hope this bug might get resolved in future releases… Would be happy to contribute or test again in the future - please get in touch.