Blog

This is a summary of preferences which should be modified for a new Simcenter Femap Nastran installation, and why.  It includes Femap preferences, plus settings to improve the Nastran solver analysis performance, further down this post.  This information is current as of Version 2021.2, but most points are also relevant to earlier versions.

Femap File | Preferences

Geometry/Model Tab:  Solid Geometry Scale Factor MUST be set to the length units you prefer for modelling or importing geometry.  There are two reasons: Firstly, Femap uses the Scale Factor to internally scale the geometry into Parasolids’ modelling extents = 1000 unit cube, centred at the origin.  If you set the Scale Factor to 1.0, but the geometry is 3500 units long, it will not create/edit properly because it falls outside the internal limits of the invisible modelling cube.   Similarly, if the Scale Factor is set to 1000, but the geometry is 50 units long and 600,000 units from the origin, this will also fail to create/edit properly.  Secondly, imported geometry (depending on source) will usually scale its actual size if the Femap size unit (ie. Scale Factor) is different to the source size unit during import.  And, if the Femap model includes geometry of mixed scale factors, this is likely to produce some unexpected outcomes when editing or adding to the geometry.

Geometry/Model Tab: Mesh Sizing… we prefer Equal Length.  This is because what you see is what you get.  Parametric sizing can space the mesh more closely along tighter curves, which can be nice, but you can end up with mesh sizing mismatches if two adjacent pieces of geometry are identical length, but have different parametric definition.

Database Tab:  Backup before Save should be ticked on.  This retains one additional copy of the Femap model at the condition of your last most recent save.

Database Tab:  The Femap Scratch Directory is not the (Nastran) scratch directory you set during installation.  They can be set to the same location.  If left blank, then Femap uses your Windows User Temp directory.  The location (a folder, eg. D:\scratch) should be a convenient and fast disk location, preferably on an SSD.  The folder should be writable by any user who logs onto the machine.  It should be fast and convenient because Femap holds a temporary full copy of the model there, plus undo files.  These are not always cleaned up on save/exit/crash, so a convenient location is wise so it can easily be tidied up.  Once the Scratch location is set (and even if left blank), the Read/Write Test button should be pressed so that Femap chooses the fastest Open/Save Method.

Results Tab: Femap can either import results into the model (default) or “Attach to Result Files” when that option is ticked.  The latter makes Femap models much smaller and faster to open, save, operate, show results etc.  The disadvantage is that for project management / traceability you need to move / save / backup any of the attached Nastran .op2 results files that belong to the Femap model.

Results Tab: Output Set Titles should be changed to “2..Subtitle” if you commonly run multi-case linear static analyses and would like Femap to automatically title the results according to the analysis setup, rather than the default “Simcenter Nastran Case 1”, “Simcenter Nastran Case 2”.  “0..Standard” remains better for auto-titling Eigenvalue (natural frequency & buckling) analyses, plus non-linear and transient analyses with multiple results sets.

Graphics Tab:  Assuming your computer has a reasonable Open GL graphics card, “Hardware Accel” and “Best Possible” should be ticked on.  For older versions without the “Best Possible” option, choose “Performance Graphics” and “0..No Vertex Arrays” should be changed to “3..Vertex Buffer Objects”.  Max VBO MB should be changed to ~75% of the dedicated video RAM on the video card (eg. a 4GB card would have Max VBO MB changed to 3072).  These make substantial difference to the graphics performance, particularly for large/complex models.

User Interface Tab:  Tick Dynamic Zoom around Cursor Location and Dynamic Rotate About Cursor Location.  When working at close range in a complex model, it helps to rotate and zoom around a local entity rather than some global model centre.  This setting is affected by the “Snap To” options (right click in View Window… Smart Snap, Snap to Point or Snap to Node).

User Interface Tab:  Load / Save Layout.  We have a multitude of custom menus and toolbar configurations.  Regular Femap users would rarely stick with the factory default layout.  Once we have a good Femap interface setup, we use Save Layout to store that configuration and then retrieve that for each new installation on a different computer, or for a version upgrade.

Interfaces Tab: Tick Create Geometry References, Create Analysis Model References and Create Analysis Results References.  This assists with project tracking for reporting or backup.  It stores (in File | References) a list of the geometry file(s) you have imported, as well as the Analysis / Results files which have been created.

Interfaces Tab: Max Lines to Monitor should be set much larger, eg, 100000 or 200000.  This is useful for long non-linear or transient analyses where you would like to watch what is happening in the .f06 file or the .f04 file.  5000 lines is too short to be useful in these cases (monitor fails to scroll to the end of long files).  Note that the text reader used in the Analysis Monitor is quite slow, so it can take minutes to show a big file.

