Determine computational resources needed to solve solution?

Experimenter
Experimenter

Hello,

 

Often times people state that Degrees of Freedom are a good indicator in how long it will take to solve a solution. I'm running a bunch of simple tests (comparing different solid elements) and i'm trying to find information in the .log, .f04, or .f06 files that I can compare across different analyses to see how computationaly intensive each one is. I know that the .log file states the number of degrees of freedom at the end, however I don't find that this is detailed enough. You get the same DOF for a solution using Reduced integration elements as you do Full integration elements (which makes sense). Is there information that shows that number of integration points, size of the stiffness matrix, etc? I want something that can be used to compare my solution accuracy to their size (previous I was using DOF). 

 

Thank you.

3 REPLIES 3

Re: Determine computational resources needed to solve solution?

Siemens Phenom Siemens Phenom
Siemens Phenom

For a linear solution, decomp will typically be the most expensive step. Detailed information for this can be found in the .f04 file.

 

If you are running with the default sparse solver, look for the DCMP (DeCoMP) module output. It will document the information you are looking for, i.e.:

 

  9:22:51     0:00      981.0         0.0         0.3        0.0    SEKRRS  186     DCMP    BEGN    
 *** USER INFORMATION MESSAGE 4157 (DFMSYN)
     PARAMETERS FOR PARALLEL SPARSE DECOMPOSITION OF DATA BLOCK KLL     ( TYPE=RSP ) FOLLOW
                      MATRIX SIZE =     1728 ROWS             NUMBER OF NONZEROES =       14850 TERMS
           NUMBER OF ZERO COLUMNS =        0        NUMBER OF ZERO DIAGONAL TERMS =        0
                     SYSTEM (107) =   32770                      REQUESTED PROC. =       2 CPUS
     User information:
     When spill is indicated, the model is too large to fit into memory.
     The job may run faster by increasing the available memory (this will
     decrease the number of spill groups).
     See the NASTRAN Installation and Operation Instructions for a
     description of these terms. See also  the NASTRAN Numerical
     Methods User's Guide.
                CPU TIME ESTIMATE =        0 SEC                I/O TIME ESTIMATE =           0 SEC
       MINIMUM MEMORY REQUIREMENT =     1488 KB                  MEMORY AVAILABLE =     9012944 KB
     MEMORY REQR'D TO AVOID SPILL =     2520 KB              MEMORY USED BY MMD   =          96 KB
     EST. INTEGER WORDS IN FACTOR =       26 K WORDS           EST. NONZERO TERMS =          54 K TERMS
     ESTIMATED MAXIMUM FRONT SIZE =       60 TERMS                 RANK OF UPDATE =         128
 *** USER INFORMATION MESSAGE 6439 (DFMSA)
     ACTUAL MEMORY AND DISK SPACE REQUIREMENTS FOR SPARSE SYM. DECOMPOSITION
     User information:
     This message is issued in the .F04 file after decomposition.
     It tells how much memory and desk space were actually required.
        SPARSE DECOMP MEMORY USED =     2520 KB                MAXIMUM FRONT SIZE =          60 TERMS  
          INTEGER WORDS IN FACTOR =        5 K WORDS      NONZERO TERMS IN FACTOR =          54 K TERMS
   SPARSE DECOMP SUGGESTED MEMORY =     2520 KB
 *8** Module  DMAP Matrix         Cols       Rows  F T  IBlks  NBlks NumFrt FrtMax 
      DCMP    186  LLL            1728       1728 13 1      1      2    154     60 *8**
 *8** Module  DMAP Matrix         Cols       Rows  F T     NzWds     Density  BlockT  StrL    NbrStr    BndAvg    BndMax    NulCol
      DCMP    186  SCR 301           1       1728  2 1      1728 1.00000E+00       3  1728          1       1728       1728         0 *8**
      DCMP    186  SCR 302           1       1728  2 1      1728 1.00000E+00       3  1728          1       1728       1728         0 *8**
  9:22:51     0:00      981.0         0.0         0.3        0.0    SEKRRS  186     DCMP    END     

Some notes on the above output:

  1. The lowercase "User information" text is inserted because extended messaging is activated via SYSTEM(319)=1
  2. The 5 lines with a "*8** prefix or suffix are inserted because DIAG 8 is active. This prints these matrix trailers to the .f04 at the point a matrix is created

 

Other solvers (i.e. Pardiso, element iterative) or solutions (i.e. eigenvalue) will print similar information to the .f04. The format is specific to the solver/solution sequence.

 

For iterative or nonlinear solutions, matrix decomp is not necessarily the best indicator of solution time. Number of iterations/time steps/bisections typically dictate overall time, but these are unknown prior to solving.

 

 

Re: Determine computational resources needed to solve solution?

Gears Phenom Gears Phenom
Gears Phenom

There are lot of additional features that can affect analysis time on same model: SOL type (linear/nonlinear), number of steps/frequencies in nonlinear/transient/modal/frequency response analysis, contact regions/contact search distance, nonlinear material, some Nonlinear solvers can split load step to achieve solution so number if iterations may be different due to convergence problems.

Therefore, I think that trying to predict solution time is useless exercise. Juts use your experience and common sense not to get unacceptable solution time.

Re: Determine computational resources needed to solve solution?

Experimenter
Experimenter
Thank you for the feedback!

To me honest, I'm not too interested in the actual run time but more so the computational effort needed to run said analysis. My main goal here is to have a comparison of different solid element combinations and how changing things like mesh density, layers, etc will impact the accuracy of the results. As a side detail i'd like to include tradeoffs such as computational time when comparing different elements and mesh densities. Whatever I find obviously can't be a rule that's always true but it would be good for me to examine the differences in accuracy vs difference in computational resources (which often is related to run time). I would use DOF as my basis but this doesn't show differences between Full integrated elements and reduced integrated elements. Something like total # of integration/gauss points could be useful for me but I'm: 1) not sure if that exists. 2) wondering if there's a better metric I can use.

Thank you once again.