Add Gothic

This commit is contained in:
caubet_m 2022-08-22 18:25:57 +02:00
parent 5e055979f9
commit 0d606942ec

View File

@ -22,7 +22,7 @@ Multiple versions are available. As of August 22, 2022, the latest
installed version is **Gothic 8.3 QA**.
Future releases will be placed in the PSI Modules system, therefore,
loading it through PModules it will be possible. However, in the
loading it through PModules will be possible at some point. However, in the
meantime one has to use the existing installations present in
`/data/project/general/software/gothic`.
@ -30,7 +30,7 @@ meantime one has to use the existing installations present in
### General requirements
When running Gothic in interactive or batch mode, there has to consider
When running Gothic in interactive or batch mode, one has to consider
the following requirements:
* **Use always one node only**: Gothic runs a single instance.
@ -40,12 +40,12 @@ multiple nodes if the Slurm allocation definition is ambiguous.
* **Use one task only**: Gothic spawns one main process, which then will
spawn multiple threads depending on the number of available cores.
Therefore, one has to specify 1 task (`--ntasks=1` or `-n 1`).
* **Use multiple CPUs**: since Gothic will spawn multiple threads, then$
multiple CPUs can be used. Therefore, adding `--cpus-per-task=<num_cpus>`
or `-c <num_cpus>` is, in general, recommended.
`<num_cpus>` must never exceed the maximum number of CPUS in a compute
node (usually *88*).
* **Use multithread**: Gothic is a OpenMP based software, therefore,
* **Use multiple CPUs**: since Gothic will spawn multiple threads, then
multiple CPUs can be used. Adding `--cpus-per-task=<num_cpus>`
or `-c <num_cpus>` is in general recommended.
Notice that `<num_cpus>` must never exceed the maximum number of CPUS
in a compute node (usually *88*).
* **Use multithread**: Gothic is an OpenMP based software, therefore,
running in hyper-threading mode is strongly recommended. Use the option
`--hint=multithread` for enforcing hyper-threading.
* **[Optional]** *Memory setup*: The default memory per CPU (4000MB)
@ -55,19 +55,20 @@ can always set the `--mem=<mem_in_MB>` option. This is in general
### Interactive
In general, **is not allowed to run CPU intensive interactive jobs in the
**Is not allowed to run CPU intensive interactive jobs in the
login nodes**. Only applications capable to limit the number of cores are
allowed to run for longer time. Also, **running in the login nodes is not
efficient**, since resources are shared with other processes and users.
Is possible to submit interactive jobs to the cluster by allocating a
full compute node, or even by allocating a few cores only.
full compute node, or even by allocating a few cores only. This will grant
dedicated CPUs and resources and in general it will not affect other users.
In general, is strongly recommended use the `hourly` partition, which
in usually has a good availability of nodes.
For interactive jobs, is strongly recommended to use the `hourly` partition,
which usually has a good availability of nodes.
For longer runs, one should use the `daily` (or `general`) partition,
however, getting interactive access to nodes on these partitions is
For longer runs, one should use the `daily` (or `general`) partition.
However, getting interactive access to nodes on these partitions is
sometimes more difficult if the cluster is pretty full.
To submit an interactive job, consider the following requirements:
@ -78,9 +79,9 @@ using the Slurm option `--x11` is necessary.
one has to define a scratch area with the `GTHTMP` environment variable.
There are two options:
1. **Use local scratch**: Each compute node has its own `/scratch` area.
This is independent to any other node, therefore not visible by other nodes.
This area is independent to any other node, therefore not visible by other nodes.
Using the top directory `/scratch` for interactive jobs is the simplest way,
and it can be defined before or after the allocation creation:
and it can be defined before or after the allocation creation, as follows:
```bash
# Example 1: Define GTHTMP before the allocation
export GTHTMP=/scratch
@ -105,18 +106,18 @@ allocation! In example:
mkdir -p $GTHTMP
```
Creating sub-directories makes the process more complex, therefore
using just `/scratch` is simpler.
using just `/scratch` is simpler and recommended.
2. **Shared scratch**: Using shared scratch allows to have a
directory visible from all compute nodes and login nodes. Therefore,
one can use `/shared-scratch` to achieve the same as in **1.**, but
creating a sub-directory needs to be done just once.
However, `/scratch` usually provides better performance and in addition
will offload the main storage, therefore using **local scratch** is strongly
recommended, and only use the shared scratch when strongly necessary.
Please, consider that `/scratch` usually provides better performance and,
in addition, will offload the main storage. Therefore, using **local scratch**
is strongly recommended. Use the shared scratch only when strongly necessary.
* **Use the `hourly` partition**: Using the `hourly` partition is
recommended for running interactive jobs, since latency is in general
lower. However, `daily` and `general` are also available if you expect
recommended for running interactive jobs (latency is in general
lower). However, `daily` and `general` are also available if you expect
longer runs, but in these cases you should expect longer waiting times.
These requirements are in addition to the requirements previously described
@ -136,7 +137,7 @@ salloc --partition=hourly -N 1 -n 1 -c $num_cpus --hint=multithread
### Batch job
The Slurm cluster is in general used by non interactive batch jobs. Users
The Slurm cluster is mainly used by non interactive batch jobs: Users
submit a job, which goes into a queue, and waits until Slurm can assign
resources to it. In general, the longer the job, the longer the waiting time,
unless there are enough free resources to inmediately start running it.