Hackathon: Porting and Optimization for Hunter

To participate in the Hackathon, you should already have an account on Hunter and make sure to be able to access Hunter from the place you plan to work, e.g. via VPN. Please check with your PI if you are unsure if VPN access is enabled for your account. See https://kb.hlrs.de/platforms/index.php/VPN for how to set up VPN.

Furthermore, kindly provide the following details by submitting an email to training(at)hlrs.de and CC to Björn Dick: dick(at)hlrs.de by the workshop registration deadline.

• Scientific domain you are working in,
• name of your code including URL (if available),
• Numerical approaches (should not be the majority of the provided details),
• name of the compute time budget used,
• programming language,
• programming models used (MPI, OpenMP, etc.),
• list of dependencies/libraries,
• known issues with specific compilers
• information on porting efforts done so far
• IO requirements (what is written to disk? with which frequency? number of files generated per each of those I/O events? volume of those files?)
• Size of your test case in terms of number of Hunter nodes used as well as expected runtime.

Running AI codes also necessitates information about:

• The user's AI software stack.
• IO requirements (e.g., dataset size, number of files, model size, number of checkpoints)
• The workflow along with computational requirements (e.g., number of GPUs needed for model training/fine-tuning and hyperparameter tuning).

Additionally, we require that you bring your own code including a test case which is set up according to the following rules:

use case selection:

• When processing the test case, your code should have a behavior and profile which is as close as possible to that of current and future production runs.
• If possible, the test case should be representative for those production runs of your group which consume the largest part of your compute time budget.

number of GPUs:

• In order to be representative, the test case should be in size comparable to the respective current and future production runs.
• In order to save valuable resources and to allow for a productive workflow, it should, however, be as small as possible.
• So, please, be prepared to reduce the size of your test case during the workshop! This can often be achieved while staying representative by reducing the simulated domain or resolution and keep the computational load per GPU constant ("weak down scaling").

wall time:

• In order to allow for a productive workflow, the wall time should be a few minutes only.
• At the same time, it should cover all important parts of the code, i.e. computation, communication and I/O.
• So take into account to reduce the number of simulated time steps and be prepared to increase I/O frequency to render investigation of I/O possible within such a low number of timesteps.

Please have in mind that it's possible to bring multiple test cases with you. This allows to cover different use cases and figure out hotspots with a production-alike sized case while doing the porting on a smaller case which allows for a simplified workflow.

If you are unsure about how to set up your test case, please contact Björn Dick (see contact data below).

In general the language of instruction is German, but can be changed to English if required.