HowTo:abaqus

Abaqus

This is a short help file on using the Finite-Element Analysis (FEA) code "Abaqus" on our machines. This software is only licensed for academic researchers who work at a university that is already covered by an Abaqus license. The software is only made available to persons who belong to a specific Unix group. See details below.

What is Abaqus ? The ABAQUS suite of software for finite element analysis (FEA) has the ability to solve a wide variety of simulations. The ABAQUS suite consists of three core products - ABAQUS/Standard, ABAQUS/Explicit and ABAQUS/CAE. ABAQUS/Standard is designed to solve traditional implicit finite element analyses, such as static, dynamics, and thermal. It is equipped with a wide range of contact and nonlinear material options. ABAQUS/Standard also has optional add-on and interface products, as well as integration with third party software. ABAQUS/Explicit is focused on transient dynamics and quasi-static analyses using an explicit approach appropriate in many applications such as drop test, crushing and many manufacturing processes. ABAQUS/CAE provides a modeling and visualization environment for ABAQUS analysis products. It offers access to CAD models, advanced meshing and visualization, and an exclusive view towards ABAQUS analysis products. ABAQUS/CAE is used mainly for pre- and post-processing. Note that this part of the ABAQUS software is not running on HPCVL machines, but on a user client machine. Version The most recent version of Abaqus on our systems is Abaqus 6.11. Earlier versions are available but not supported. Location and Access This software is only available on the Linux systems. All versions of the Abaqus package are located in the directory /opt/abaqus. To use Abaqus on our machines, you have to be covered by an academic Abaqus license outside of the Centre for Advanced Computing, i.e. you have to be a "licensed University User of Abaqus". It is furthermore required that you read through the Abaqus Licensing Policy, and sign a statement. Note that our license does count as a license for Queen's University. We will confirm your statement, and you will added to a Unix group "abaqus", which enables you to run the software. Contact us if you are in doubt of whether you will be able to run Abaqus on our system. We also will submit your name and affiliation to Abaqus Inc. for a check if a prior university license exists. Licensing The Fluent license is "seat limited" and "process limited". At present, there are the following licensing limits on our systems: 25 program runs plus 512 parallel processes i.e. at most 25 separate sessions can be run simultaneously (serial or parallel). Each of these sessions can run up to 4 processes for a total of 100. In addition, it is possible to run up to 512 "parallel only" processes in total. One scenario would be 24 users have 24 process parallel jobs running, and another one with 36, thus using up all available Fluent resources.