Simcenter/NX Nastran Preferences (nastran.rcf)

The nastran.rcf file is a simple text file which should be edited to improve the default NX Nastran performance.  The file is located in <Femap_Install_Dir>\nastran\conf.

The factory default condition is better than it was (new values for memory and smem), but there is still further room for improvement…

Any good computer has multiple cores, and your standard Femap with NX Nastran licence is multi-threaded in some solver matrix operations.  Add a line:

PARALLEL=x

where x is however many cores your computer cpu has.  Even if you have more cores, there are diminishing returns above 8.  For numerous cores and multiple SSD’s, the computer could otherwise efficiently run multiple simultaneous analyses, if useful.  If you do want to run multiple simultaneous analyses on one computer, best performance is achieved if each analysis uses a separate scratch disk, preferably an SSD.  Also, if you do wish to run simultaneous analyses, the following recommendations for memory and smem need to be reduced to allow for the SHARED allocation of resources.

SDIR=fast disk location

The SDIR line is set during installation, but can be changed if the initial choice was not the best choice.  “Fast disk location”  (eg:   D:\scratch)   should be on the fastest disk on the machine (preferably SSD).  It needs to have plenty of free space if the analysis is large (roughly 40GB free per million nodes for a linear static analysis, unless you have monster RAM).  The size is rough because it is not a linear relationship and depends on analysis type and matrix density (and assuming not using the iterative solver).

For large RAM computers (>24GB)…

We also suggest changing some existing lines in the nastran.rcf file.  [NOTE: this advice is less important for current versions, because the defaults are much improved, but not excellent. Also, in OLD versions, these changes MUST be done in conjunction with ticking the “Use ILP-64 bit NX Nastran” option in Femap’s File | Preferences -> Interfaces tab.]

memory=yMB

where y is about 75% of your computer’s physical RAM, eg. for a 64GB computer, this line would read memory=48000MB   (or the factory default proportion can be changed to 0.75*physical  ie. 75% of RAM).  Note that “MB” is case sensitive.

smem=zMB

where z is about 60-65% of your computer’s physical RAM, eg. for a 64GB computer, this line would read smem = 40000MB   (or the factory default proportion can be changed to 60.0x).  Note that “MB” is case sensitive.  If smem is large enough, then all the major Nastran scratch files will be contained in physical RAM, which is still at least an order of magnitude faster than the best SSD.

In general, Nastran performance is maximised if smem is bigger than the maximum cumulative size of the major Nastran scratch files – whilst not making the memory setting so large that the computer “swaps” (uses disk [=slow] to act as RAM if the RAM is filled).  Smem must be smaller than the value set for memory, because the solver itself needs space to perform matrix operations, separate to the scratch files being stored in smem.  Thus smem + amount required for the solver itself must be less than the memory setting.  In our experience, if the RAM is big enough to allow all major scratch files into smem, the overall analysis performance is superior compared to allowing Windows to automatically use spare RAM to cache files.  Note that even if you have the best SSD, most have limited write life (eg. 10,000 lifetime cell writes before the disk starts to die), so writing huge I/O to memory rather than disk is faster and helpful for SSD life.  And thus, important data should be backed up to some location other than any SSD which is hammered with FEA scratch I/O.

The Nastran .f04 file provides useful computing resource information including MAXIMUM DISK USAGE and I/O TRANSFERRED, at the end of the analysis.  These substantially influence runtime performance, particularly if the disk is slow (= mechanical).  Ideally smem needs to exceed the MAXIMUM DISK USAGE which would have been reported had smem not been set at all.  As this is hard to assess upfront, it’s best to make smem as large as practical, as indicated above.  For large contact or non-linear analyses, sufficient smem can reduce the I/O TRANSFERRED from TB to a few tens of GB.  In practice, a reasonable mechanical disk will take 1.5 hours to deal with 1TB of I/O, whilst a good SSD might take 20 minutes – but your computer’s RAM can deal with this sub-component of the analysis in less than 3 minutes if smem is large enough.  Even when Windows caches spare RAM, all the I/O TRANSFERRED ends up physically on the disk at some point during the analysis.  The summary point is that with sufficient smem for a big analysis, the dead time waiting for slow disk I/O is virtually eliminated, and total runtime is thus “only” limited by cpu usage.

buffsize = 32769

if not already set.  This allows larger models to be run without exceeding default maximum scratch file size allocation.

buffpool = 1000

We recommend the buffpool be lowered from the factory default of a proportion of RAM, to increase the memory space available for smem.

Also checkout how to speed up or improve Femap processes with our productive free APIs.