Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
doku:cfd [2021/10/22 08:56] – sfrank | doku:cfd [2022/12/20 14:33] – [Graphical User Interface] ir | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Engineering ====== | + | ====== Engineering |
* [[https:// | * [[https:// | ||
Line 5: | Line 5: | ||
* [[https:// | * [[https:// | ||
* [[https:// | * [[https:// | ||
- | |||
- | ===== ABAQUS 2016 ===== | ||
- | |||
- | ==== Checkpointing and restart ==== | ||
- | |||
- | Users sometimes find that their jobs take longer than the maximaum runtime permitted by the scheduler to complete. Providing that your model does not automatically re-mesh (for example, after a fracture), you may be able to make use of Abaqus’ built-in checkpointing function. | ||
- | |||
- | This will create a restart file (.res file extension) from which a job that is killed can be restarted. | ||
- | |||
- | - Activate the restart feature by adding the line: | ||
- | |||
- | < | ||
- | *restart, write | ||
- | </ | ||
- | at the top of your input file and run your job as normal. It should produce a restart file with a .res file extension. | ||
- | |||
- | < | ||
- | < | ||
- | |||
- | < | ||
- | abaqus job=jobName oldjob=oldjobName ... | ||
- | </ | ||
- | where oldJobName is the initial input file and newJobName is a file which contains only the line: | ||
- | |||
- | < | ||
- | *restart, read | ||
- | </ | ||
- | |||
- | |||
- | ---- | ||
- | |||
- | ===== ABAQUS 2016 ===== | ||
- | |||
- | ==== Checkpointing and restart ==== | ||
- | |||
- | Example: | ||
- | |||
- | INPUT: [[examples/ | ||
- | |||
- | JOB SCRIPT: [[examples/ | ||
- | |||
- | INPUT FOR RESTART: [[examples/ | ||
- | |||
- | |||
- | ---- | ||
- | |||
- | ====== COMSOL ====== | ||
- | |||
- | The following case is provided here including the directories-structure\\ | ||
- | and the appropriate batch-file: {{ : | ||
- | |||
- | ===== Module ===== | ||
- | |||
- | Available version of Comsol can be found by executing the following line: | ||
- | |||
- | < | ||
- | module avail 2>&1 | grep -i comsol | ||
- | </ | ||
- | Currently these versions can be loaded: | ||
- | * Comsol/5.5 | ||
- | * Comsol/5.6 | ||
- | |||
- | < | ||
- | module load *your preferred module* | ||
- | </ | ||
- | |||
- | ---- | ||
- | |||
- | ===== Workflow ===== | ||
- | |||
- | In general you define your complete case on your local machine and save it as *.mph file.\\ This file contains all necessary information to run a successfull calculation on the cluster. | ||
- | |||
- | ---- | ||
- | |||
- | ===== Job script ===== | ||
- | |||
- | An example of a Job script is shown below. | ||
- | |||
- | < | ||
- | #!/bin/bash | ||
- | # slurmsubmit.sh | ||
- | |||
- | #SBATCH --nodes=1 | ||
- | #SBATCH --ntasks-per-node=24 | ||
- | #SBATCH --job-name=" | ||
- | #SBATCH --partition=mem_0384 | ||
- | #SBATCH --qos=mem_0384 | ||
- | |||
- | module purge | ||
- | module load Comsol/5.6 | ||
- | |||
- | MODELTOCOMPUTE=" | ||
- | path=$(pwd) | ||
- | |||
- | INPUTFILE=" | ||
- | OUTPUTFILE=" | ||
- | BATCHLOG=" | ||
- | |||
- | echo " | ||
- | echo $INPUTFILE | ||
- | echo " | ||
- | echo $OUTPUTFILE | ||
- | echo " | ||
- | echo $BATCHLOG | ||
- | echo "and the usual slurm...out" | ||
- | |||
- | # COMSOL' | ||
- | comsol batch -mpibootstrap slurm -inputfile ${INPUTFILE} -outputfile ${OUTPUTFILE} -batchlog ${BATCHLOG} -alivetime 15 -recover -mpidebug 10 | ||
- | </ | ||
- | |||
- | ==== Possible IO-Error ==== | ||
- | |||
- | COMSOL is generating a huge amount of temporary files during the calculation. These files in general got saved in '' | ||
- | To get rid of this error just expand the comsol command in the job script by the following option: | ||
- | < | ||
- | -tmpdir "/ | ||
- | </ | ||
- | |||
- | ===== Submit job ===== | ||
- | |||
- | < | ||
- | sbatch karman.job | ||
- | </ | ||
- | |||
- | ==== Using a shared node ==== | ||
- | |||
- | If your case isn't that demanding on hardware and you are interested in a fast solution, it is possible to use one of the shared nodes. These are non-exclusive nodes, thus more than just one job is able to use the provided hardware. | ||
- | On these nodes you have to tell SLURM, how much memory (RAM) your case would need. This value should be less than the maximum of 96GB these nodes uses. Otherwise your job needs a whole node anyway. | ||
- | Here we use --mem=20G, to dedicate 20GB of memory. | ||
- | |||
- | < | ||
- | #!/bin/bash | ||
- | # slurmsubmit.sh | ||
- | |||
- | #SBATCH -n 1 | ||
- | #SBATCH --ntasks-per-node=1 | ||
- | #SBATCH --job-name=" | ||
- | #SBATCH --qos=mem_0096 | ||
- | #SBATCH --mem=20G | ||
- | |||
- | hostname | ||
- | |||
- | module purge | ||
- | module load Comsol/5.6 | ||
- | module list | ||
- | . | ||
- | . | ||
- | . | ||
- | </ | ||
- | |||
- | |||
- | ---- | ||
- | |||
- | |||
- | |||
- | {{ : | ||
- | |||
- | |||
- | ---- | ||
+ | ====== Graphical User Interface ====== | ||
+ | read here [[https:// |