NASTRAN In-CAD 2019 with Impossibly Slow Interface

[Anonymous]

Good Afternoon.

I have downloaded and installed NASTRAN IN-CAD 2019 along with Inventor Pro 2019. I'm working on the 30day trial as an evaluation of the software.

The model I'm working with is an assembly with 189 midsurfaced pieces, and 2 solid pieces, 14 connectors (2 springs, the rest are rigid). Part count is 227 discrete pieces. Overal model dimensions are 7'x7'x16' and I have it meshed with 2in elements throughout, not utilizing the mesh table for any refinements. The results log file shows 77220 elements. This is a "mid-size" model in comparison to the rest of the company.

The computer I'm working on is a rather new ThinkStation P320, i7-7700 @ 3.6GHz (8-core), 24.0GB RAM, Nvidia P2000 w/6GB RAM, and 256GB SSD running windows 10. The computer is screaming fast in all other programs, and even when doing advanced modelling within Inventor, advanced calculations in MathCAD, and even when compiling code in Visual Basic.

I'm finding the interface to be extremely difficult to work with. The solver appears to be running rather quickly, but the interface itself for viewing results, as well modifying part geometry (mid surfacing, meshing, etc) is impossibly slow. Saving once midplaned is also prohibitively slow (a single save took almost 10 minutes this morning). Other things like changing the visibility of the CAD bodies from the ribbon has taken several minutes as well. The solver ran in just under two minutes.

I found some threads here discussing disabling the integrated video card and seeing some improvements, and have done that. It worked.....sort of....There is still odd behavior and ridiculously slow times to do the most basic things basic things in the interface.

Is there anything I can do to speed up this model in the interface? Is there a guide I can be pointed to on how to optimize settings within NASTRAN to help with this odd situation? Should I be deriving a single part and doing the analysis on that instead of working within the Assembly directly? Any help would be greatly appreciated, as NASTRAN has some very real benefits over ANSYS in our situation, however if this interface isn't sped up it will be a non-starter.

[John_Holtz]

Hi @Anonymous

Sorry to hear about the slow performance with your midsurface model. I have not done any midsurface models of that size, but I will try a few things.

In the mean time, here are some questions:

1. Are the Inventor files saved on a network drive or your local hard drive? (I do not know about Inventor and this particular instance, but some activities are slower when working over a network.)
2. How is the speed if you were to test using solids instead of midsurfaces? (You probably do not want to use solids for your analysis because I assume your parts are thin, but I am curious if the speed issue is related to the model size or midsurfaces in particular. Maybe try a model with 50 or 100 components and compare the based interface when meshed with solids versus when meshed with midsurface and shells.)

I will also ask my co-workers for some ideas, and maybe some other users will reply, too.

[Anonymous]

Thanks for the reply. Here are some more details.

• Files are stored locally so as not to fight network traffic.
• I'll give it a go with solid elements and see how it works out. I have not tested that yet, however it was on my radar as something to try.

