From 0d606942ecc72d3daf9b83dd84ba314e18b83837 Mon Sep 17 00:00:00 2001 From: caubet_m Date: Mon, 22 Aug 2022 18:25:57 +0200 Subject: [PATCH] Add Gothic --- pages/merlin6/05-Software-Support/gothic.md | 47 +++++++++++---------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/pages/merlin6/05-Software-Support/gothic.md b/pages/merlin6/05-Software-Support/gothic.md index 5302942..5923a2f 100644 --- a/pages/merlin6/05-Software-Support/gothic.md +++ b/pages/merlin6/05-Software-Support/gothic.md @@ -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=` -or `-c ` is, in general, recommended. -`` 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=` +or `-c ` is in general recommended. +Notice that `` 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=` 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.