HPCE/gitea-pages
HPCE/gitea-pages
0
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Activity

Add Gothic

Browse Source
This commit is contained in:
caubet_m 2022-08-22 18:25:57 +02:00
parent 5e055979f9
commit 0d606942ec
1 changed files with 24 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
pages/merlin6/05-Software-Support/gothic.md
View File

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