Optimisation and resource use documentation

[aidanheerdegen]

Release requires documentation on the performance, optimisation and resource use of the model to support users when applying for compute time in competitive allocation schemes such as NCMAS.

From the NCMAS documentation:

In the Computational Details part of your application, you should focus on the assessment criteria of 3) Computational Feasibility and provide details on:

• Scalability of your code(s) on each nominated facility:
  • Use scalability tables and/or plots.
  • For software with multi-node capability, applicants should present data relative to single node performance, not single core performance
  • Poor scaling may impact negatively on the merit of theapplication
• Compute job resources at each nominated facility:
  • Provide details on typical job configurations for your workflows, including
    • expected wall times,
    • number of nodes/cores,
    • data dependencies,
    • expected throughput, and so on.
    • Provide a summary of the resource requirements in the form of an “SUbudget” for each request. This budget should list:
    • major steps in the project workflow(s),
    • the key methods/algorithms required, and
    • the SU requirements for each step.
• Also describe other dependencies such as software and storage. • Storage at each nominated facility:
  • Describe data storage requirements and data life cycle for your project.
• Algorithms and Workflows:
  • Describe parallelism in your application(s) and how this relates to mathematical algorithms used. Describe data movement and lifecycle.

[aidanheerdegen]

This is also required for ACCESS-ESM1.5, so there may be overlap or a shared approach. Also documentation should be consistently compiled and presented.

https://github.com/ACCESS-NRI/access-esm1.5-configs/issues/4

[dougiesquire]

Andrew has sent me some of this information. @aidanheerdegen, where should this documentation live? Should I open an issue/PR with the ACCESS-Hive docs?

[aidanheerdegen]

I think this repo is probably the best place initially. If need be we can link to it from the Hive, or make a dedicated section on the hive that summarises the information in a standard way.

So maybe create a docs directory, upload PDFs or other assets and add a README.md with a summary and links?

[dougiesquire]

I think this repo is probably the best place initially

Scaling/performance documentation is configuration-specific, so access-om2-configs feels like a more intuitive home to me. @aidanheerdegen are you okay with this?

[aidanheerdegen]

I think this repo is probably the best place initially

Scaling/performance documentation is configuration-specific, so access-om2-configs feels like a more intuitive home to me. @aidanheerdegen are you okay with this?

Yeah I was tossing up the pros and cons. Arguably the scaling tests include configurations that aren't actually part of the released configs, but the resource use for each configuration is better in the configs repo, so it could go either way.

The most important consideration IMO is where would users expect to go and find this information. I'd argue here, but I'm not gonna die in a ditch about it.

[dougiesquire]

So... where?... You tha boss

[aidanheerdegen]

Not true. You da boss.

Ok, put it in a subdir in the configs repo (main branch) and add some text pointing to it in this repo.

Gordian knot cut.

[dougiesquire]

Gordian knot cut.

Thank the stars

[dougiesquire]

I'd argue here, but I'm not gonna die in a ditch about it.

Sorry, I just realised I didn't read this properly and you actually told me where