I have yet another problem.
I would like Nastran to show me an estimate about DOF, memory and disk usage. This is done by memory=estimate in the .rcf nastran config file, as I learned by Googling.
Now I would also like to designate Smem to make sure scratch goes into RAM, however I cannot use both of these commands while this will give me an error.
Maybe I misunderstood the usage of mem estimate or smem, but can someone explain these to me?
I can find enough about why to use them on the internet, but not how exactly.
Solved! Go to Solution.
Thank you very much for taking the time to answer.
Unfortunately I have already seen this thread, and it does not answer the question how to dedicate an amount of RAM to Smem AND use mem=estimate as well.
I just want Nastran to give me an estimate (to know how much DOF I got), and after that I still need it to solve the equations with the following settings:
But preferably I'd like the settings to be:
Which of course is impossible because of the occurrence of mem two times.
-Estimate is an out-of-date tool that NX Nastran inherited from MSC Nastran.
-Nastran reports the DOF in the *.log file, memory and disc usage in the *.f04 file after the job runs for some time. At that point, you could stop the process through e.g. the Windows Task Manager, adjust the mem parameter and submit the job again.
-The following site has also some good information on memory and other settings. It is in Spanish, but you could use the free translator service from a well-known search site to translate it.
The estimate utility was more based on heuristics related to dof count than any meaningful algorigthms. It was somewhat reliable for simple SOL 101 and 103 models that did not contain anything beyond grids, elements, constraints and loads.
In reality, there are a lot of factors that influence memory usage that cannot be gleaned from a quick scan of the input data. Sparsity of the model cannot be determined until the stiffness matrix is generated. A 200,000 grid solid mesh has a different bendwidth than a 200,000 grid shell structure. Memory requirements for contact cannot be determined until the contact search and element formation is complete. Same thing for glue formation, dependent dof, etc. Element iterative solvers have vastly different memory requirements than sparse solvers, etc.
The problem is that the only way to get a reliable estimate for a given model is to run it to get a number which takes into account all of the factors listed above and more. Obviously, this would take a considerable amount of time. In some cases, this would be a considerable portion of the solution time.
The best estimate is your experience. Most analysts deal with many models of similar size and analysis type. After a while, you will get a feel for the memory requirements best suited for your particular needs.
As stated in the referenced thread, your first priority is to hold the decomp in core. If you have significant memory available beyond that, you can look at dumping some or all of the SCRATCH DBSET to memory via smem. You do want to leave a good amount of memory unallocated to Nastran so that the system can use it as IO cache.
Thanks for your response!
However I cant seem to find the DOF in the .log file.
Memory and disc usage I can find in the f04 file, however the whole section of memory required to avoid spill has disappeared for some reason... Any idea about both these issues?
Thank you, I will take a look first thing monday morning!
For example, see the attached file.
I was under the impression that I should dedicate ~half my RAM to mem and half to Smem, that is incorrect than? Can I do something about the Dball/Master I/O by leaving RAM unallocated?
Also, under parallel processes it names 8 processes, why is that? (I only have a quad core)
And last but not least, do you have any idea about the missing section from my f04 files? (memory required to spill is gone)
The "Memory Required to Avoid Spill" is part of the sparse solver decomposition information block in the .f04 file.
The information shown in your attachment indicates that the HIWATER memory occurred in the SOLVIT module. This is the element iterative solver. As it is an iterative solver and not a single decomposition, the decomp information is not printed to the .f04.
Thank you very much!
As I started using the iterative solver (because Nastran advised to do so), I indeed missed this information.
I can't seem to find the DOF in the .log files though, can you help me with that? Where is it supposed to be?
Finally only one small question left: can you explain to me when to use the iterative solver and when not to?
This would help me understand the program better.