You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the above examples all threads on each -- we are effectively allowing the OS to schedule the threads on the available set of cores as it sees fit.
492
492
This often gives the best performance, however sometimes it is beneficial to bind threads to explicit cores.
493
493
494
-
The OpenMP threading runtime provides additional options for controlling the pinning of threads to the cores assinged to each MPI rank.
494
+
The OpenMP threading runtime provides additional options for controlling the pinning of threads to the cores assigned to each MPI rank.
495
495
496
496
Use the `--omp` flag with `affinity.mpi` to get more detailed information about OpenMP thread affinity.
497
497
For example, four MPI ranks on one node with four cores and four OpenMP threads:
@@ -580,7 +580,7 @@ The approach is to:
580
580
1. first allocate all the resources on each node to the job;
581
581
2. then subdivide those resources at each invocation of srun.
582
582
583
-
If Slurm believes that a request for resources (cores, gpus, memory) overlaps with what another step has already allocated, it will defer the execution until the resources are relinquished.
583
+
If Slurm believes that a request for resources (cores, GPUs, memory) overlaps with what another step has already allocated, it will defer the execution until the resources are relinquished.
584
584
This must be avoided.
585
585
586
586
First ensure that *all* resources are allocated to the whole job with the following preamble:
Copy file name to clipboardExpand all lines: docs/services/cicd.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -718,7 +718,7 @@ Private projects will always get as notification a link to the CSCS pipeline ove
718
718
To view the CSCS pipeline overview for a public project and restart / cancel jobs, follow these steps:
719
719
720
720
* Copy the web link of the CSCS CI status of your project and remove the from the link the `type=gitlab`.
721
-
*Alternativily, assemble the link yourself, it has the form `https://cicd-ext-mw.cscs.ch/ci/pipeline/results/<repository_id>/<project_id>/<pipeline_nb>` (the IDs can be found on the Gitlab page of your mirror project).
721
+
*Alternatively, assemble the link yourself, it has the form `https://cicd-ext-mw.cscs.ch/ci/pipeline/results/<repository_id>/<project_id>/<pipeline_nb>` (the IDs can be found on the Gitlab page of your mirror project).
722
722
* Click on `Login to restart jobs` at the bottom right and login with your CSCS credentials
723
723
* Click `Cancel running` or `Restart jobs` or cancel individual jobs (button next to job's name)
724
724
* Everybody that has at least *Manager* access can restart / cancel jobs (access level is managed on the CI setup page in the Admin section)
@@ -783,7 +783,7 @@ This is the clone URL of the registered project, i.e. this is not the clone URL
783
783
### `ARCH`
784
784
value: `x86_64`or `aarch64`
785
785
786
-
This is the architecture of the runner. It is either an ARM64 machine, i.e. `aarch64`, or a traditinal `x86_64` machine.
786
+
This is the architecture of the runner. It is either an ARM64 machine, i.e. `aarch64`, or a traditional `x86_64` machine.
787
787
788
788
789
789
## Runners reference
@@ -819,7 +819,7 @@ Accepted variables are documented at [Slurm's srun man page](https://slurm.sched
819
819
820
820
!!! Warning "SLURM_TIMELIMIT"
821
821
Special attention should go the variable `SLURM_TIMELIMIT`, which sets the maximum time of your Slurm job.
822
-
You will be billed the nodehours that your CI jobs are spending on the cluster, i.e. you want to set the `SLURM_TIMELIMIT` to the maximum time that you expect the job to run.
822
+
You will be billed the node hours that your CI jobs are spending on the cluster, i.e. you want to set the `SLURM_TIMELIMIT` to the maximum time that you expect the job to run.
823
823
You should also pay attention to wrap the value in quotes, because the gitlab-runner interprets the time differently than Slurm, when it is not wrapped in quotes, i.e. This is correct:
824
824
```
825
825
SLURM_TIMELIMIT: "00:30:00"
@@ -867,7 +867,7 @@ The value must be a valid JSON array, where each entry is a string.
867
867
868
868
It is almost always correct to wrap the full value in single-quotes.
869
869
870
-
It is also possible to define the argument's values as an entry in `variables`, and then reference in `DOCKER_BUILD_ARGS` only the variables that you want to expose to the build process, i.e. sth like this:
870
+
It is also possible to define the argument's values as an entry in `variables`, and then reference in `DOCKER_BUILD_ARGS` only the variables that you want to expose to the build process, i.e. something like this:
871
871
```yaml
872
872
my job:
873
873
extends: .container-builder-cscs-gh200
@@ -987,7 +987,7 @@ This tag is mandatory.
987
987
##### `GIT_STRATEGY`
988
988
Optional variable, default is `none`
989
989
990
-
This is a [default Gitlab variable](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#git-strategy), but mentioned here explicitly, because very often you do not need to clone the repository sourcecode when you run your containerized application.
990
+
This is a [default Gitlab variable](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#git-strategy), but mentioned here explicitly, because very often you do not need to clone the repository source code when you run your containerized application.
991
991
992
992
The default is `none`, and you must explicitly set it to `fetch` or `clone` to fetch the source code by the runner.
993
993
@@ -1323,7 +1323,7 @@ The easiest way to use the FirecREST scheduler of ReFrame is to use the configur
1323
1323
In case you want to run ReFrame for a system that is not already available in this directory, please open a ticket to the Service Desk and we will add it or help you update one of the existing ones.
1324
1324
1325
1325
Something you should be aware of when running with this scheduler is that ReFrame will not have direct access to the filesystem of the cluster so the stage directory will need to be kept in sync through FirecREST.
1326
-
It is recommended to try to clean the stage directory whenever possible with the [postrun_cmds](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postrun_cmds) and [postbuild_cmds](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postbuild_cmds) and to avoid [autodetection of the processor](https://reframe-hpc.readthedocs.io/en/stable/config_reference.html#config.systems.partitions.processor) in each run.
1326
+
It is recommended to try to clean the stage directory whenever possible with the [`postrun_cmds`](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postrun_cmds) and [`postbuild_cmds`](https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.postbuild_cmds) and to avoid [autodetection of the processor](https://reframe-hpc.readthedocs.io/en/stable/config_reference.html#config.systems.partitions.processor) in each run.
1327
1327
Normally ReFrame stores these files in `~/.reframe/topology/{system}-{part}/processor.json`, but you get a "clean" runner every time.
1328
1328
You could either add them in the configuration files or store the files in the first run and copy them to the right directory before ReFrame runs.
0 commit comments