Regular Access

Discoverer Call for Proposals for Regular Access Mode – View as PDF

Principal Investigator (PI)

Assistant Professor position is required to access Discoverer resources.
Example: – Sofia University
Example: – Faculty of Chemistry and Pharmacy
Example: – Department of Physical Chemistry
Co-PIs
Title (Dr., Prof., etc.)
Last name
First name
Organisation name
Faculty
Department / Group
Country
 
Provide the details of any Co-PIs in the project, including Title, Last name, First name, Organisation, Department, Group and Country.

IMPORTANT NOTICE

All of the sections and subsections below MUST BE COMPLETED (unless stated otherwise). In case you wish to leave a section empty, you must  provide a clear reason after the table. The Domain Panel Chairs, appointed by the Resource Allocation Committee (RAC) will not be able to process proposals that neither provide the requested information nor a justification for the lack of such information for each section.

Applicants are strongly encouraged to base their proposal on reliable benchmark data obtained on the target machine(s) from previous calls or access programmes. Such data and support to properly collect these can be obtained from the Discoverer Benchmark Access. If needed, please contact the peer review office Discoverer at peer-review@discoverer.sofiatech.bg in order to request such access and support, at least 2 weeks before the submission deadline.

The structure and formatting settings of this template must be preserved and respected (change in font size or margin and spacing settings are not allowed). The maximum number of pages allowed is 10, including graphs, tables and references, but not counting the cover page and the Appendix. Reviewers will be instructed not to consider any pages out of the established limit. Applicants are requested to include information about their track record in Appendix 1, at the end of the document (not counted in the page limit). Instruction paragraphs can be removed from the proposal text.

The applicant must provide e-mail address(es) for administrative and technical contacts, and select a protection level for the corresponding e-mail communication, by filling the form provided in Appendix 2.

Upload a single document, based on the present template, in PDF format without exceeding 20 MB. PDF documents, which authorship and content can be automatically validated based on an embedded electronic signature, will be greatly appreciated (see Appendix 2).

Proposals that do not follow the template or that are incomplete will be administratively rejected and will not be further evaluated.

Outline the scientific/societal/technological significance of your project, how High Performance Computing (HPC) is expected to help achieving your goals, and what are the expected major outcomes. This section would typically be the same as the abstract of the proposal in the submission form.
Describe the proposed research and the main scientific/technical advances you will achieve with the requested Discoverer allocation. For industrial applications, proposals should demonstrate the innovation and industrial impact on the specific market and the broader socio-economic impact. For public sector applications, the proposal should demonstrate the innovative aspects of the applications, the expected societal impact, and how the application will contribute to the delivery of quality and efficient public sector services. The justification of the requested resources must be clearly linked to the software performance evaluation (Section 2.6).
Describe the motivation, objectives and scientific challenges of the problem. Describe and justify the choice of computational methods. State the advances that will be enabled through the requested Discoverer Regular Access award (e.g. impact on community paradigms, valuable insights or solving a long-standing challenge, new technology/therapy, etc.). Provide a list of expected outcomes of your proposal and, if relevant, the interdisciplinary value of your proposal.

2.3. Validation, verification, state of the art (1 page)

Please describe the validity of the simulations and predictions made with this proposal. In case you provide references to relevant publications please include here also the key relevant results. Please address issues of reproducibility and highlight the predictive capabilities of your simulations.
Please summarize the validation of your model against physical experiments or other established reference data. Please also provide how the numerical consistency and stability of your computational method has been verified or provide evidence of existing verifications.
Place the project in the context of competing work. Explain the relative advantages AND drawbacks of your approach

2.4. Software and Attributes (1 page)

(Please see also Examples of Performance Reporting in Section 2.6.2.1). Describe the software that will be used including a discussion of the state of the art in the field. The description should mention
Please describe all codes you are using in the proposal. Justify your choices and describe alternatives (if any).
Describe particular libraries required by the production and analysis software, algorithms and numerical techniques employed (e.g. finite element, iterative solver), programming languages. Please specify requirements for compilation or build environment (build system (e.g. cmake, python version), version control system (e.g. git, subversion) etc.).
Model(s) used (e.g., MPI, OpenMP, etc.).

2. Detailed proposal information (Maximum 10 pages, graphs and tables included)

The information should be suitable for expert peer review in your discipline. It must also include appropriate information for a broader audience as your proposal will be evaluated by a panel and in parallel with proposals in other disciplines.
I/O requirements (e.g. amount, size, bandwidth, etc.) for execution, input files, restart and other output. Describe I/O strategy (number of files, frequency, read/write size) and I/O behaviour of your code during the period of calculations. Please specify the restart overhead, not only for I/O; (e.g. a code may have to perform a costly domain decomposition first).

2.5 Data: Management Plan, Storage, Analysis and Visualization (~1 page)

Data Management Plan covering both short-term and long-term aspects, including needs for I/O bandwidth, number of files and input/output data volumes. Specify for which system the data will be provided, how long the data must be stored at the computing centre after the termination of the project, how it will be moved from the centre, and how subsequent analysis will be performed. Specify the availability of both code and data to other researchers, and how this will be handled. Discoverer & EuroHPC should be given credit for all data produced through Discoverer allocations when publishing, and described in the provenance when depositing to other infrastructures.
Project workflow including the role and timeline of data analysis and visualisation identify where the analysis will be done and any potential bottlenecks in the analysis process. Describe any analysis and/or data reduction tools used.
Software workflow solution (e.g. pre- and post-processing scripts that automate run management and analysis) to facilitate this volume of work.
I/O requirements (e.g., amount, size, bandwidth (the one required for Internet connectivity; some gross estimate of the expected minimum IB bandwidth between the compute nodes; file system read/write latency), etc.) for data analysis and visualisation. Highlight any exceptional I/O needs. Please provide data for (one or several) precise systems that will be simulated.

