By Dr Marlies Hankel, a QCIF eResearch Analyst at UQ.
Note: Marlies, QCIF’s HPC expert, can review NCMAS applications (before they’re submitted) from researchers of QCIF Member universities. Draft applications need to be sent to Marlies by COB Monday, 5 September 2022 (email: m.hankel@uq.edu.au). NCMAS applications are due to NCI by COB Monday, 19 September 2022.
First of all, access the main page of NCMAS.
They do have an Online Information Course. PLEASE look at that. It is a bit of a time commitment but it will answer a lot of questions. The listings tell you how long each episode is. There is a section on who is eligible to be a lead Chief Investigator (CI) and it explicitly tells you what is allowed and what not. To be a lead CI you need to be a CI on a competitive grant. If you are not, you cannot be a lead CI and you will have to find someone to support your project.
There is a whole section on scaling. It is important to get this right or the rank of your application will be low, and your allocation will be a lot less than you expect and/or need.
This year I have obtained several example proposals from 2022 that I can give out to applicants. A big thank you to those who have agreed to make these available to help others. There are examples of Fluid Dynamics, Material Science and Bioinformatics. Please contact me (m.hankel@uq.edu.au) if you would like to have a look at those.
The documentation provided on the Application Form is very good as it has screenshots and indicates what needs to be done in which part of the form. It clearly shows where information needs to be anonymised and where not.
The main things you should remember, the assessors will only see a summary of the team’s track record. CIs will be presented in random order so assessors will not know who the lead CI is. So, for the track record, it is the team as a whole that counts.
The assessors will base their assessment on the Proposal and the Computational Details. They will not see anything else apart from the team track record. So, if you bury computational details and justification somewhere else in the application, they will not take that into account.
Projects without sufficient scaling information and computational details and justification will suffer in the ranking. Scaling needs to be presented on the facility you are applying for. So old Raijin (NCI’s previous supercomputer) data will sink the application. Just giving data for Gadi (NCI’s new supercomputer) but asking for a lot of time on Setonix (Pawsey’s supercomputer) will not go down well. If you do not have access to Setonix please use the Preparatory Scheme to gain access to do some scaling and efficiency calculations. Scaling data will need to be presented for the calculations you wish to do next year. If you want to do some completely different systems or setups then you should present scaling data for each. You will also need to present scaling for all the different software you propose to use, not just one or two packages.
In general, your proposal should follow the general outline of most grant applications. Assessment criteria are:
- Project quality and innovation (40%)
- Investigator records (30%)
- Computational feasibility (20%)
- Benefit and impact (10%).
Computational Feasibility
Most projects fail with regards to computational feasibility. Most assessors will not accept it if applications do not explain how the allocation requested will facilitate the proposed research. In the proposal you should outline the research you intend to do in 2023. Do not say this is continuing work etc., or anything that would show them that you had any allocation this year. You need to outline the significance, innovation and quality of the research for 2023. Then you should explain what kind of calculations are needed to achieve your research goals. You can provide some detail, but it needs to be made clear that the methods (software) you are using are the proper ones (state-of-the-art, the only ones available, the ones that are expected to be used if you want to publish your results, etc.,…) for the research you are doing and for what you are trying to achieve. It also needs to be made clear that these calculations need to be done to achieve your proposed research goals.
The computational details then should show that the calculations you want to do run efficiently on the facilities you are applying for. Those of you doing MPI (VASP, MD, OpenFoam, home grown MPI code, …) should consider looking at Setonix as well. Gadi is not the only facility that does that. If you say that the calculations need X number of cores to run then you will need to show that the software you are using does scale well up to that number of cores for the systems you intend to look at in 2023. Reusing old scaling info again and again is not a wise thing to do. If you can, do new scaling calculations every year, or throughout the year for new systems or set ups you are doing. So, if you are going to use multiple software you have to provide scaling data for all, or at least a good set of them. If you are going to look at very different systems or set ups (input parameters) you should give scaling for as many as you can.
For those of you who struggled to get what you asked for last round, not providing this info would have been the main point as to why. It takes (tedious) effort to write the computational details.
Service Units
There is no need to arrive at exact Service Units (SUs) for each calculation and each project. It is enough if you can show that typical calculations will need this much SUs and therefore to get some meaningful results you are asking for this allocation for this project. Please make sure that allocations requested for each project add up to the total you are asking for. Please quote SUs according to the charging rate. Some of the queues charge more in SUs than others, so please make sure to factor this in. Please also be aware of minimum allocations for each facility. Allocations are given in kSUs (kSUs are Service Units in thousands, e.g., 100 kSUs is 100,000 SUs), but asking for an allocation of, for example, 634 kSUs would be pretty weird. This should really be 600 kSUs or 650 kSUs if possible. Make it divisible by four as the allocation is for the full year and will be divided by four to get the quarterly allocation.
If you ask for time on Gadi and Setonix then please justify your allocations for each. This usually means providing scaling. Also, if you say, for example, Gadi is much better but ask for time on Gadi and Setonix, the committee might not give an allocation on Setonix. Asking for an allocation on both just in case, but not making your case why you need an allocation on both will most likely get you into trouble and you might not get anything on one of them.
The Proposal and the Computational details document is the information the assessors see. You need to make sure everything is in there to convince them that your proposal has merit, and that this allocation is needed to do the calculations to achieve the research you propose.
- High-Performance Computing