You are correct. The model in question is a large sheet metal weldment that I am running a discrete frequency analysis on. The same behavior was observed when creating mid-surfaces on a linear static analysis of another large assembly (roughly 350 parts in that one). The parts are large thin sections (10'x8'x1/2" plates, etc). The use of shell elements and midsurfaces is an attempt to speed to solving process, as well as match what my colleagues have been doing for years within ANSYS. The intent overall here is to get some Apples-to-Apples comparisons between the two software packages before plunking down considerable cash on either ones latest version.

I suspect the slow interface has to do with the mid-surfaced features themselves. When saving on these particularly large models I can watch the interface convert the mid-surfaces back to solids, perform the save, then regenerate the mid-surfaces. Perhaps creating the model with surfaces only within the CAD environment is the way to go. This would eliminate the software doing the conversion in real time, however this is essentially how FE models have been produced previously in ANSYS, and one of the largest draws for moving to NASTRAN is that our design room already runs Inventor, so simplifying the model geometry and importing into the analysis package is much easier than recreating the geometry all together for the engineers.

I have already begun testing a part model that is derived from the assembly. It is exhibiting the same behavior as well as the added hassle of losing all of the inherent material properties already setup in the assembly. I suspect that is not the direction to head. I will move over to testing the entire assembly with solid elements and see if the interface speeds up any.

Thanks again, and I look forward to any improvements you can suggest.

[Anonymous]

I spent the afternoon recreating the analysis with Solid Elements instead of mid-surfaced elements. It is a fairly complex analysis with some concentrated masses, lots of springs, many connectors, and several alternating loads.

Meshing with solid elements was significantly more difficult. Lots of refinements, and use of the mesh table was necessary to get all solid bodies to mesh. Some out right failed on initial setup, some worked fine. A little more time was spent here than in the midsurfaced model, however it's probably a wash with the midsurfacing step.

The number of elements grew SIGNIFICANTLY. The shell/midsurfaced model was about 75k elements. The solid model was around 485k elements. The solve time increased as well from ~1.5min to ~7min. Still completely reasonable solve time considering the size of the analysis.

Displaying results, saving the file, displaying/hiding CAD Bodies and Mesh are all notably faster. Much less hair pulling and "clicking and waiting" with the solid meshed model. This leads me to believe that the midsurfaced features are causing the interface to be so slow. The saving in particular is significantly faster. Saves are in the 20-30 second range now as compared to as long as 10 minutes with the midsurfaced model.

I haven't had good results from the solid analysis yet, but will continue with that tomorrow and see if I can get the results to match each other between the two differently formatted models.

I'm very anxious to hear what changes might be possible to make to improve this midsurfaced models performance. Thanks to all for the help!

[Anonymous]

Hi Mdobrick,

I'm currently working on a similar (albeit slightly smaller) model using surfaces, and about 32,000 elements.

I don't have any tips for you, but I can only confirm performance is woeful on my PC, I've spent a whole week setting up, and debugging the FE model, and dealing with crashes etc. Save times are taking about 30mins, but our PCs aren't spec'd as well as yours.
The biggest issues I'm having is that mesh idealisations seem to be a bit forgetful - I'll select a set of faces and assign them to an idealisation, then when I generate mesh, it leaves one or two faces out, then I have to re-select and re-mesh.
Geometry changes are also buggy - I've had cases where a minor dimension change has resulted in a part's mesh being re-located to some arbitrary position, and there's nothing I can do about it - even deleting the mesh, or mid-surface and re-creating it doesn't work.

There's only 2 reasons I persist - its very easy to solve a plate model that isn't water tight, and its very easy to update geometry, and try again (when it works at all).

[Anonymous]

@Anonymous Thanks so much for the reply. Glad to know I'm not the only one fighting this particular problem.

I can confirm that I've also had similar issues with the midsurfaces just shooting off to nowhere. Most notably that will happen any time I go back to the geometry to make a change. Adding a face, work point, plane, or axis will do it sometimes. Heaven forbid if you remove a part, or replace a part. Working through the model tree in the NASTRAN browser is a complete pain. The midsurfaces aren't named logically at all (can the software not just copy the part name to the midsurface name instead of sequentially numbering them?), and attempting to remove more than one at a time is time prohibitive since multi-select doesn't work. I've found several times that completely abandoning the model and starting fresh is faster than attempting to fix whatever shenannigans the software has done. Sadly this also means recreating mesh refinements, constraints, loads, connectors, and idealizations.

The midsurfacing tool works very quickly initially. It finds the parts, mid surfaces them, and applies the material properties in minutes, even on a rather large (500ish parts) assembly. Once they are created it's as if it doesn't save the data it has just created, and has to recreate it every time you want to do an operation in the interface such as add non-structural-mass, refine the mesh, or even save.

On this medium sized model, I think I've had to start over 4 or 5 times at least. It's quite an annoyance, however it has taught me very quickly to keep good notes of the analysis in terms of loads, constraints, connectors, and masses. I've even gone so far on this last iteration to create workpoints in the 3D model before bringing it into NASTRAN to assist in the speed of model setup. I was able to recreate the analysis in only about an hour yesterday afternoon with my notes and work points system. This however is a work around that I think shouldn't have to be faced. Coupled with similarly long save times, and the "click and wait" interface it makes the analysis take significantly longer than it should.

I'm going to continue on the path of refining/tuning this solid element model today and see if that helps with speeding the analysis up. The number of elements has grown significantly, however I have the benefit of a well spec'd machine to run the analysis. I'll gladly make the trade to a long solve if I can get that time back in the interface, setup, and results display. Even a 30min solve would be better than the hours spent waiting on the interface, and reworking the FE model at this point.

A final thought is that having worked with Inventor since release 10 (13 years ago or so I think) I have learned to "save now, save often" as it tends to crash fairly regularly. I've had good luck isolating the problems most times, and not repeating them, however it's still a thorn in the side when it happens. NASTRAN IN-CAD appears to be at least as stable as the underlying Inventor platform at this point as I've only experienced a few full stop crashes in the 6 or so FE models I've prepared.

I really want this software to work for us. The interface needs a few minor tweaks, and the speed of working with midsurfaces needs addressed. Aside from that it has all of the basic solving that we need, and has a price that is very agreeable. The added benefit of being in the native Inventor is a huge advantage for us as well.

[John_Holtz]

Thanks for the feedback @Anonymous and @Anonymous.

I have reproduced this problem with a simple test model (80 parts). The developers are looking to see what can be done to improve the performance. Working with solid idealizations does not have the same slow response. Of course, the model size (mesh and number of nodes) needs to be much larger in some cases to get the same accuracy that you get from shell elements.

Just to clarify about the multi-select functionality. Multi-select does work in general in the browser/model tree in version 2019 using the Shift key or Ctrl key in combination with the mouse. (It did not work in 2018.0 and 2018.1.) It is not convenient in this specific situation of selecting the Midsurface  "parts". In order to select all of the Midsurface parts, you need to click on them one at a time while holding the Ctrl key to select multiple items. Then press the Delete key to delete them. On the other hand, the shell idealizations can be selected by clicking the first one, hold the Shift key, and clicking the last one.

[Anonymous]

Thanks for the response John, we look forward to future improvements.

For what it's worth, I'm currently trying to save my document by exiting the Nastran environment, saving, then re-entering the Nastran environment. It certainly seems that Entering the environment takes the most time - by a long shot, exiting the environment comes next, the actual save only takes a few seconds.

I noticed when I'm entering the Nastran environment the status bar has the comment: "<Esc> to Cancel; Executing Unsuppress Feature". This seems a little odd - I'm not sure how this fits in, but this is the point where we do most waiting...

Regards

[Anonymous]

@Anonymous Thanks again for more information and a much more clear explanation of what is happening. I can confirm that a majority of the setup time that is waiting is when I am working directly with the mid-plane features, or doing a save. Once they are midplaned, and the mesh is defined, I can typically work acceptably placng constraints, loads, connectors, etc. Anytime it gets sluggish with those items, I'll exist NASTRAN environment, save, and re-enter. I try to do this before lunch so it can work while I got eat.

@John_Holtz Thanks for the work on duplicating the situation. Is there a way I can send a screen captute or similar example of what I'm working with? Due to the nature of the equipment and the amount of information in the FE model I can't send the model itself unless we setup some sort of NDA agreement, which feels excessive at this point. I think taking a screen capture would be acceptable though so you can see what the machine is doing here. Also, is there any form of logging I can enable within the NASTRAN environment that would garner more information for you and your team?

Another thought, I tried the multi-select on the midsurfaced bodies. I can indeed hold down control and select multiple items. The highlighting on each item doesn't stay, so I was assuming it wasn't working. It appears it is working though. I do have to confirm each deletion though, and that is another click and wait scenario. Wait times between confirmation boxes are between 45 seconds and a minute a piece. So a 20 item selection leads to a 30 minute deletion.

I've had another thought as I'm typing that I will investigate this afternoon. I am working in an assembly with just over 225 pieces in multiple sub-assemblies. I'm curious if I promoted all pieces to the top level, and worked with only a single assembly if this would help with the interface speed. Going off the comment of @Anonymous, and noticing that the midsurfacing is suppressing features, I'm wondering if I'm simply trying to access too many files at once? Just a thought, and another avenue to investigate.

Thanks again to all for the help!

[Anonymous]

Another factor which may (or may not) play into the equation is that my model is a multi body part derived from an assembly... Long story short, my CAD model started as a multi body skeleton with a mix of solids, surfaces (some of the solids were created from thickened surfaces)... After I built my assembly and started to create the FE model, I found that surfaces used in the definition of some of the solids were still lingering around as artifacts - I couldn't omit them from the FE model, not using LODs or "exclude from analysis" from the browser tree. So I decided to create a derived part where I could very easily control the inclusion of surfaces and solids - then I created my FE model off that, and it's working fairly well so far, no more issues with artifacts being incorrectly included.

I wouldn't suggest this as a tool for improving performance though... 

Regards

[Anonymous]

Good Morning @John_Holtz

Any word from the developers in finding a solution?

I haven't been able to spend much time optimizing my model for performance, but hope to get back on it today. I've come to ask about computing speed in relation to this particular issue. Assuming I had a significant budget for a new PC to handle this task on a daily basis, would I see any improvement from building a very high end machine? If so, what areas would I concentrate on? Clock speed? Multiple Cores? Video Ram? Super Fast Storage?

I have two machines sitting on my desk now I hope to do side by side testing with once I have a model that runs and has been tuned properly. Both are i7's with SSD HD's, however one has significantly more RAM, a much nicer video card, and runs at a higher clock speed. I'll be sure to report back on those tests once they are run.

Thanks again for the help, and I hope to hear some encouraging news soon.

[John_Holtz]

Hi @Anonymous

The shell issue is on the agenda. I do not know if work has begun on it or whether development is wrapping up their other work.

About the computer specs. Clock speed is important. Speedy input/output is important. RAM may be important if you work on large models (millions of nodes or elements). I think number of CPUs is less important than most users think. 8 CPUs is around the optimum. Using many more CPUs just takes time to split the problem into multiple CPUs, so there is not much of a speed savings.

[Anonymous]

Just following up on this issue... We updated to 2019 (from 2017) over the weekend just gone, and Nastran has now ground almost completely to a halt. Solutions seem to be a little faster, but loading/unloading results, entering/exiting the environment or saving are all now 30min-60min operations.

Keen to watch the progression of Nastran, but just at the moment it's genuinely unusable on larger analyses.

[Anonymous]

will this be fixed in the 2020 release?

[Anonymous]

Just as a follow up to the interface problems I've been having......For starters our FEA work has slowed a little, so my usage has gone down a bit. We've also upgraded to 2019 from the 2018 trial. Furthermore, I'm working off of a new laptop.

The interface is "better" on the new laptop. There are still significant hangs, and a lot of the previous issues still exist, however it's not as "unworkable" as it was before.

I'm unsure of the cause, as I changed many variables at once. I can say the new laptop has significantly faster storage (new V.2 NVME SSD, vs standard SSD ) than the desktop, and is also running a more modern 4 core processor than the desktop. The laptop has decidedly slower graphics capabilities (integrated video only, desktop has dedicated GPU).

It's workable for us for now, but I think there is still some significant room to improve. If there is any interest I can grab a GoPro and do some "over the shoulder" recording of the speed differences.

[John_Holtz]

Hi @Anonymous and @Anonymous 

We are hoping to investigate this issue in February. Whether it can be released with the 2020 software (sometime in April 2019 if I remember correctly) will depend on what turns out to be the cause and solution.

[Anonymous]

@John_Holtz Thanks for the response on the consistent monitoring of the thread. It's good to know that AutoDesk has someone listening in on the users here.

I have a bit more data to give on this issue, and thought the results were interesting.

I have been working in a much smaller model for the last few days, using the FEA results in a Linear Static analysis to size up components in a new design. This model is MUCH smaller than the ones that originally prompted my start of this thread. Here is the model setup.......I have 1 solid part, and 7 sheet metal parts. The solid is idealized as a solid, and the sheet metal parts are idealized as shells. Meshing is complete, loads and constraints are placed, and the analysis run.

I have been working between two machines. My desktop machine, and a new laptop I spec'd and the company furnished. Here are the specs for each machine. I have the latest/most up to date drivers installed on both.

Desktop:

Thinkstation P320 Signature Edition

Core i7-7700 CPU

256Gb SSD

24 Gb RAM

Nvidia P2000 video card.

(3) 21in HD monitors displayed with NASTRAN on the primary

Laptop:

Thinkpad X1 Yoga (3rd gen)

Core i7-8520U

512Gb SSD

16Gb Ram

Intel UHD 620 graphics

Single 13.3in 4k display.

Running the same analysis on both machines I find that the desktop will solve a shade faster than the laptop. The desktop solves in 3min-32sec and the laptop solves in  4min-21sec. Not a terribly big difference IMO. Again this isn't an overly complicated model to solve, and it's a relatively "simple" analysis.

The real speed difference is noticed when displaying results. The desktop is PAINFULLY slow to display results. If I restart inventor, open the assembly, enter NASTRAN environment, the load my results file from the same analysis. That time is VERY similar. However if I right click on a plot and select display, in this instance a stress plot with shading, no deformation, mesh not displayed, and the display not zoomed......Then the laptop is SIGNIFICANTLY faster. It will load the results in approximately 9.8sec. The desktop takes almost a full minute to update the display at 55.7sec. Once displayed panning/zooming/rotating is near identical. Selecting a probe on the desktop is all but impossible. It will literally "lock" the system until I move the mouse off the viewing area and allow it to "catch up", then the interface "comes back to life". The laptop does NOT have this issue. I can easily hover my mouse around and get near real time updates on the probes for various locations.

The laptop has been my "workstation" for FEA since I received it a month ago. It has a clear performance advantage in the displaying of results with only a small penalty in solve times. The interface is MUCH faster when responding to changing plots, updating the display, and interpreting the results. I feel this shows that it's not so much the software that is the issue here, but the configuration of the machine in general. Even this resource points at running an OpenGL card for a high end system, and I'm not certain that is really the best advice here.

My suspicion is that my laptop is handling a particular video codec better than my desktop. I'm not 100% certain how to test that theory at this point, but am researching video card benchmarking software now to see if I can pinpoint where one system is out performing the other in this case. PLEASE let me know how I can help in improving this. I'll gladly run benchmarks, try different drivers, or otherwise test the two systems to figure out what is happening. The end goal is a modification to my desktop system to have equal or better performance the my laptop, as well as sharing that information with the community to prevent someone else from having the same problems!

Thanks again for your time!

[shigeaki.k]

Hello @Anonymous ,

just couple of thoughts. Are the graphics cards driver version newish?  Also just to check, have you switched off "onboard graphics" i.e. set it so that it will only use the nvidia card.

Regards,

Shigeaki K.

[Anonymous]

Good Morning @shigeaki.k 

I did some testing this morning on the desktop machine concerning the graphics processing...My findings in the previous post were with the Internal Graphics Processor (IGP) switched off and only using the PCI Express Graphics Processor (PEGP). I've tried again with the bios set to "auto select" as well as IGP only. I've also tried all configurations of NVidia control panel settings in regards to "OpenGL Rendering GPU". Those options being auto select, IGP, or PEGP. There is no appreciable change in results load time with any of those. Each load is still right around a minute with the fastest being about 54sec and the longest being about 62sec.

I have downloaded the latest drivers, both BETA and Stable from Nvidia's website as of yesterday (2/5/19) morning. Neither of those have helped the situation either.

Doing some testing yesterday afternoon, I have noticed that the GPU is not being utilized at all during the loading of the display. Once I have the results from a previous solution loaded, and I right click on the results plot I want, then select display I started watching the process in task manager. During the ~1min load time the CPU jumped to around 14%, disk usage jumped to about 8.1Mb/sec, with GPU, Memory, and Network remaining at zero. Once the display is loaded all parameters drop back to zero (except memory of course). This tells me it appears to be more of a bottleneck with the hard drive than the GPU. I should not here, that once the display is loaded, rotating, panning, zooming, or any other display manipulation will quickly spike the GPU on both systems into the 10-15% usage range. This would be expected, and neither machine has any issue viewing the results once the display is loaded.

To test my HD read/write theory I ran CrystalDiskMark, a Hard Drive benchmarking tool. I ran it on both machines. The results are VERY similar between the two. I've attached the results from each. There doesn't seem to be enough of a difference between the two machines to notice a 6x difference in load times. If anything the desktop machine appears to have slightly faster storage overall.

Should I be looking into updated motherboard drivers, or something along those lines? Where else can I look to investigate the slow loading problem?

I'm going to attempt to load the original model that created my initial post onto the laptop at some point today and see if it is likewise improved over the desktop. I'll be certain to report back my findings.

[Anonymous]

 @shigeaki.k @John_Holtz 

Any word on where this might stand in the development list?

I have been doing testing for the past 2 weeks or so on a new design model we are working on. It is a medium sized (in terms of item count) shell/solid model. I have been working exclusively on my laptop which is SIGNFICANTLY faster than my desktop. It has a nice screen and all, but the single 13.3in is a little tiring compared to the (3) 24's on my desktop.

I attempted a complete reinstall of all Autodesk products this morning. It made zero difference in performance of the NASTRAN interface. I retested display times again, and it's around 67sec for the desktop and around 7sec for the laptop. Solve times on the actual solution are still nearly identical. I've dumped the graphics diagnostic specs from both machines into a PDF and attached it here if anyone is interested. I'm at a loss for what is causing the performance hit on the desktop at this point.

I'm going to reach out to my VAR this afternoon and see if I can get some insight from them on what is going on. At this point, if I didn't have the laptop I would have an extremely painful experience using the software. Hopefully someone here has some insight soon.