Mechanical APDL Basic Analysis Guide - Ansys

Mechanical APDL Basic Analysis Guide - Ansys Mechanical APDL Basic Analysis Guide - Ansys

www1.ansys.com
from www1.ansys.com More from this publisher
15.11.2012 Views

Chapter 5: Solution standing how memory is used by each solver can help you to avoid problems (such as running out of memory during solution) and maximize the problem size you can handle on your system. 5.3.1. Running ANSYS Solvers under Shared Memory One of the easiest ways to improve ANSYS solvers' performance is to run the solvers on a shared memory architecture, using multiple processors on a single machine. For detailed information on using the shared memory architecture, see Activating Parallel Processing in a Shared-Memory Architecture in the Advanced Analysis Techniques Guide. The sparse solver has highly tuned computational kernels that are called in parallel for the expensive matrix factorization. The PCG solver has several key computation steps running in parallel. For the PCG and sparse solvers, there is typically little performance gain in using more than four processors for a single ANSYS job. See "Using Shared-Memory ANSYS" in the Advanced Analysis Techniques Guide or the Distributed ANSYS Guide for more information on using ANSYS' parallel processing capabilities. 5.3.2. Using ANSYS' Large Memory Capabilities with the Sparse Solver If you run on a 64-bit workstation or server with at least 8 GB of memory and you use the sparse solver, you can take advantage of ANSYS' large memory capabilities. The biggest performance improvement comes for sparse solver jobs that can use the additional memory to run in-core (meaning that the large LN09 file produced by the sparse solver is kept in memory). You will generally need 10 GB of memory per million degrees of freedom to run in-core. Modal analyses that can run in-core using 6 to 8 GB of memory (500K - 750K DOFs for 100 or more eigenmodes) will show at least a 30 - 40% improvement in time to solution over a 2 GB system. You can configure memory for sparse solve in-core runs explicitly using the BCSOPTION command, but the easiest way to access this capability is to increase the initial ANSYS memory allocation so that the amount of memory available to the sparse solver exceeds the in-core memory requirement. The performance improvement over a 32-bit system configured with nominal I/O performance can be even more significant when the sparse solver memory requirement for optimal out-of-core operation is larger than a 32-bit system can allocate. In such cases, I/O for the sparse solver factorization can increase factorization time tenfold on 32-bit systems compared to larger memory systems that run either in optimal out-of-core mode or in-core. An important factor in big memory systems is system configuration. You will always see the best ANSYS performance with processor/memory configurations that maximize the memory per node. An 8-processor, 64 GB system is much more powerful for large memory jobs than a 32-processor 64 GB system. ANSYS cannot effectively use 32 processors for one job but can use 64 GB very effectively to increase the size of models and reduce solution time. You will see the best performance for jobs that run comfortably within a given system configuration. For example, a sparse solver job that requires 7500 MB on a system with 8 GB will not run as well as the same job on a 12-16 GB system. Large memory systems use their memory to hide I/O costs by keeping files resident in memory automatically, so even jobs too large to run in-core benefit from large memory. All ANSYS software supports large memory usage. It is recommended for very large memory machines where you can run a large sparse solver job in-core (such as large modal analysis jobs) for the greatest speed and efficiency. To use this option: 1. Increase the initial ANSYS memory allocation via -m (for example, -m 24000). This initial memory setting should be larger than what the sparse solver actually requires to account for memory used prior to the sparse solver. 2. You can further refine sparse solver memory using the BCSOPTION command. 104 Release 13.0 - © SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.

