...
where graph_file is something like https://acme-svn2.ornl.gov/acme-repo/acme/inputdata/ocn/mpas-o/oRRS15to5/mpas-o.graph.info.151209 and # pes is the number of cores you want to use for that component.
About Parallel I/O (PIO) Layout:
Input/output (IO) can also have a big impact on model performance. can also have a big impact on model performance. So as to not confuse I/O performance with model performance, the usual steps are:
- Get a working PIO settings, so that the model will not crash while reading input settings. Often the default settings will not work, especialy on vary large or very small processor counts.
- Disable history output and restart files for all components. Then you can use short (5-10 days) simulations to determine an optional processor layout. Otherwise, short simulations will be dominated by I/O costs and will give misleading performance numbers.
- Once you have a reasonable processor layout without I/O, use 1 month simulations to test PIO settings.
To understand the impact of I/O on the model performance start by taking a look at the time taken by the PIO functions (grep for pio*) in the performance archive. Bad PIO settings can cause the model to crash, or have horribly slow output performance. But you want to make sure you have a reasonable processor layout before calibrating the PIO settings.
Several aspects of the model I/O performance can be controlled at runtime by setting the PIO* parameters in env_run.xml. The model developer can start by tuning the number of PIO I/O tasks (processes that perform I/O) and the stride between the I/O tasks by setting PIO_NUMTASKS and PIO_STRIDE respectively in env_run.xml. By default the PIO_STRIDE is set to 4, which means as you increase the number of tasks, you get more tasks trying to write to the filesystem.
...