- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
The main idea behind this hackathon is to focus on improving the performance of MALA. This especially applies to inference, but also training of models. Of course, other topics may just as well be touched.
- GOAL: Enable GPU based calculations using the total energy module (based on Quantum ESPRESSO).
- LINKED ISSUE: https://github.com/mala-project/mala/issues/362
- STEPS:
1. Build a GPU version of QE.
2. Port external_modules/total_energy_module/total_energy.f90 to a GPU ready version of QE.
3. Test that this works as expected (e.g. with examples/ex03_postprocess_data.py)
4. Test whether the functions we lose time in are already GPU ready; they may not be, since we run at different scales then QE regularly does.
- GOAL: Enable GPU based calculations using the LAMMPS code.
- LINKED ISSUE: https://github.com/mala-project/mala/issues/399
- STEPS:
1. Build a GPU version of LAMMPS.
2. If necessary, port our version of LAMMPS to this one
3. Benchmark the calculations and check whether our code already makes good use of the GPU
- GOAL: Find out where MALA loses time during training and inference.
- LINKED ISSUE: None
- STEPS:
1. Build a standard MALA version on hemera, if none is available.
2. Run a simple training (e.g. Al256 at room temperature) and thereafter an inference, first in GPU, second in CPU
3. Time all things important.
- GOAL: This topic is directed towards Jon/Sandia, since I know they have been doing some things in this regard in cooperation with Nvidia. The idea is to reduce the data loading time for the lazy loading case.
- LINKED ISSUE: None.
- STEPS:
1. Get in touch with Jon or be Jon
2. Merge required changes to main code
- GOAL: MALA currently requires all snapshots to have the same grid size. This is obviously an unnecessary requirement.
- LINKED ISSUE: None, but there is an existing branch: https://github.com/RandomDefaultUser/mala/commits/flexible_datahandling, however I would NOT go beyond this commit: https://github.com/RandomDefaultUser/mala/commit/60e14a82bb6601b7ac2078f2886b439abaf01d95, the rest is experimental
- STEPS:
1. Rebase/Update branch, starting from the last reliable commit
2. Test that everything works
- GOAL: Make use of OpenPMD parallelization capabilities
- LINKED ISSUE: None.
- STEPS:
1. Investigate OpenPMD parallelization for data writing.
2. Investigate OpenPMD parallelization for data reading.
- GOAL: MALA has been used for a while now, and some convenience use cases have emerged.
- LINKED ISSUE: https://github.com/mala-project/mala/issues/378, https://github.com/mala-project/mala/issues/365, https://github.com/mala-project/mala/issues/295
- STEPS:
1. Look into the issues.
- GOAL: MALA currently uses x GPUs for training and y CPUs for preprocessing, where currently x=y. Investigate whether y>x.
- LINKED ISSUE: None.
- STEPS:
1. Implement an MPI based interface to exchange data between ranks.
2. Benchmark.
- While the focus of the sessions should be performance, ML topics such as Gaussian processes, equivariant NN, etc. can of course also be investigated.