Running Fluent Setup Setup through the "usepackage" command: use abaqus will add the proper directories to the PATH and enable using the software. This needs to be done on the Linux workup node swlogin1. Interactive runs The following instructions assume that you are a member of the Unix group "abaqus". They pertain only to the Standard and Explicit components of the software. The instructions in this section are only useful if you want to run an interactive test job of Abaqus on the workup node. If you want to run a production job, please refer to to instructions on how to start a Abaqus batch job (see next section). The Abaqus program uses a sophisticated syntax to set up a job run. Instructions to the program are written into an input file which is specified when the program is evoked. While an input file can be written "from scratch", it is also possible to use the ABAQUS/CAE component to generate such a file. Both techniques a outside the scope of this FAQ. You also can have a look at a simple example input file here . Documentation for Abaqus is extensive, and available both electronically and in print. There is no substitute to consulting it. Assuming that we have an input file called testsys.inp, we can initiate a run: abaqus job=test001 inp=testsys.inp scratch=/scratch/hpcXXXX The job= option specified what the output files are to be called. They have various different "filename extensions" but share the name specified here (in our case test001). With the inp= option, we specify which input file to use. There are more options, such as cpus= and mp_mode= for running parallel jobs, but the two used above should get a simple serial job running. The above sequence starts the job in the background, i.e. after an initial setup phase, your terminal returns although the job is still running. If you want to avoid this, you can include the interactive option in the command line. The Abaqus software uses a directory in /tmp (which is local to the nodes on which the software is executing) as scratch space. This is the default setting and causes some Abaqus jobs to fail. It must therefore be changed to the standard scratch space /scratch/hpcXXXX (XXXX being the numbers in your username). This can be done by including the option scratch=/opt/hpcXXXX in your command line. Also, do not forget to occasionally check the contents of this scratch directory by typing (replacing XXXX with the proper numbers for your username): ls -lt /scratch/hpcXXXX and removing any files that might be left over from old Abaqus runs. This is necessary because Abaqus will not remove these files if a job was terminated before it ran to completion. More about changing the Abaqus environment may be learned from the "Installation and Licensing Guide" (chapter 4) of the Abaqus documentation. Please contact us if you need assistance. Batch runs In most cases, you will run Abaqus in batch mode. Most interactive work can be done elsewhere, whereas the computationally intensive runs are executed on the cluster. Production jobs are submitted on the systems via a scheduler. To obtain details, read our Gridengine help file. For an Abaqus batch job, this means that rather than issuing the above commands directly, you wrap them into a Grid Engine batch script that looks similar to this: #!/bin/bash #$ -S /bin/bash #$ -q abaqus.q #$ -l qname=abaqus.q #$ -V #$ -cwd #$ -be #$ -M {email address} # Defining output file #$ -o {output file} #$ -e {error file} export PATH="/opt/abaqus/6.11/Commands":$PATH export PATH="/bin":$PATH source /opt/ics/bin/compilervars.sh intel64 abaqus job={job name} input={input file} scratch=/scratch/{user name} -interactive This script needs to be altered by replacing all the relevant items in curly brackets by the right values. The -interactive option is necessary; without it the program will not start properly. The script can be submitted to the GridEngine by typing, e.g. qsub abaqus.sh Note that Abaqus needs to be set up correctly before submitting this script, as it inherits the settings of the submitting shell. Note that the usage of the scheduler for all production jobs is mandatory. Production jobs that are submitted outside of the load balancing software will be terminated by the system administrator. Parallel production runs The Abaqus jobs that you will want to run on our machines are likely to be quite large. To utilize parallelism, Abaqus offers to execute the solver on several CPU's simultaneously. The Abaqus software achieves a certain degree of parallel scaling using either shared- or distributed memory machines. Here is a list of operations with the corresponding parallel mode that Abaqus supports: Element operations - MPI only Iterative solver - MPI or threads Direct solver - Threads only Lanczos solver - Threads only Note that only the shared-memory parallelism is in use on our clusters. It is necessary to decide before a parallel Abaqus run which parallel mode (if any) is to be used (on our clusters, use "threads"), and how many processes are to be started. Production jobs must be submitted via the Grid Engine scheduling software. Here is an example script for a parallel submission: #!/bin/bash #$ -S /bin/bash #$ -q abaqus.q #$ -l qname=abaqus.q #$ -V #$ -cwd #$ -m be #$ -M {email address} #$ -o {output file} #$ -e {error file} #$ -pe shm.pe {number of processors} export PATH="/opt/abaqus/6.11/Commands":$PATH export PATH="/bin":$PATH source /opt/ics/bin/compilervars.sh intel64 abaqus job={job name} input={input file} scratch=/scratch/{username} cpus=$NSLOTS mp_mode=threads -interactive Note that Grid Engine allocates all processors on a single node. After altering the script by substituting the items enclosed in curly brackets, it is submitted by qsub batch_file_name Because of the limited number of cores, only 12-processor jobs can be run on most of the nodes. Also, the total memory of each node is limited, meaning that jobs with large memory requirements should request memory up-front to avoid getting scheduled on too small a node. Please contact us if you need help with this.

Further Help Fluent is a complex software package, and requires some practice to be used efficiently. In this FAQ we can not explain it use in any detail. The documentation for Fluent can be access from inside the program GUI by clicking on the "Help" button on the upper right. This is in html format. The pdf version of the docs can be found in /opt/fluent/ansys-16.0/v140/commonfiles/help/en-us/pdf Fluent documentation is subject to the same license terms as the software itself, i.e. you have to be signed up as a Fluent user in order to access it. If you are experiencing trouble running a batch command script, check carefully if the sequence of commands is exactly in sync with the program. This might mean typing them in interactively as a test. If you have problems with the Grid Engine, read our FAQ on that subject, and maybe consult the manual for that software which is accessible as a PDF file. HPCVL also provide user support in the case of technical problems: just send email to cac.help@queensu.ca.