I know only this method:
In the menu that appears when you want to solve the simulation under Edit Solver Parameters, in the "parallel" entry I add the number of processors on which to parallelize the calculation (see image attached).
Does anyone know another more efficient method?
Paralel is a good idea. Note that hyperthreading needs to be turned off in the bios for this to work. Nastran is also I/O demanding therefore the scratch disk option can dramatically optimise the performance. Although to take advantage of this you are required to have a really fast MB/s spec'ed SSD (the fastest you can find the better).
Dear @CWilson, thanks for your answer.
1) Can you suggest me some references to learn how to turn on/off the hyperthreading?
2) about scratch: it can be usefull specify a particular path in the filed? Or it just keep empty?
3) can be usefull the "memory" field shown also by @_IG_ in his picture? This field "specifies the RAM allocated during the solve." It look quite important.
To disable the HT you would need to re-start you computer and hit the F12 (or del) key to enter the BIOS configuration. The option would likely be located in the "Advanced" section. What you want to look for is Hyperthreading, or Intel(R) HT Technology, or Core Multiprocessor. Naming can differ from BIOS manufacturer. e.g. My HP workstation option is "Intel(R) HT Technology". You then simply set this feature to "disabled". Ensure you cold-start the computer before restarting (power-off/on). * Can impact on the performance of other application(s) installed on that computer. Requires testing.
About the Scratch disk, its all depending on the model really. You can have a look in your *.f4 file, under *** DATABASE USAGE STATISTICS *** (near the footer of the file), lookup for I/O TRANSFERRED (GB). If you deal with rather large size then it might be a good idea to investigate in fast read/write hardware (SSD preferably).
For the RAM, you should be fine with default nastran64.exe (8GB). If/when you are getting memory errors then you need to use the nastran64L.exe instead (8GB+). Mind you I've never really needed to use more than 8GB even for rather large simulations.
Post edited above. Sorry.
Key is "scratch disk". This onto real fast read/write hardware, fastest specs you can find. Really makes a great deal of difference. For us it did anyway. Memory not so much.
Which particular solution? There are many things that can be done depending on the solution.
If doing modal analysis/response, DMP would help, so will RDMODES (nrec=xxx). We've seen RDMODES easily bring 50% reduction in solution time. SMP is marginally beneficial, DMP is far better if you can. I disagree with turning HyperThreading OFF, we actually have a lot of data showing it's not penalizing for DMP. It might be for SMP, but then again, SMP doesn't really scale that well.
If it is linear statics, then to use the elemental iterative solver, it's whicked fast for large models (sometimes 10x to 20x) but you must have enough RAM to be able to get this running.
If doing contact, try to get the condensation going if the contact surface is a small subset of your model...
And as far as generic recomendations, more memory (RAM), a bigger buffpool and a fast SDIR would help tremendously.