I encountered a Nastran fatal recently when running a solid breakout model. A Nastran “fatal” is an error message that is prompted by some issue that prevents a solution from being completed. The potential causes are numerous. There are no comprehensive guides to understanding each one (I’m personally waiting for someone else to write that book!), but some hints can be garnered from the associated Nastran messages. The most intuitive route begins with reviewing the Nastran messages from the “Show Details” button from the Femap prompt. There lies a mix of informational messages, warnings, and fatal messages. The wording for the fatal messages is key. That’s what will provide the most relevant hint which will lead you to a strategy, especially if you’ve seen the same message many time before!
My issue turned out to be a quick fix, so I’m leaving some notes here regarding this error in case others stumble upon it themselves. The error popped up in my run after a good bit of time had elapsed. The first thing I did was inspect the f06 file via the Message Review Details window in Femap.
The f06 file is the source of the information that Femap automatically displays once an error causes Nastran to exit prematurely. The relevant section is included here:
*** USER FATAL MESSAGE 1250 (BIOWRT)
STATUS = 112, FILX = 3, LOGNAME = SCR , NSBUF3 = 32768
FILE = c:/scratch/integrated.scr
BLKNBR = 244634
ERROR MESSAGE IS —
There is not enough space on the disk.
BIOMSG: ERROR 923 HAS OCCURRED IN ROUTINE IONAST , FILE INDEX = 3.
LOGICAL NAME IS SCR
FILENAME IS c:/scratch/integrated.scr
STATUS = 112********* NASTRAN FILE TABLE *********
INDEX LOGNAME STREAM_ID NAME
2 OBJSCR 00000002 c:/scratch/integrated lug, chopped bottom-004.T15296_9.OBJSCR
3 SCR 00000003 c:/scratch/integrated.scr
5 MASTER 00000005 c:/scratch/integrated lug, chopped bottom-004.T15296_9.MASTER
6 DBALL 00000006 c:/scratch/integrated lug, chopped bottom-004.T15296_9.DBALL
7 SCR300 00000007 c:/scratch/integrated lug, chopped bottom-004.T15296_9.SCR300
8 MASTERA FFFFFFF8 c:/femapv1122/nastran/nxn10p2/em64tntl/SSS.MASTERA
9 MSCOBJ FFFFFFF7 c:/femapv1122/nastran/nxn10p2/em64tntl/SSS.MSCOBJ
*** SYSTEM FATAL MESSAGE 4276 (IONAST)
ERROR CODE 923 PID= 0
USER INFORMATION: THIS ERROR MAY BE CAUSED BY EXCEEDING THE CAPACITY OF A SYSTEM RESOURCE.
(E.G., ALLOCATED DISK IS FULL, OR MAXIMUM FILE SIZE HAS BEEN REACHED)
*** USER INFORMATION MESSAGE 4276 (IONAST)
TO OBTAIN A NASTRAN DUMP RESUBMIT JOB WITH DIAG 44 INSERTED IN THE EXECUTIVE CONTROL SECTION.
1 * * * END OF JOB * * **** SYSTEM INFORMATION MESSAGE 1156 (XCLNUP)
GINO FILE 102 WAS LEFT OPEN AT PROGRAM TERMINATION.
*** SYSTEM INFORMATION MESSAGE 1156 (XCLNUP)
GINO FILE 201 WAS LEFT OPEN AT PROGRAM TERMINATION.
*** SYSTEM INFORMATION MESSAGE 1156 (XCLNUP)
GINO FILE 106 WAS LEFT OPEN AT PROGRAM TERMINATION.
*** SYSTEM INFORMATION MESSAGE 1156 (XCLNUP)
GINO FILE 107 WAS LEFT OPEN AT PROGRAM TERMINATION.
*** SYSTEM INFORMATION MESSAGE 1156 (XCLNUP)
GINO FILE 202 WAS LEFT OPEN AT PROGRAM TERMINATION.
*** SYSTEM INFORMATION MESSAGE 1156 (XCLNUP)
GINO FILE 203 WAS LEFT OPEN AT PROGRAM TERMINATION.
The fatal message with ID 1250 was posted to the f06 file. We see a subsequent error message with ID 4276, which gives additional direction that the disk is full. The GINO FILE messages are secondary to the fatal. The first thing I did was inspect the available space on my attached hard drives:
I found that my C: drive was a little low. Note that I am using a solid state drive to maximize the storage throughput, so my scratch directory is located there. Gathering my thoughts, I realized I had a large model with over 500k nodes which was running perhaps 1500 static subcases. This sort of combination can eat up a lot of disk space, especially if the analysis requires more memory than what I have available and spills to (takes from my) hard drive as RAM resources are maxed out. In this case, it depleted all 44 Gb of space and prompted a fatal. The other drive is a traditional spinning HDD. Slower, but bigger.
So I decided that I need to provide more resources to the solution. I did this with the Scratch Files button in the NASTRAN Executive and Solution Options dialog.
Since 44 Gb wasn’t enough, I changed the location of the scratch directory (for this solution only). I allocated 600 Gb from my larger HDD, which ended up being plenty and prevented a repeat of the error. You can see the effect this setting has with an analysis preview. Select preview from from the Analysis Manager, and you will find some additional information written to the Nastran input file.
These highlighted lines indicated where the scratch file location was defined just for this solution (yes there is a slight discrepancy in the screen shots, but assume Z:\TEMP and Z:\HDDTEMP are the same place). The size of the file can also be seen, and it matches what was provided in the Analysis setup dialog for Executive and Solution options.
Note that this was just one type of fatal error message. There can be any number of reasons why a Nastran run fails. It’s just the nature of the complexity of models and the FEA process. Some tips and tricks for beginners approaching the challenge that is a Nastran fatal error are covered in Learning Femap. Specifically, a section is dedicated to explaining how dreaded pivot ratio/ model singularity issues pop up. You can see more in the book outline.
Your other recourse could lie in asking your Femap reseller, like Structures.Aero, for assistance with finding the root cause of fatals. Be aware that although resellers are there to provide occasional assistance for such items, this technically falls into the category of training. If you find yourself perplexed by fatals, looking into the training offerings provided by resellers such as Structures.Aero.
Thanks for reading!