Add Gothic
This commit is contained in:
parent
5e055979f9
commit
0d606942ec
@ -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.
|
||||
|
Loading…
x
Reference in New Issue
Block a user