A colleague of mine has the following problem: an op2 contains output which seams "too small" for FEMAP, resulting in the "1. #INF" value and a crash if he tries to plot the output.
I asked for output in the f06, there are indeed values such as 1.E-39 on certain nodes when the rest of the model has displacements around 1.E-6.
The f06 is imported correctly, but the model is huge and he has many more subcases to add so we would rather use the op2. I thought FEMAP could "clean up" this kind of output, but apparently something went wrong in this case.
This can be replicated easily with the model I've attached.
Is there something to do on the FEMAP side, like flipping a switch in the "Preferences"?
I'm using v11.1.1, is this a known bug? Is the problem on the NASTRAN side?
Solved! Go to Solution.
I have been unable to repeat the error. Can you provide some more information. The .log, .f04, .f06 and even the .op2 file would be helpful.
How did you see the value? via list output, before the crash?
Here are the files.
I see the value through:
>> Select PostProcessing Data
Deform = Total Translation
>> Vector Info:
"Output Set : 2..MSC/NASTRAN Case 1
Output Vector : 1..Total Translation
Min : 2.6102E-7 At Node 4 Max : 1.#INF At Node 2 "
FEMAP doesn't like the 1E-40 value.
The crash only occurs if I try and plot these results.
Same goes for version 11.0.1.
This may have been fixed for v11.1.2, I don't have it so I can't say...
It appears this is an issue with MSC Nastran. The op2 file contains a floating point error. I reran the job in version 2012 and the op2 file no longer has the bad number. If you have access to a later version, that seems to eliminate the issue. Femap does have checks for bad floats, but did not catch this particular one, we are adding another check to catch this in the next Femap release.
If you do not have a later release, then maybe running the ILP executable will create an op2 without the float error.
Great thank you vey much!
I found a workaround for displacements in the meanwhile, MSC NASTRAN allows for a filter in the output request through DISP(TM=XXX,RM=XXX), thus avoiding too small/big values in the op2.
But I was afraid this might also occur for small stresses, forces...etc... other output. Your response confirms that it should not.