Using Dakota on beach: Difference between revisions
From CSDMS
Created page with "== Using Dakota on '''beach''' == Topics to address: * Link to HPCC rules * At minimum, use `qsub -I` for a single-processor job * Running Dakota in parallel with MPI * Best..." |
m Words |
||
| (One intermediate revision by the same user not shown) | |||
| Line 4: | Line 4: | ||
* Link to HPCC rules | * Link to HPCC rules | ||
* At minimum, use | * At minimum, use <code>qsub -I</code> for a single-processor job | ||
* A simple example -- use [https://github.com/gregtucker/simple-dakota-example Greg's], with the <code>qsub</code> submission script | |||
* Best practice: copy inputs to compute node (using '''/state/partition1'''), perform Dakota experiment, delete inputs, move results back to home directory, or to '''/scratch''' if space is an issue. | |||
* Running Dakota in parallel with MPI | * Running Dakota in parallel with MPI | ||
If you encounter any problems in using Dakota on '''beach''', | |||
please email the CSDMS software engineers | |||
at [mailto:CSDMSsupport@colorado.edu CSDMSsupport@colorado.edu]. | |||
Latest revision as of 12:01, 23 January 2017
Using Dakota on beach
Topics to address:
- Link to HPCC rules
- At minimum, use
qsub -Ifor a single-processor job - A simple example -- use Greg's, with the
qsubsubmission script - Best practice: copy inputs to compute node (using /state/partition1), perform Dakota experiment, delete inputs, move results back to home directory, or to /scratch if space is an issue.
- Running Dakota in parallel with MPI
If you encounter any problems in using Dakota on beach, please email the CSDMS software engineers at CSDMSsupport@colorado.edu.
