Partner Channel / Creo Simulate

The biggest influences on performance are the amount of RAM in your machine and how that RAM is used by Mechanica/Simulate. The amount of memory that is used during an analysis depends on several factors, including the complexity of the model, the desired accuracy of the solution, and the type of analysis or design study you are running. You can see how much total memory an analysis takes by looking at the bottom of the Summary tab of the Run Status dialog. The line you're looking for looks like this:

Maximum Memory Usage (kilobytes): XXXX

If the maximum memory usage of Mechanica plus the memory used by the OS, and the other applications exceeds, the amount of RAM in your machine, then the operating system (OS) will swap data between RAM and the hard disk, which seriously degrades the performance of your applications. Thus, to achieve maximum performance, you want to make sure that the maximum memory usage is less than the amount of RAM in your machine. For very large models, the thing that requires the most memory during an analysis is the global stiffness matrix. You can see how big the global stiffness matrix is by looking on the Checkpoints tab of the Run Status dialog box (also in the .pas file in the study directory). The line you're looking for is:

Size of global matrix profile (mb):

Mechanica allows you to limit the amount of memory that the global stiffness matrix will consume by setting the Memory Allocation field in the Solver Settings area of the Run Settings dialog. We often call this Memory Allocation setting "solRAM". With this setting, you allocate a fixed amount of memory in which to hold slices of the global stiffness matrix that the linear equation solver works with at any one time. If the global stiffness matrix is too big to fit in solRAM, then Mechanica will swap part of the matrix back and forth between disk and RAM using an specialized swapping algorithm that is more efficient than the general swapping algorithm used by the OS.
This document contains information how to set the default solRAM giving three different scenarios of how Mechanica uses memory during an analysis. The document also contains speed-up tips to improve performance, and some disk usage guide lines.

Share on Social Networks

Share Link

Use permanent link to share in social media

Share with a friend

Please login to send this document by email!

Embed in your website

Select page to start with

1. R AM and SolRAM in Creo Simulate The biggest influences on performance are the amount of RAM in your machine and how that RAM is used by Mechanica/Simulate. The amount of memory that is used during an analysis depends on several factors, including the complexity of the model, the desired accuracy of the solution, and the type of analysis or design study you are running. You can see how much total memory an ana lysis takes by looking at the bottom of the Summary tab of the Run Status dialog. The line you're looking for looks like this: Maximum Memory Usage (kilobytes): XXXX If the maximum memory usage of Mechanica plus the memory used by the OS , and the other applications exceeds , the amount of RAM in your machine, then the operating system (OS) will swap data between RAM and the hard disk, which seriously degrades the performance of your applications. Thus, to achieve maximum performance, you want to make sure that the maximum memory usage is less than the amount of RAM in your machine. For very large models, the thing that requires the most memory during an analysis is the global stiffness matrix. You can see how big the global stiffness matrix is by looking on the Checkpoints tab of the Run Status dialog box (also in the .pas file in the study directory). The line you're looking for is Size of global matrix profile (mb): Mechanica allows you to limit the amount of memory that the global stiffness matrix w ill consume by setting the Memory Allocation field in the Solver Settings area of the Run Settings dialog. We often call this Memory Allocation setting " sol RAM ". With this setting, you allocate a fixed amount of memory in which to hold slices of the global stiffness matrix that the linear equation solver works with at any one time. If the global stiffness matrix is too big to fit i n solRAM , then Mechanica will swap part of the matrix back and forth between disk and RAM using an specialized swapping al gorithm that is more efficient than the general swapping algorithm used by the OS.

5. Disk Usage The other major factor that influences performance is disk usage. During an analysis, Mechanica writes all of its results to disk. Also, Mechanica temporarily stores on disk intermediate data that is required during the analysis. Although we haven't done detailed studies to determine their actual impact, the following guidelines should help improve performance. Make sure you are not using any drives that are mounted across the network. Us e drives that have a generous amount of empty space on them. Occasionally defragment your disks so that data can be written and read in large contiguous blocks. Use fast hard drives. Use disk striping with a redundant array of independent disks (RAID) to increase IO performance. Use a RAM disk instead of a hard disk. Use a solid - state drive instead of a hard disk drive. o sim_run_out_dir d: \ femwork o sim_run_tmp_dir d: \ temp Hyper - threading There is no benefit to using hyper - threading. Parallel Processing F or very large models, the most time consuming part of a Mechanica analysis is solving the global stiffness matrix equations. For this part of the analysis, Mechanica uses, by default, all of the available CPU cores for multiprocessing, up to a limit of 64 cores. Today, there are a few other parts of the analysis where Mechanica uses multiple cores and we plan to expand multiprocessing to other parts of the analysis in the future. You can edit the number of used processors with config.pro setting sim_run_num_threads (all) . Monitoring Solver and Memory Use E fficiency In windows operating systems you can use perfmon.exe to check the memory and CPU resource use.