2.6 Performance of Software (Maximum 2 pages)

It is strongly recommended that your production code is tested in the requested machine(s) environment (see also the text referring to Benchmark Access in the Important Notice at the top of page 1). Please specify the Discoverer Benchmark Access project (if any) or other projects (previous PRACE or EuroHPC Calls, national calls, etc.) used to prepare the Regular Access proposal. If the CPU architecture and model used on the preparatory host machine are different from AMD CPU architecture, and Zen2/3 architecture in particular, specify why that estimation i might be considered relevant. In the latter case, please report briefly the conversion factor (in terms of ratio of time-to-solution, flops, or requested core hours) from the machine where the preparatory tests were performed to the requested system. Moreover, your proposal must account for all technical constraints and requirements of the targeted machine(s) as documented in the separate Technical Guidelines for Applicants document; failing to do so will significantly increase the risk that your project will be technically rejected.

2.6.2 Quantify the HPC performance of your project

The presented data must be representative of the entire workflow of the project proposed and refer to the main application code you intend for the production work. The software scalability data (see Examples of Performance Reporting below) must be used to choose the most efficient job size(s) for the simulations planned in production: the corresponding software performance must be clearly linked to the justification of the computing resources requested. The Domain Panles will not accept estimates based on related codes and/or data related to parts of your production. All data must refer to the targeted AMD Zen2/3 architecture in your production runs or a system with comparable size, software stack and with the same architecture, and network (e.g. a project can be accepted on Discoverer CPU Zen partition if it was benchmarked on another AMD Zen machine with the same AMD Epic CPU). Please coordinate with the centres if in doubt about the portability of your code. Specify that performance results are reported on the basis of one of the following: whole application including I/O; whole application except I/O; kernel only; other (specify). More specifically you must include:
Starting with the minimum size of the computer necessary to run the problem (usually 1 core or 1 node), justify the minimum size for your scaling if it is larger than 1 core or 1 node (e.g. memory limitations). Please provide a justification in case that either the weak (e.g. study of one particular bio-molecule) or the strong (e.g. study of an ensemble) scalability metric is not considered relevant to your project. See Examples of Performance Reporting below for the requested format.

Examples of Performance Reporting. For the weak and strong scaling please start with the minimum and finish with the maximum number of cores that are suitable for your application. Please mark the number of cores that you expect to perform the main load of your work. On the Y axis you may use time to solution (scaled or otherwise) or speedup with respect to the minimum number of cores. The table with the timings is mandatory. The table should include the speedup and the parallel efficiency. Log/log plots are useful to span many orders of magnitude.

One of: single precision, double precision, mixed precision. Only the precision you use in the simulation is relevant.
Time-to-solution as normalised/averaged per iteration, AND the normalized total time to solution with ti the time per iteration, tf the total time to solution, Nc the number of cores and Ne the number of computational elements (size of the problem). IMPORTANT: Justify the choice of your code (e.g., comparison with existing codes, methods or any other scientifically rigorous argumentation). See also the text referring to Preparatory Access in the Important Notice at the top of Page 1.
One of: results measured on full-scale system, projected from results of smaller system, other (specify).
One of: timers, FLOP count, static analysis tool, performance modelling, other (specify).
Specify requirements per node or core depending on the size of the problem.
Please collaborate with the Centres on obtaining this information (see also the text referring to Preparatory Access in the Important Notice at the top of Page 1). Alternatively provide code specific metrics for the requested machine (FLOPS, etc.).

3. Milestones (quarterly basis) (Maximum 1 page)

Goals and milestones should articulate simulation and developmental objectives and be sufficiently detailed to assess the progress of the project for each year of any allocation granted. It is especially important that you provide clear connections between the project’s overarching milestones, the planned production simulations, and the compute time expected to be required for these simulations. Please clarify any dependencies of milestones on other milestones. Please ensure that the core hour consumption is regular throughout the allocation or provide a requested schedule after consultation with the centres.

Run Type

Code(s)

N.

of

N.

of

N. of steps

Time

per

Total  node

 

 

runs

 

nodes

 

per run

Step(s)

 

hours

A (init. condition prep.)

code1

 

 

 

 

 

 

 

 

B (low resolution)

code2

 

 

 

 

 

 

 

 

C (high resolution)

code2

 

 

 

 

 

 

 

 

D (post processing)

code3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Max. file size: 128 MB.
Provide a Gantt Chart of the simulation plan in production indicating job sizes and scheduling of computing tasks including a communication plan for the results and the strategy and timeline for the dissemination of the results.

4. Personnel and Management Plan ( 0,5 page)

What personnel are already in place and what are their roles on the project? If applicable, describe (i) personnel that will be hired for the project in the future and their responsibilities and (ii) potential personnel turnover that may occur during the project and a strategy for replacing them. The Discoverer Regular Access calls welcome proposals from individual PIs or teams of collaborators. Outline the focus of each individual or subgroup and their interrelationships.

5. References (Maximum 30)

6. Confidentiality (0,5 page)

Is any part of the project covered by confidentiality?
Does your project involve handling of personal data?
This field is for validation purposes and should be left unchanged.