I am using the ccx_2.19 pre-compiled binary.
I have slightly modified the example shell model shellf.inp to run a modal dynamic analysis:
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?
- 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.
shell elements are expanded into threedimensional elements !?
maybe you can try first a simulation with solid elements !?
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:
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
- 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.
maybe these can help for the second question:
after these you can send out the new mesh in pre
seta new e all
seta new n all
send new abq
you can have one example
I changed the concentrated load by a distributed one and got same error. My guess is that there is a bug but, more investigation is needed.
@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.
An option may be to use a gmsh script within your automated python code. If I recall correctly, there is a python wrapper for gmsh.
I will look into that (Sept 2022).