Distributed CSE Support FAQ
- What is the distributed CSE (dCSE) support service and how may it be beneficial to my research?
- Who can apply for dCSE support?
- Can I apply for dCSE support?
- When can I apply, and when do I know if my application has been successful?
- How do I apply for dCSE support?
- If I am awarded dCSE support, do I get a grant?
- If I am not successful, when can I re-apply?
- If I have received a dCSE award previously can I re-apply for more funding?
- How will the support be co-ordinated by NAG?
- What happens to the Intellectual Property Rights generated by the project?
Writing the proposal
- What elements would make up a good proposal?
- Should I provide performance or profiling data?
- How do I gather performance information?
- I need further help?
A. It is to support scientific software development to facilitate scientific research. Awards are given to employ specialist help for improving an existing scientific code so that it can make better use of the capabilities of HECToR.
A. The main applicant should hold a permanent UK academic position or be the Principal Investigator (PI) on a Research Council award or fellowship.
A. The aim of the proposal should be to facilitate new scientific research by improving the performance of an existing code, either by tuning or through the implementation of new algorithms. Note that performance includes both the speed and scalability of the code.
- As a rule of thumb, if your proposal focusses on the development of novel methods such that it could be considered for submission to one of the Research Councils as a grant application through their research programmes (e.g. EPSRC funding) then it is unlikely to be suitable for dCSE support.
- Distributed CSE proposals should be for implementation and tuning of proven techniques which have a high degree of certainty of success. They are clearly targeted at obtaining performance increases on the UK High End Service(s), HECToR, but portability is also encouraged.
- Distributed CSE proposals CAN be aimed at extending codes to add functionality. Again, this should essentially be an implementation exercise with a high probability of success, and a high probability of significantly extending the scientific output.
A. Applications may be submitted at any time, but they will only be assessed after the end of the current call. Notification of the outcome will be around 2 months after the call ends. To help validate and discuss the rationale for the work being proposed it is strongly recommended that applicants contact the NAG CSE team at firstname.lastname@example.org at least 2 weeks before the application deadline. The dCSE review panel expects a thorough performance analysis of the codes in question as a basic justification of a dCSE proposal, and the NAG CSE team can contribute to ensure that these requests are met as well as advise prospective applicants on related work or the typical scope within the dCSE framework.
A. By submitting a case for support which must give a top level view of the proposed software development. See how to apply
A. No. The CSE service will either provide the necessary support staff directly, or via a contract with a third party (which could be the applicant). In the latter case a formal contract will be agreed which will outline the programme of work with mutually agreed milestones and deliverables. Any variation to this programme of work should be discussed with the CSE service in advance.
A. Feedback and guidance will be available to help with any re-submission; you can re-apply at the next call.
A. Yes, provided there is clear justification for further code development which is likely to be successful.
A. NAG will be flexible in working with the PI to deliver the dCSE support. For example:
- The PI might have a suitable colleague in mind to carry out the work. NAG might sub-contract this work directly to that colleague or through a suitable institution to that colleague. In general it would be better if that colleague was co-located with the PI or part of the consortium working on the science; or
- The PI might ask NAG to provide suitable support directly, either from NAG's own resources or via recruitment. Again, if possible, co-location with the PI, or part of the consortium working on the science would be highly desirable.
As part of NAGs contract with EPSRC to carry out HECToR CSE Services, NAG is obliged to retain all rights in the work carried out under a dCSE contract, in order that it can be licensed to other HECToR users and more broadly if required by the UK Research Councils. NAG grants the Contractor and the PI a non-exclusive license to re-use all such rights. For the avoidance of doubt, where the programme of work involves changes to existing software, NAG only requires rights to the modifications themselves, not to the entirety of the modified software. NAG's grant of rights back to the Contractor/PI allows the modifications to be included into existing software without restriction, including releasing the modified software under a suitable software licence.
- Justify the economic impact of the proposed work for the wider scientific community. You are strongly advised to give specific examples of new research that will be facilitated by the proposed work. This may be from your own research plan or from a direct sponsor or group of sponsors requiring the code improvements. There should be a clear explanation of the proposed scientific cases that are enabled by the completion of this work. Letters of support from UK research groups which give details of their scientific justification and HECToR requirement for the code development are also encouraged and this is especially relevant for established codes. E.g. group A from University B would like to use code C to do simulations with material D using E points (where E is only possible by implementing the proposed code improvements). Ideally, this should also include an estimate of the AU footprint of group A in doing this work.
- Realistic and quantifiable goals indicating worthwhile improvements in performance and/or scaling.
- Evidence that the project will achieve the goals stated. If a new general algorithm is to be implemented, it should already be proven by evidence in the scientific press. Research into the performance of an algorithm is not covered by dCSE support.
- Strong applicability to a large community where the findings could be beneficial to many other codes.
- The improvements should enable scientific research to be performed that is currently not possible because of code limitations.
- Scaling and profiling information will help the reviewers to familiarise themselves with the code performance. You are encouraged to identify areas of weak performance and clarify how they might be improved. Help with code profiling may be available from the NAG CSE team.
A. It may not be essential to provide this depending upon the nature of the proposal. But, when applicable, it should give clarity to the aims of the proposal. For assistance in performance analysis, obtaining profiling information, and using the tools available on HECToR to obtain this information, please contact the NAG CSE team at email@example.com. They will also provide feedback on the analysis that you have performed yourself. The following may help in deciding areas of the code for analysis.
- Investigating the I/O performance, e.g. pre/post processing or restarts. For load balancing and memory issues, does the code use any partitioning packages to distribute the data, and how do these perform?
- Serial performance on a single node. Timing the code using single core mode and then comparing with using multi-core mode will give an idea of the efficiency of the intra node communications.
- Parallel optimisation for critical regions or building blocks of the code. It is important to identify such regions that contain the essential MPI communications of the code. E.g. A region could be where the global variables are exchanged around the processors using non-blocking communication. Another example might be where all-to-all messages contribute to load imbalance and inefficient usage of communication buffers due to synchronization timings.
A. This information needs to be understood by someone who may be unfamiliar with the code. A high level view of the application will provide the reviewers with sufficient information to evaluate the proposal. Most profiling approaches focus on the concept of regions of the code. It is usually unnecessary to profile an entire run. Provided that all critical regions of the execution are included only a few minutes worth of execution time may be required. However, if the initialisation and closing time becomes significant, then these components should be excluded from the data so that the reviewers have a representative view of a typical production job. The main profiling tools on HECToR are CrayPat, Cray Apprentice and Totalview.Further help and advice
For further assistance, the NAG HECToR CSE support team can be contacted at firstname.lastname@example.org, or via the HECToR Help Desk. Go to the main Distributed CSE support page here.