You are here:
Dr Marlies Hankel

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, 20 September 2021 (email: m.hankel@uq.edu.au). NCMAS applications are due to NCI on 5 October 2021.

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.

The sample proposal and computational details are the same as last year but are good examples.

The Application Form is actually pretty 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 videos below are from last year so some information will be out of date. But the general info on how to write the proposal and the part on scaling are very current.


NCMAS facilities and who should apply from last year:


NCMAS: Process and walk through the application form from last year:


The main things you should remember, the assessors will only see a summary of the teams 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 data will sink the application. Just giving data for Gadi (NCI’s supercomputer) but asking for a lot of time on Setonix (Pawsey’s supercomputer) will not go down well. If you are asking for time on Setonix at least present Magnus data. 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%).

Most projects fail with regards to the 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 2022. 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 2022. Then you should explain what kind of computations, 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 2022. 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. 

Last round, new assessors struggled with proposals from multiple CIs when there were many different projects. It does help if you number different projects like Project 1, Project 2, etc., and then show scaling for software and systems under each project. 

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 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.


TAGS
  • High-Performance Computing