Result File is in wrong format - NX 7.5

[cfhamm]

I'm trying to do a simple FEA static load on a lower control arm in NX 7.5, and everything appears to be working, except I cannot do any post processing b/c it says the "Result File is in wrong format." The .f06 file has no fatal errors listed, and I've tried the param, bailout, -1 procedure without any luck.

The data appears to be writing to a .dat file. Failing the ability to post-process in NX, is there another processor that I could run the .dat through and still get results and animations?

 

[mlamping]

Could you copy and paste the top of the input file (*.dat) here? My first guess is that the solve didn't complete successfully. My second guess is that the output is in an XY plotting type format (i.e. SORT2 on the output request entries). Copy and paste all lines from the top of the file to just after the last PARAM entry. Basically stop when you get to the first GRID.

Regards,
Mark

Mark Lamping
CAE Technical Consultant
Siemens PLM Software

 

[cfhamm]

Top of the .dat is attached. Searching revealed that SORT1 might solve my issues, so that is the output I requested.

 

[mlamping]

Thanks for the snip of the input file. That is fairly default stuff. SORT1 is the default for linear statics, so if there's no sorting method specified, SORT1 is used... for linear statics. Assuming that using SORT1 explicitly didn't address the problem, can you summarize the warning, fatal, and error messages from the F06 file?

There is one other possibility. Does the model have any constraint (RBE2) elements in it. Searching a Siemens PLM internal mailing list led me to a reported post processing limitation that's been extended/removed. The limitation was related to a model that contained an RBE2 element with 33484 nodes. That's not a typo... 33484 nodes for one element! NX 7.5.2 and prior versions support models with single elements defined by up to 32767 nodes. NX 7.5.3 and higher versions support single elements defined with up to 2 GB nodes. So this limitation has been virtually removed.

Regards,
Mark

Mark Lamping
CAE Technical Consultant
Siemens PLM Software

 

[cfhamm]

This is the original error I've gotten:
USER FATAL MESSAGE 9137 (SEKRRS)
RUN TERMINATED DUE TO EXCESSIVE PIVOT RATIOS IN MATRIX KLL

That led me to the param bailout -1, which removed the fatal error but still gives me the error on the output file. I see no other warning or errors in the .f06 file.

There shouldn't be any contraint elements, though I do see that I have 49,673 nodes now from 36,503 elements. I'm constraining it by a fixed constraint on the inside face of the bushing mount, could that be causing a problem?

Thanks for the help

 

[mlamping]

Excessive pivots usually indicates rigid body motion. PARAM BAILOUT -1 will typically remove rigid body motion, but it's not a recommended practice. It's more of a troubleshooting utility that helps you understand what's wrong with your model. Could you provide the contents of the following:

1. Open the SIM file
2. Select the SIM file in the Simulation Navigator
3. MB3 Simulation Summary

This will print out a summary of nodes/elements, boundary conditions and such. How many solid/sheet bodies are meshed? This could probably be solved with a quick view of the model. Doing it here is more challenging. You may want to consider opening a call with GTAC so that you could show the support AE the model and get some quick advice.

Regards,
Mark

Mark Lamping
CAE Technical Consultant
Siemens PLM Software

 

[cfhamm]

It is a lot of individual bodies due to the file I was given to work with. Haven't found a way to successfully combine them yet. The sim summary is attached.

 

[mlamping]

That helped quite a bit. Your model is a lower control arm represented as shell elements. I assume that the lower control arm is a single solid body, and the geometry you were given is a bunch of sheet bodies that represent the midsurface of the solid body?

How are you assuring that the shell elements are connected? I suspect that there are regions of your shells that are completely disconnected from one another. Further, those elements have no path to the constraints you defined, so they are free to move rigidly (a linear statics no-no). If the CAD geometry is manifold, then you can sew the sheet bodies together to form (for example) 1 body from 2 bodies. Non-manifold connections (such as two sheet bodies forming a T intersection) can be connected in the FEM polygon geometry using the Stitch Edge command. Sew in CAD and Stitch Edge in CAE polygon geometry will produce shell-shell connections (i.e. shells that share nodes/edges) and a contiguous mesh.

Your control arm should be one contiguous mesh but I suspect it isn't. At this point you can check the shell mesh for element free edges. In the FEM or SIM select the Finite Element Model Check command (green check mark icon or Analysis, Finite Element Model Check from the menus) and set the dialog to Element Outlines. Apply the dialog and NX will highlight all of the shell element free edges. These are edges that don't connect to other shell elements. There are likely more free edges in your model than there should be since your input geometry is unstitched.

Another way to view the disconnected shell element regions is by performing a normal modes analysis. Every disconnected region will produce 6 rigid body modes. If you have 3 disconnected regions, you will get 18 rigid body modes.

If I'm correct here, I suggest you review the NX online help for the Modeling Sew command and Advanced Simulation Stitch Edge command.

Regards,
Mark

Mark Lamping
CAE Technical Consultant
Siemens PLM Software

 

[cfhamm]

Yep, that diagnosis sounds right on point. I didn't realize it was all separate bodies until I'd meshed it, and completely overlooked constraining them to each other. Will try sew and stitch and the checks tomorrow, hope that's the answer!

 

[Walterke]

If the problem was caused by sheets not being connected to one another, how come the bailout -1 solution didn't work?
I've had similar problems (usually solved by deleting everything and starting again) in the past, which is why I ask.

 

[mlamping]

That's a good question. I don't know why BAILOUT = -1 didn't work, but then again I never use it. I prefer to resolve the singularities myself than have the solver introduce artificial constraints. I suppose BAILOUT could have helped me at times to quickly identify regions that need to be corrected, but I've never got in the habit of using BAILOUT.

Regards,
Mark

Mark Lamping
CAE Technical Consultant
Siemens PLM Software