4. In this scenario, the analysis will run slowly because the operating system will swap data. If this occurs , it's better to decrease solram so that memory that Mechanica uses remains in RAM, as shown below Available memory : RAM swap | -------------------------------------------- ------- | ----------------------------------------------------- | Used by Mechanica: DB K ***********************(######)########## OK sol RAM DB + solRAM < RAM good (no OS swapping) K > solRAM not so good (matrix equations will be swapped) This is the same as scenario II above. Speedup tips There are few other things to keep in mind: If you use a 32 - bit Window OS the maximum amount of memory that any one application can use is 3.2 GB. Sol RAM is currently limited to a maximum of 16 GB (Creo Simulate 2.0). Here are some guidelines that you can follow to improve performance: Run on a machine with a 64 - bit OS and l ots of RAM. Exit other applications, so that Mechanica can use as much RAM as possible. Set solRAM low enough so that the total memory used by Mechanica is less than your total amount of RAM. If p ossible, set solRAM high enough so that the global stiffness matrix fits in solRAM (but don't violate guideline #3)

3. Available memory: RAM swap | --------------------------------------------------- | ----------------------------------------------------- | Used by Mechanica: DB K ****************(#########)## OK sol RAM DB + solRAM < RAM good (no OS swapping) K > solRAM not so good (matrix equations will be swapped) In this case, the part of K which does not fit in solRAM , shown above as # # #, will be swapped to disk with specialized, efficient Mechanica code. In t his scenario, the size of solRAM has some, but not a large , effect on the performance of the analysis. In general, the larger solRAM is, the faster the global stiffness matrix equa tions will be solved, as long as the total memory used fits in RAM. Scenario III The worst case scenario is when the total memory used by Mechanica does not fit in RAM. If the total memory allocated by Mechanica (and all of the other processes running on your machine) exceeds the total RAM of your machine, then the operating system will swap data. Available memory: RAM swap | --------------------------------------------------- | ----------------------------------------------------- | Used by Mechanica: DB K ***********************(################ ---- ) Bad solram DB + solram > RAM bad (OS will swap data) K < solram doesn't really matter

2. Set Default SolRAM To set the default sol RAM you may use config.pro setting sim_solver_memory_allocation . Three scenarios of how Mechanica uses memory during an analysis . Scenario I Mechanica runs most efficiently when the entire global stiffness matrix fits in sol RAM and when the total memory used by Mechanica fits in RAM. For example, suppose you have a machine with 4 GB of RAM and 4 GB of disk allocated to swap space. You run an analysis which needs 1 GB for the global stiffness matrix, K, and 2 GB for everything else, which I'll call DB. If you set solRAM to 1.5 GB, then, ignoring the RAM used by the operating system and other applications, the memory usage looks like this. Available memory: RAM swap | --------------------------------------- ------------ | ----------------------------------------------------- | Used by Mechanica: DB K ****************(######## ---- ) Ideal situation sol RAM DB + solRAM < RAM good (no OS swapping) K < solRAM good (no matrix equation swapping) In the example above, the m emory used by DB is shown as ** *, the memory used by K is shown as ###, and the memory allocated to sol RAM is inside parentheses (### -- ). Because K is sm aller than solRAM , there is some me mory that is allocated to solRA; that is unused, shown as --- . This is an ideal situation because the K < solram and DB + solram < RAM and hence, no swapping will occur. Scenario II The next most efficient scenario is when the entire amount memory used by Mechanica still fits in RAM, but the global stiffne ss matrix does not fit in solRAM .

Views

  • 55 Total Views
  • 39 Website Views
  • 16 Embeded Views

Actions

  • 0 Social Shares
  • 0 Likes
  • 0 Dislikes
  • 0 Comments

Share count

  • 0 Facebook
  • 0 Twitter
  • 0 LinkedIn
  • 0 Google+

Embeds 1

  • 2 185.254.80.137