Difference between revisions of "Applications/MIKE"
(→Batch Session) |
m (→Next Steps) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 33: | Line 33: | ||
</pre> | </pre> | ||
| − | Note the sample job above includes a 6 hour time limit. | + | Note the sample job above includes a 6-hour time limit. |
<pre style="background-color: black; color: white; border: 2px solid black; font-family: monospace, sans-serif;"> | <pre style="background-color: black; color: white; border: 2px solid black; font-family: monospace, sans-serif;"> | ||
| Line 43: | Line 43: | ||
===Scaling Tests=== | ===Scaling Tests=== | ||
| − | It is useful to carry out scaling tests when running MIKE so that appropriate resource is requested to run a job. While requesting fewer nodes will mean the longer the job will run | + | It is useful to carry out scaling tests when running MIKE so that appropriate resource is requested to run a job. While requesting fewer nodes will mean the longer the job will run, it is more likely that a job will start sooner the fewer nodes it requests. The sample job script above requests 16 nodes (448 cores). |
| − | The table below shows runtimes for a test job over different numbers of nodes. For this example, the 3 minutes gained using 32 nodes over 16 nodes, provides little benefit and other users would be better having access to the 16 additional nodes. With contention for | + | The table below shows runtimes for a test job over different numbers of nodes. For this example, the 3 minutes gained using 32 nodes over 16 nodes, provides little benefit and other users would be better having access to the 16 additional nodes. With contention for resources on Viper high, requesting 8 nodes would be a good compromise. |
It is useful to carry out scaling tests with any significant change in job type. | It is useful to carry out scaling tests with any significant change in job type. | ||
| Line 79: | Line 79: | ||
|} | |} | ||
| − | + | {{Licensepagenav}} | |
| − | |||
| − | |||
| − | { | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 11:21, 16 November 2022
Application Details
- Description: MIKE
- Version: 2017
- Modules: Private module available on request to appropriate license holders
- Licence: Limited license (The Energy and Environment Institute)
Usage Examples
Batch Session
#!/bin/bash #SBATCH -J MIKEjob #SBATCH -N 16 #SBATCH --ntasks-per-node=28 #SBATCH -o %j.log #SBATCH -e %j.err #SBATCH -p compute #SBATCH --time=0-06:00:00 module add use.own module add MIKE/2017 export OMP_NUM_THREADS=1 NP=$(( $SLURM_JOB_NUM_NODES * $SLURM_NTASKS_PER_NODE )) echo $NP "processes" mpirun -n $NP FemEngineHD model.m21fm
Note the sample job above includes a 6-hour time limit.
[user@login01 ~]$ sbatch MIKE.job Submitted batch job 1209671
Scaling Tests
It is useful to carry out scaling tests when running MIKE so that appropriate resource is requested to run a job. While requesting fewer nodes will mean the longer the job will run, it is more likely that a job will start sooner the fewer nodes it requests. The sample job script above requests 16 nodes (448 cores).
The table below shows runtimes for a test job over different numbers of nodes. For this example, the 3 minutes gained using 32 nodes over 16 nodes, provides little benefit and other users would be better having access to the 16 additional nodes. With contention for resources on Viper high, requesting 8 nodes would be a good compromise.
It is useful to carry out scaling tests with any significant change in job type.
| Nodes | Cores | Runtime (Mins:Secs) |
|---|---|---|
| 1 | 28 | 520:02 |
| 2 | 56 | 258:07 |
| 4 | 112 | 116:27 |
| 8 | 224 | 70:47 |
| 16 | 448 | 52:41 |
| 32 | 896 | 49:14 |