5.3.3. Disk Space (I/O) and Postprocessing Performance for Large Memory Problems I/O performance with large memory One of the hidden system benefits of large memory systems is the ability to cache large I/O requests. Even for modest-sized ANSYS jobs, you can considerably reduce the cost of I/O when the system free memory is larger than the sum of file sizes active in an ANSYS job. This feature, often called buffer cache, is a system-tunable parameter and can effectively move all I/O traffic to memory copy speeds. The system details are different for various vendors; consult your hardware manufacturer for details on their systems. For most Linux versions and Windows X64 systems, the benefit of the system buffer cache is automatic and does not require tuning. IBM and HP system caches may require some tuning; consult your hardware vendor for details. A large memory system will often perform at almost in-core memory performance with the sparse solver when the system memory size is larger than the matrix factorization file (usually file.LN09 or file.LN07), even when the sparse solver runs in out-of-core mode. 5.3.4. Memory Usage on Windows 32-bit Systems If you are running on a 32-bit Windows system, you may encounter memory problems due to Windows' handling of contiguous memory blocks. Windows 32-bit systems limit the maximum continuous block of memory to 2 GB; setting the /3GB switch will add another gigabyte of memory, but not contiguous with the initial 2 GB. (See the ANSYS, Inc. Windows Installation Guide for information on setting the /3GB switch). Running the PCG solver with the /3GB switch set will be sufficient in many situations, as will running the sparse solver with a reasonably large -db setting and a -m setting of just 50 MB more than the -db setting. However, to maximize your system's performance for large models, you need to: 1. Learn the largest -m you can use on your machine. 2. Learn how much memory solving your job will require. 3. Optimize your job and your system to take advantage of your system's capabilities. Learn your -m limits To find out the largest -m setting you can use on your machine, use the following procedure. The maximum number you come up with will be the upper bound on the largest contiguous block of memory you can get on your system. 1. Open a command window and type: ansys130 -m 1200 -db 64. 2. If that command successfully launches ANSYS, close ANSYS and repeat the above command, increasing the -m value by 50 each time, until ANSYS issues an error message that it has insufficient memory and fails to start. Be sure to specify the same -db value each time. Ideally, you will be able to successfully launch ANSYS with a -m of 1700 or more, although 1400 is more typical. A -m of 1200 indicates that you may have some DLLs in your user space; contact your system administrator for suggestions on cleaning up your user space. Learn your memory requirements ANSYS offers the BCSOPTION command to determine how much memory your job will require (when running the shared-memory sparse solver). Use this command as a habit to determine how much memory you need, and set your -m and -db appropriately. Too little memory, and your job will not run. However, setting an unnecessarily high -m will prevent ANSYS from using available memory to reduce I/O time. To use this command, add the following to your input: BCSOPTION,,,,,,PERFORMANCE 5.3.4. Memory Usage on Windows 32-bit Systems Release 13.0 - © SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates. 105

5.3.3. Disk Space (I/O) and Postprocessing Performance for Large Memory<br />

Problems<br />

I/O performance with large memory One of the hidden system benefits of large memory systems is the<br />

ability to cache large I/O requests. Even for modest-sized ANSYS jobs, you can considerably reduce the cost<br />

of I/O when the system free memory is larger than the sum of file sizes active in an ANSYS job. This feature,<br />

often called buffer cache, is a system-tunable parameter and can effectively move all I/O traffic to memory<br />

copy speeds. The system details are different for various vendors; consult your hardware manufacturer for<br />

details on their systems. For most Linux versions and Windows X64 systems, the benefit of the system buffer<br />

cache is automatic and does not require tuning. IBM and HP system caches may require some tuning; consult<br />

your hardware vendor for details. A large memory system will often perform at almost in-core memory<br />

performance with the sparse solver when the system memory size is larger than the matrix factorization file<br />

(usually file.LN09 or file.LN07), even when the sparse solver runs in out-of-core mode.<br />

5.3.4. Memory Usage on Windows 32-bit Systems<br />

If you are running on a 32-bit Windows system, you may encounter memory problems due to Windows'<br />

handling of contiguous memory blocks. Windows 32-bit systems limit the maximum continuous block of<br />

memory to 2 GB; setting the /3GB switch will add another gigabyte of memory, but not contiguous with the<br />

initial 2 GB. (See the ANSYS, Inc. Windows Installation <strong>Guide</strong> for information on setting the /3GB switch).<br />

Running the PCG solver with the /3GB switch set will be sufficient in many situations, as will running the<br />

sparse solver with a reasonably large -db setting and a -m setting of just 50 MB more than the -db setting.<br />

However, to maximize your system's performance for large models, you need to:<br />

1. Learn the largest -m you can use on your machine.<br />

2. Learn how much memory solving your job will require.<br />

3. Optimize your job and your system to take advantage of your system's capabilities.<br />

Learn your -m limits To find out the largest -m setting you can use on your machine, use the following<br />

procedure. The maximum number you come up with will be the upper bound on the largest contiguous<br />

block of memory you can get on your system.<br />

1. Open a command window and type:<br />

ansys130 -m 1200 -db 64.<br />

2. If that command successfully launches ANSYS, close ANSYS and repeat the above command, increasing<br />

the -m value by 50 each time, until ANSYS issues an error message that it has insufficient memory and<br />

fails to start. Be sure to specify the same -db value each time.<br />

Ideally, you will be able to successfully launch ANSYS with a -m of 1700 or more, although 1400 is more<br />

typical. A -m of 1200 indicates that you may have some DLLs in your user space; contact your system administrator<br />

for suggestions on cleaning up your user space.<br />

Learn your memory requirements ANSYS offers the BCSOPTION command to determine how much<br />

memory your job will require (when running the shared-memory sparse solver). Use this command as a<br />

habit to determine how much memory you need, and set your -m and -db appropriately. Too little memory,<br />

and your job will not run. However, setting an unnecessarily high -m will prevent ANSYS from using available<br />

memory to reduce I/O time. To use this command, add the following to your input:<br />

BCSOPTION,,,,,,PERFORMANCE<br />

5.3.4. Memory Usage on Windows 32-bit Systems<br />

Release 13.0 - © SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information<br />

of ANSYS, Inc. and its subsidiaries and affiliates.<br />

105

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!