Has anyone done some comparison of running a nastran job with smp specified and with or without nrec specified too?
I just did a SOL111 test with smp=32 and by specifying nrec=128 it seems that the analysis is slower!
(FEM DoF ~ 1285710, Nmode up to 2000Hz which is about 100 modes, Sol111 requests FREQ card every 1 Hz between 20-2000Hz
Does that make sense?
Is anyone prepared to share thoughts and/or experirence on this capabilities?
By default all the job are run with parallele=32
Solved! Go to Solution.
1. NREC keyword applies to RDMODES. RDMODES is an alternative to computing eigenvalues when number of eigenvalues are > 200 to 500.
2. If you have a good disk system, I suggest you use DMP and SMP together with RDMODES. This will give you a very good performance.
3. What kind of damping do you have. Is it modal, viscous or structural damping. The frequency response depends heavily on this.
4. In your case, it seems to me computing frequency response might be the longer than computing normal modes. It seems to me that your response is between 20 to 2000 Hz. However, you are computing modes only from 0 to 2000.0 Hz. To get a good frequency response solution, you should obtain modes from 0 to 4000 Hz
Thanks for the input.
2. Cannot use 'dmp' as not set up, I think
3. & 4. for the test I am doing , I don't mind what is the "accuracy" of answer(s). I just want to see if the nrec optiin is faster. I just killed the job as way too slow.. But for info: damping speciifed as CRIT and previous test with nmodes extraced up to 6KHz showed virtually no difference in key response.
Thanks jimB for the reminder. Currently running out of time to test things. Will have too look into this at some stage I guess
right now I have found no way of "speeding" up a SOL111 to get rms (VM) stress. Will have to request rms vlaue for a smaller set of elemetns...or find another tool!
Took a step back and try running a SOL103 for a "large"number of modes (about 460-off)
1. there seems to be a time improvement ~45% (with nrec=128)
2. "loss" (or is it a gain?) of accuracy in the freq, predicted, which I believe is desribed in the doc. See attached
3. analysis with nrec=128 found 15 fewer modes in the range (up to 6KHz)
RDMODES is an approximation to obtaining modes. If you use NREC=128 you are asking the solver to use more substructuring. If you want to compare it with Lanczos solution, you might want to change NREC to 64 or even drop it down to 32. Of course, this will increase your elapsed time.
I would focus on the response solution and see what value of NREC would work for you in terms of solution response accuracy. We've found that for most applications one can go to NREC=256 without sacrificing accuracy - especially when requesting thousands of modes.
Note: Since substructing is used for RDMODES, the eigenvalues might not be necessarily the same as Lanczos. However, both methods obtain modes or Rayleigh-Ritz vectors needed to span the solution subspace. The goal here is to be able to predict the frequency response.
tested with nrec=32 and time improvment is marginally better than with nrec=128 (i.e. still about 45% of no nrec) but the difference on the value of the freq. is noticable. The freq. prediction is mainly below 1% difference and only 9 fewer modes
When using RDMODES you are using a slightly different subspace to span the Ritz vectors. It is not really missing eigenvalues but it is using a slightly different subspace from Lanczos. Even the Lanczos is typically augmented by using residual vectors especially if you are interested in responses at loading location. As I mentioned earlier, what needs to be compared is not the modes themselves but the response they produce and how much you accuracy you are willing to forego to complete the solution a little faster. The benefit of RDMODES will be realized if
(a) You are computing more than 500 or 1000 modes - Here Lanczos is typically very compute intensive
(b) You are running in a distributed computing environment (even on a single node with the assumption that you have multiple disks in a RAID0 configuration. This is needed for supporting I/O throughput required when MPI instances are spawned by nastran
Thanks for the explanation. Very useful and much appreciated. Will "close" the question very soon