Freq Response (Sol111) - output file size

You wrote "Depending on when I run the analysis..." - do you mean when you run the model once, and then again sometime later without changing the input, the quantity of output changes? Which output? The f06 file? The punch file? I don't see any specification of an output file for a post processor, but maybe this is in the geometry.bdf file you omitted. How stable is the eigensolution, i.e. do you get a repeatable number of eigenvalues with the same values? I see you are using FREQ4 which generates excitation frequencies around each resonant frequency (11 in your case).

As has been remarked elsewhere, more details generally means more detailed suggestions.

DG

I repeat the same analysis on the same machine just at a different time. The input file is the same but the .op2 and .pch change size. I've had issues with similar models, different configurations of the same geometry, where the analysis stops for a reason relating to the sturm count but doesn't give me any error messages. I've attached an example of the .f06.

Drop back to SOL 103 and SOL 101 to check out the model. If the model won’t run cleanly in these solution sequences, you have little hope of getting a frequency response to function correctly. There are reports of many negative values on the factor diagonal of the dynamic stiffness, which is never a good sign in linear analysis.

I don’t see a GRID point singularity table in the f06 file, yet the model contains many solid elements. Is PARAM,PRTGPST,NO defined? If this is the case, remove it and make sure PARAM,AUTOSPC,NO is not also defined, then inspect the singularity table for any suspicious degrees of freedom that are reported as singular.

You are using CBAR elements. Although I have nothing against CBAR elements, they have the pathological behaviour that they don’t generate a mass moment of inertia about their axis. This means the local rotations about the bar axis are massless, but there is a torsional stiffness. Eigensolvers don’t like stiffness with no mass (nor the reverse), and this can be the source of massless mechanisms. I always use CBEAM elements. They do everything that CBARs can do and more, including having a mass moment of inertia about their axis. If one day you use the model in a nonlinear analysis, CBAR elements do not update their stiffness due to large displacement effects, whereas CBEAM elements do. You can’t offset the shear centre of a CBAR element whereas you can with a CBEAM. You can a varying section along the length of the CBEAM element whereas a CBAR is prismatic,… the list goes on. If you really want to stick with CBARs, you can request the mass moment of inertia about the axis is added to the element mass using system call 398.

Make sure the GRID points connected to the CBUSH elements have mass.

The model contains composites. Are the composite definitions able to pass a static checkout run (SOL 101) with some load applied to get sensible answers?

You have RBE3 elements defined. How are these configured (the REFC and Ci field definitions)? Are there any RBE3 elements connected to fewer than 3 independent GRID points, which would require special handling on Ci, and for those that pass this test, do any RBE3 elements connect to only colinear GRID points.

Use GROUNDCHECK on all sets to see if you have any suspicious false groundings at the G, N, N+AUTOSPC, F and A set levels.
For a SOL 101 with a GRAV load defined, do you get loads applied at all DOF?

When you have done the sanity checks, run SOL 103 with no SPCs – for a non-disjoint structure you should get 6 clean rigid body modes.
If you are still stuck after this, if you can reproduce the problem on a complete model you can share, I will take a look at it to see if I can see something obvious.

DG