Errors in output file?

[suviuuno]

Greetings,

I am working with Patran. For fairly large model ~100 000 shell elements I am getting the following in the output file. I am running normal modes analysis.

MAIN: The FPU has been reset after floating point exception.
MAIN: For reference, A(MAINAL) = 73C3B0, A(/SYSTEM/) = 2554A00
MAIN: A(/XNSTRN/) = 3CC0020
MAIN: "Floating point zero divide" (C000008E) exception encountered.
MAIN: Exception occurred at address 017C162B.
MAIN: Context Flags 0001003F
MAIN: EAX 00000001 EBX 00000003 ECX 00000018 EDX 00000002 ESI 00000003 EDI 00000001
MAIN: EBP 041EE200 ESP 0012F0E4 EIP 017C1631 EFLAGS 00010202
MAIN: The 32 bytes around exception location 017C162B are --
MAIN: 017C161B D8 C8 D9 C3 D8 C8 DE C1 D9 C1 D8 C8 DE C1 D9 FA
MAIN: 017C162B DC 3D A8 71 4F 03 DC CA D9 CA DD 99 E8 82 C7 02
MAIN: FPU Control Word 0273 StatusWord A0A4 TagWord 55FF
MAIN: FPU EIP 017C162B OpCode 043D DataOffset 034F71A8
MAIN: Data at 034F71A8 is 00000000 0000F03F
MAIN: FPU Reg 0 (Tag 1) 00000000000000000000 ZERO
MAIN: FPU Reg 1 (Tag 1) 00000000000000000000 ZERO
MAIN: FPU Reg 2 (Tag 1) 80000000000000000000 ZERO
MAIN: FPU Reg 3 (Tag 1) 80000000000000000000 ZERO
MAIN: FPU Reg 4 (Tag 3) 4002B9B0FD0F00A4B000 EMPTY
MAIN: FPU Reg 5 (Tag 3) 00000000000000000000 EMPTY
MAIN: FPU Reg 6 (Tag 3) C001A99C10FC41ADE800 EMPTY
MAIN: FPU Reg 7 (Tag 3) 00000000000000000000 EMPTY

There are bunch of other stuff as well but this " Floating point zero divide" is disturbing. There are no fatal errors. As a result analysis will not get through. Any help greatly appreciated.

suviuuno

 

[GBor]

I'm not sure what analysis engine you are using, but it looks like you have a "screw loose" (sorry, bad joke). It looks like something isn't fully connected and you are getting a rigid body mode (infinite displacement). This frequently occurs if you have, for instance, a 5 degree of freedom beam element perpendicularly intersecting a 6 degree of freedom shell element. In this situation, the beam can spin infinitely around it's axis.

If your model is entirely shell elements, look at your boundary conditions to insure that you are constraining all directions and rotations at a minimum of one node. If you anticipate a rigid body mode (i.e. you are designing a shaft that is EXPECTED to rotate freely about its longitudinal axis), then there should be a flag to indicate that you expect one...the lowest frequency will be ignored.

Garland E. Borowski, PE
Borowski Engineering & Analytical Services, Inc.

http://www.borowskiengineering.com

 

[airmail]

I think that "Floating point zero divide" error is typical of the models no-fixed, it means, a mechanism.

I am not sure, but I think that after this message, there is an instruction that you can follow if you want that the model run anyway. Afterwards, you can look at the movement of your model and check that, indeed, it is a mechanism. Check the points no constrained!

 

[johnhors]

This is without doubt a very serious (i.e. fatal) software bug !

The "Floating point zero divide" is a sytem error message and not a program error message.

"There are no fatal errors." - that's because the software has already crashed, and hence is in no position to report anything other than the gibberish you see (the symbolic stack dump stuff that only means something to the geekiest of geeks)

As Garland queries "what is your solver engine?" - because most solvers can handle mechanisms when doing a natural frequency analysis. Both Abaqus and Nastran will simply provide a rigid body zero frequency mode for each mechanism present in the model. You can easily test this by throwing a completely unsupported contiguous mesh at these solvers, and you will find that the first six modes have almost zero frequency (i.e. just round off error values) and almost zero internal stresses reported. Other solvers like Lusas make it necessary for the user to provide an Eigen shift value before performing a "free-free" analysis, otherwise it just simply reports that the stiffness matrix is singular and aborts the solution.

In any case whatever the solver you should never see the message "Floating point zero divide" - as that is nothing more than buggy (i.e. BAD) software.

 

[suviuuno]

Thanks for input. Problem solved. Believe it or not, few distorted quad elements caused this.

Thanks,
suviuuno

 

[johnhors]

So was the solver Nastran ?

as indicated in this line:-

MAIN: A(/XNSTRN/) = 3CC0020

 

[suviuuno]

Yes, Nastran is solver.

suviuuno

 

[fkmeyers]

Looks like UGS NX Nastran. Correct?