Skip to content

FF chevron

Apply for an AAC Allocation

This page discusses the process of applying for an allocation from the Allocations and Advisory Committee. It includes detailed discussion of the various pieces of information requested by the form.

Overview

The Allocations and Advisory Committee (AAC) awards allocations to UMD faculty members at no cost to the faculty member. These allocations are awarded after the AAC reviews applications submitted by the faculty member (or a student, etc. on their behalf). The AAC is entrusted with ensuring that the valuable HPC resources are being used well, and so review the applications carefully; the more resources being requested, the more closely the application is examined. Because the AAC does not oversubscribe resources from pool available to them, awarding resources to one researcher reduces the amount of resources that can be awarded to others.

  • The AAC grants only one allocation per faculty member (excluding class allocations) regardless of the the number of projects or students. So when applying for an allocation from the AAC, you should submit a single application covering all research projects, etc. that you intend to work on for the upcoming twelve months (or when the existing allocation expires if that is not expiring imminently).
  • The AAC needs to be be apprised of all research being conducted on the UMD HPC clusters. If a faculty member has multiple allocations, e.g. departmental/college and/or paid allocations in addition to the AAC allocation being applied for, the application must discuss the research being conducted across all such allocations. But the research for which the AAC allocation is being requested should be discussed in the greatest detail in the SU Justification and Code Use and Scalability sections.
  • AAC grant limit is 550kSU/year.
  • The grant period is a year--365 days from the date of the grant (not a calendar year as in Jan-1 to Dec-31).
  • All applications must come from a faculty member.
    However, a student may fill out the form on behalf of their faculty advisor as long as the faculty member approves it.
  • Faculty members are eligible for at most one development allocation from the AAC per year. If additional resources are needed beyond what is available in a development allocation, you must apply for a larger allocation.
  • AAC allocations are granted for a year. You can submit a "renewal" application if:
    • the allocation has expired
    • you need additional resources from the AAC. In this case (if the previous allocation has not expired and is not about to expire), the expiration date from the previous allocation will be retained, and the application should be restricted for that period.
  • There is no charge to the faculty member for either a developmental larger allocation from the AAC.
  • If you need more than the AAC's yearly limit, you can look into departmental and paid allocations.
  • The AAC and DIT do not provide software licenses for research software packages. Although some commercial products (e.g. MATLAB are available to all users on the cluster due to site licenses purchased either by campus or by individual units who allow access to all users on the cluster, in general to use a restrictively licenses software package on the cluster you must provide a license. Always contact HPC staff before purchasing any license you intend to use on the cluster; not all licenses are compatible with the HPC cluster.

There are basically two "flavors" of allocations from the AAC:

  • Developmental allocations: This is a small allocation (up to 50 kSU/year, with 100 GB of scratch storage and 1 TB of SHELL storage) and is intended for new users to explore how (or even whether) their research can make use of HPC resources. For small projects, it might even be enough to complete the research project. It also allows access to the cluster so that one can collect data about how your jobs run on the cluster, which the AAC will wish to see in any renewal application for a larger allocation.
  • Larger allocations: This is a larger allocation (up to 550 kSU/year, up to 10 TB of scratch storage and up to 50 TB of SHELL storage). This type of allocation is often sufficient for medium sized projects. Due to the larger size, the AAC requires more detailed research plans in the application, including metrics showing that you are using the HPC resources efficiently; such metrics are typically collected in the previous developmental allocation.

Although it is convenient to discuss the two "flavors" of AAC allocations, the only difference is in the amount of resources awarded and the requirements in the application process. Either flavor of allocation will appear as a Slurm allocation account named something like PROJECT-aac, where PROJECT is the name of the project under which the allocation exists. I.e,, you will not see separate developmental and larger allocations, but a single AAC allocation.

Similarly, the same application form is used for both flavors of allocations. However, the scrutiny with which the application is reviewed differs substantially, and in general the more resources you request, the higher the standard to which the application will be held by the AAC.

How to Apply for an AAC Allocation

Please use the online form to apply for either a Basic/Developmental allocation, or a Larger Allocation.

Below are some guidelines and advice for submitting applications for developmental allocations and larger allocations, as well as a detailed discussion of each field in the form.

If you are new to the UMD DIT maintained HPC clusters, you should start by requesting a developmental allocation, even if you have experience with HPC at other institutions. The AAC typically wishes to see a summary of certain benchmarking tests for your codes on the UMD cluster before they will grant more resources than available in a developmental allocation; if you sstart by making a request for more resources it will usually only be granted at a developmental level.

Note that:

  • AAC grants only one allocation per faculty member (excluding class allocations) regardless of the the number of research projects or students, etc.
  • The limits on AAC grants are 550 kSU/year, 10 TB of scratch storage, and 50 TB of SHELL storage. If you need more than the AAC's yearly limit, you can look into departmental and paid allocations.
  • The grant period is a year--365 days from the date of the grant (not a calendar year as in Jan-1 to Dec-31). Larger allocations generally retain the same expiration as the original base/developmental allocation (unless the former expired or is close to expiring).
  • The AAC will only award a single development allocation to a faculty in the annual grant period. If additional resources are needed beyond what is available in a development allocation, you must apply for a larger allocation.
  • All applications must come from a faculty member. However, a student may fill out the form on behalf of the faculty member as long as the faculty member approves it.
  • If you are a student filling out the form on behalf of your faculty advisor, then
  • AAC allocations are granted for a year. You can submit a renewal application if the application has expired. You can also submit a renewal application for a larger allocation if you need additional resources from the AAC
  • There is no charge to the faculty member for either a developmental or larger allocation from the AAC.
  • The AAC and DIT do not provide software licenses for research software packages. Although some commercial products are available to all users on the cluster due to site licenses purchased either by campus or by individual units who allow access to all users on the cluster, in general to use a restrictively licenses software package on the cluster you must provide a license. Always contact HPC staff before purchasing any license you intend to use on the cluster; not all licenses are compatible with the HPC cluster.

All allocation requests are reviewed by the HPC systems staff first, and then by the AAC. The more resources you request, the more scrutiny your application will receive. AAC does not over-subscribe the HPC resources, hence, when an allocation is graneted, those resources are no longer available for other campus researchers. The application process is also one of the only chances we have to ensure the cluster resources are being used efficiently. This is why the review process is very strict. If clarifications or more explanations/data are required, the application will be sent back to be updated accordingly.

Applying for a Developmental Allocation

Note

The online application form is at https://umd.service-now.com/hpc

If you are new to the UMD HPC cluster, even if you have experience with HPC clusters at other institutions, this is the allocation type you should request first. This allocation grant from the AAC includes 50 kSU/year of compute time, 0.1 TB (100 GB) of high performance scratch disk space, and 1 TB of medium term SHELL storage.

As with all allocations and resources awarded by the AAC, there is no charge to the faculty member for this type of allocation.

The review of the application by the AAC is more rigorous as more resources are requested; faculty members are eligible a developmental allocation of up to 50 kSU per year with very little information. This is useful if you are new to HPC and wish to see if HPC techniques can benefit your research, or for you to start your research while collecting the metrics that will be needed in any subsequent renewal application for additional resources.

Note

The AAC will not grant another developmental allocation to a faculty member until the previous one is expired (or at least close to expiration). If you (or if applying as a student on behalf of your faculty advisor, your faculty advisor (or another student of your faculty advisor) has applied for an developmental allocation less than a year ago), you cannot request another developmental allocation. Please submit a renewal allocation for a larger allocation instead.

When applying for a developmental allocation, please focus on the fields:

  • Research (Lay) Abstract: just describe your overall research interests and what you hope to do with the HPC cluster
  • Faculty Advisor: If you are a student requesting an allocation on behalf of your advisor, please identify your advisor here.
  • HPC Experience: How much HPC experience do you have? This is for internal statistics, and your answer will not affect the approval of your application.
  • Unix Experience: How much Unix experience do you have? This is for internal statistics, and your answer will not affect the approval of your application.

If you need more than the default levels of 100 GB of scratch and/or 1 TB of SHELL storage, please also set:

For the other fields, we recommend that you try to answer them as best as your can without putting too much effort into it. Do not worry if you do not know how to answer the question, or even if you understand the question; you generally do not need to respond to the other fields in order to receive your application. (The form might require a response in some fields, you can enter "developmental allocation" or similer if needed to submit the form). If you do not understand the question or how to respond, you can state such as well.

We think it is useful for you to see those fields, because if you will need more than this basic developmental allocation to complete your research, you will need to apply for a renewal allocation for a larger allocation. Such an application will need good responses to these fields, and for some of the answers will expect that you have collected benchmarks and other metrics while using this developmental allocation. So it is best for you to see what is expected in a future renewal application now, before your compute time from this developmental allocation is all consumed.

Applying for a Larger Allocation

Note

The online application form is at https://umd.service-now.com/hpc

If you are requesting more HPC resources from the AAC then is available from a developmental allocation (i.e. 50 kSU/yr, 100 GB of scratch space, and 1 TB of SHELL space), then you need to apply for a larger allocation.

Tip

If you have not used an UMD HPC cluster before, do not request a larger allocation; apply for a developmental allocation instead. If you apply for a larger allocation without having any experience on the UMD HPC clusters, the AAC will only award you a developmental allocation anyway.

The AAC is able to award up to a total of 550 kSU/year of compute time, 10 TB of scratch disk space and 50 TB of SHELL disk space.
However, you will need to provide a detailed justification to the AAC for any resources being requested. The more resources you request from the AAC, the stricter their review criteria are. Therefore, we highly recommend you only request the resources needed for your research goals, and justify the request with quantitative data from representative jobs already run on the cluster (using the previously awarded developmental allocation.

Generally, when applying for a larger allocation from the AAC, you need to satisfactorily fill in all of the fields on the form. But special attention should be given to the fields:

  • Research (Lay) Abstract: Here you should describe your overall research interests, and then go into more detail about the what you intend to do with the requested HPC resources. This should be a detailed, technical discussion, especially of the computational aspects. The AAC is comprised of faculty members with extensive experience in using HPC techniques in their research, but they might not be experts in your specific domain of science. Please aim your discussion for a general technical audience, and include context as appropriate.

NOTE: The AAC considers all of the allocations in the project when evaluating proposals. If you have multiple allocations (e.g. departmental or paid allocations), you need to include projects which are using those allocations as well.

  • Milestones: This should be a list of scientific goals you hope to accomplish with the requested resources. Focus on the science; the AAC assumes that any interesting results will be published. This list should directly correlate to the resources being requested in the SU Justification and Disk Space Justification sections, and should effectively be a list of "success criteria" for the project.
  • Past Results: For renewal applications, discuss what was accomplished with the previously awarded resources.
  • Publications: For renewal applications, list any publications produced since your last application to which the use of HPC resources contributed.

  • Code Use and Scalability: Here you should be discussing the codes and calculations that you will be using and the parallel capabilities of such codes. You should also be providing scaling data on how well the codes being use perform with different amounts of resources, for each type of job you will be running, in order to determine the optimal amount of resources to request for a job. This data should be from tests that you conducted on the actual UMD HPC cluster you are seeking resources on, and include e.g.

    • Performance vs the number of CPU cores
    • Performance vs the number and type of GPUs being used.
    • If you are requesting more than the standard 4 GiB of RAM per CPU core, you should verify that almost all of your successful jobs are using almost all of the memory allocated to them.

  • SU Justification: This should provide a detailed and quantitative estimate of the amount of compute resources needed to accomplish the research goals as listed in the Milestones section. Typically we recommend that you go through each milestone and discuss the different types of jobs that need to be run to accomplish that goal, and then for each type of job estimate the number of such jobs that would be required (please include a sentence or two explaining how you arrived at that number) along with the job submission specs (number of CPU cores, amount of RAM, and the number and type of GPUs being used (all of this should match the optimal values determined in the Code Use and Scalability section, and average walltimes and SU/costs per job based on your experience running such jobs on the relevant cluster.

NOTE: The AAC considers all of the allocations in the project when evaluating proposals. If you have multiple allocations (e.g. departmental or paid allocations), you need to include the compute resources required for projects which are using those allocations as well.

  • Disk space Justification: If you are requesting additional storage resources, detail here why the additional storage is needed to accomplish the research goals as stated in the Milestones section. Include estimates of the size, number, and type of files needed for a job. Remember that scratch space is only intended for data related to "active" jobs; once a job is completed you should be deleting files no longer needed and moving other files no longer needed for active jobs elsewhere (e.g. SHELL storage).

NOTE: The AAC considers all of the allocations in the project when evaluating proposals. If you have multiple allocations (e.g. departmental or paid allocations), you need to include the storage resources required for projects which are using those allocations as well.

The AAC expects that you collected the needed data listed above while using your initial developmental allocation.

Note

NOTE: The AAC considers all of the allocations in the project when evaluating proposals. If you have multiple allocations (e.g. departmental or paid allocations), you need to include information on projects which are using those allocations in the application as well as the projects for which you are explicitly requesting resources.

Note

The AAC will not grant more than one allocation to a faculty member. If the faculty member is engaged in multiple projects which need HPC resources, the application should generally cover all such projects. The AAC will not grant separate allocations for individual projects or students under the same faculty member.

Tip

Students submitting applications on behalf of their faculty advisor should communicate with their advisor and colleagues to generate a single, comprehensive application covering all research requiring HPC resources. If there are multiple applications coming from different students of the same advisor requesting resources in a piecemeal fashion, this conveys a sense of a lack of organization which might adversely color the reception of the applications.

Below you can find details about each field in the form,

Detailed field list for AAC application form

The following list gives all of the labels for the various fields for the form to request an Allocation from the AAC. This section click to be taken to a discussion of what is being requested by each field. This list is alphabetical, in the detailed discussion fields are presented more or less in order they appear on the form.

Requested for:
This should list the person who is filling out the form. If a student, etc. is filling out the form on behalf of their faculty advisor, this should be the student's name.
(The faculty advisor's name goes in the Faculty Advisor field.
Faculty Advisor:
This field should list the faculty member you are filling out the form on behalf of. If the requestor is a faculty member (e.g. Professor) filling out the form on their own behalf, this can be left blank.
Request Type:
This specifies the type/"flavor" of request, either New Allocation or Renewal. If this is the first project/allocation for you (or your faculty advisor if requesting on their behalf), choose New Allocation. If it is a request to renew or add resources to an existing allocation, select Renewal.
Desired Allocation Name
This is the desired name of the allocation. As the allocation is typically for all research projects for the faculty member (and we generally want this to be permanent), we will usually default the allocation name to something like UNAME-prj-aac where UNAME is the username of the faculty member the allocation is for. If you have a different name for your research group that is likely to be comprehensive, unique, and stable over time, you can enter that here and we will consider using that instead.
Research Title
This should be an one-line title for your research.
Research (Lay) Abstract

Please provide several paragraphs describing your research.
Please include both an overview of your general research program, along with a somewhat detailed account of the research you are proposing to use HPC resources for, and how the HPC resources will be used in the furtherance of that research. This section should discuss the scientific aspects of what you are trying to do; computational and algorthmic details belong in other sections (e.g SU justification, Disk space justification, and/or Code Use and scalability).

The AAC is comprised of faculty members from various disciplines with extensive experience in the use of HPC for advancing research, but do not assume that have extensive experience in your particular discipline.
Please address your comments here accordingly.

Please include in this section a discussion of all research you are undertaking in the coming year which involves HPC resources, even if such research will be using resources in other allocations within this project (e.g. departmental or paid allocations). The AAC will look at all resources on the UMD HPC clusters you have access to when considering your application, so if you have committed resources from other allocations to other projects, you need to tell that to the AAC.

Past Results
(Only for Renewal type applications).
For renewal applications, please list what was accomplished with your previous allocation. Publications, if any, should go in the Publications section. In this section, please describe what was achieved --- usually these would be related to the Milestones listed in the previous application. Even for the renewal "base" allocations, we would appreciate having this information.
Publications
(Only for Renewal type applications).
For renewal applications, please list what publications were at least in part made possible based on the computations done in your previously awarded HPC allocations. Even for the renewal "base" allocations, we would appreciate having this information. We recommend that you enter this information in ColdFront first and then cut and paste here.
Desired Start Date
If you are requesting an allocation well ahead of time, please specify the date when you want the allocation to start. It will default to a week from the current date (i.e. the allocation will start as soon as possible, often in a day or so).
Desired End Date
All allocations have an expiration date, which will default to one year after the allocation is created/renewed. If you do not need/require the resources for a full year, please adjust the date correspondingly. For quarterly allotted allocations, this will be adjusted to the date at which a quarter ends.
Requested Allocation Type

This is a drop-down of predefined allocation sizes for the allocation being requested. For new allocations, or renewing an expiring allocation, this should be the size of the allocation you are requesting. If you are seeking to add SUs to an existing allocation, this should be the size of the new allocation, i.e. the sum of what you currently have plus the additional SUs being requested (in this case, it does not hurt to break this down in the SU Justifaction field).

Development is for "base" allocations Small and Medium are for allocations which can be awarded by the AAC. Large is for allocations which require payment.

Whatever you set here will default the Requested kSU field to the maximum allowed value for that type. You may wish to edit that field to reduce the default value when requesting less than the maximum allowed for that type.

Requested kSU
Please enter the requested kSU. As described in the Requested Allocation Type section, this should be the combined size of all allocations you are seeking --- i.e. if requesting additional SUs on top of what was already allocated to you, this should by the sum of the current SU levels plus the amount of new compute time being requested. This should be within the range determined by the Requested Allocation Type. You will also need to justify the requested kSU in this section in the Disk Space Justification section.
Additional High-performance Scratch Disk Space (TB)
All allocations get a base of allotment of 100 GB (0.1 TB of scratch (HPFS) storage. If that is all the scratch disk space you expect to need, you can just leave this at 0 TB. If you expect to need more scratch space, please enter your expected need (in TB). If you have an existing allocation and are requesting more space, this number should be the total space needed (i.e. the currently allotted space plus any additional space you are requesting). Round to the nearest TB. You will also need to justify the space you are requesting in the Disk Space Justification section.
Additional SHELL (Medium-Term) Disk Space (TB)
All allocations get a base of allotment of 1 TB of SHELL storage. If that is all the SHELL disk space you expect to need, you can just leave this at 0 TB. If you expect to need more SHELL space, please enter your expected need (in TB). If you have an existing allocation and are requesting more space, this number should be the total space needed (i.e. the currently allotted space plus any additional space you are requesting). Round to the nearest TB. You will also need to justify the space in this section in the Disk Space Justification section.
Estimated RAM per core (in GiB)

Please give the estimated amount of RAM that your jobs will need, in GiB, per CPU core. For purely sequential jobs, this should be your estimate of the total memory needed by the jobs; for multithreaded or MPI jobs, this should be your estimate of the total memory needed by the jobs divided by the total number of CPU cores. If unsure, 4 GB/core is a standard value.

Note that if your jobs are requesting more than 4 GB/core, there might be surcharges in the SU costs for the job. And in a renewal application, you should include information in the Code Scalability to demonstrate that your jobs are actually using most of the memory being requested.

"Requested Cluster" or "Renewal Cluster"

This is a drop down list in which you can state the CPU cluster you wish the allocation to be made on. The decision as to what cluster the allocation is placed on is up to DIT and the AAC. However, your request will be considered. If there are specific considerations you think the AAC should be aware of when making a decision as to what cluster, please include those in the SU Justification section.

As currently the only DIT maintained cluster is Zaratan, you can leave this blank.

Processor Need

This is a drop down giving different processor options.
Currently, it only asks if you intend to use

  • CPU: you primarily plan to use [CPUs](/kb/glossary.md#cpu] in your research.
  • GPU: you primarily plan to use GPUs in your research.
  • CPU and GPU: your research will make heavy use of both CPUs and GPUs.

While we do not currently restrict your usage to either CPUs only or GPUs only on the basis of your answer to the above, an honest answer helps our understanding of how the cluster is being used. I.e., if you do not think you will be using GPUs, then answer CPU only. An answer of "CPU only" will not prevent you from submitting GPU jobs, or exploring if your codes can benefit from using GPUs. If you do such tests and discover that GPUs are useful for your research, your answer here does not prevent you from using them --- just please change your answer when you renew the allocation.

Software Requested

This section allows you to list the software packages that you intend to use in carrying out your research.
This is useful our better understanding of how people are using the cluster. The drop down list includes many of the packages installed on the cluster, but as we are frequently adding to our Research Software Library on the clusters, this list is not always up to date. But please glance at the list and select any packages you expect to use. If you require a software package that is not listed, please select Other and fill in the Additional Software Needs field as well.

Your answers here helps us to better evaluate your application as well as improve our understanding of how people are using the clusters, so accurate answers are appreciated. However, we do not restrict your access to software based on this answer; if there is an application "foo" on the list that you did not select when filling out the application, but after the allocation awarded you discover that it would be helpful to your research, the fact that you did not select it will not prevent you from using it. We do ask that if you continue using it that you include it when you renew the application.

Additional Software Needs

This section, like the Software Requested field, helps us better understand your application and the use of the cluster by users. This field is mainly intended so that you can elaborate on what is meant by your choice of Other in the Software Requested field. But you can also use it to specify version requirements of software in the drop-down list.

Please note that the presence of a package in either this or the Software Requested fields does not constitute a promise on the part of the HPC staff to install said software, even if the application is approved. The HPC team strives to make a large library of software packages available to our users, and will make reasonable attempts to install packages on request, but not all packages install nicely, or even are suitable for system wide installations.

Also note that the AAC and DIT do not generally provide licenses for licensed software.
The HPC team will attempt to install licensed packages on request, assuming the requestee can provide proof of license (and likely they will need to provide installation media). Some of the packages in the drop down list are proprietarily licensed --- in a few such cases they are covered by a campus wide site license, but many such cases are only covered by licenses granted to certain departments and/or research groups. Your inclusion on the application, even an approved application, does not grant you access under these licenses --- we will open a discussion with you about licensing in such cases.

NOTE: Do NOT purchase licenses for software you intend to use on one of the UMD maintained HPC clusters without consulting with the HPC team first.
Not all licenses are suitable for use on an HPC cluster, and we do not wish you to spend money on a license you cannot use on the cluster. Please contact us any such purchases.

SU Justification

In this field, you are requested to provide a justification for the amount of compute time that you are requesting. In order to try to keep the average length of time jobs wait in the queue acceptable, we limit the total amount of compute time over all allocations awarded to minimize the amount of oversubscription. Thus compute time awarded to one group reduces the available pool of compute time to award to future groups. So the AAC gives much weight to this field in their decision making process.

This section is where you describe your computational strategy, contrasting with the Research (Lay) Abstract section which is more about the science. In particular, for allocations from the AAC, the AAC wishes to see a detailed quantitative justification of the compute time requested.

In many cases, this can be as simple as going through each research Milestones and discussing the types of jobs that will be needed to accomplish that goal. Then for each such job type, estimate the number of such jobs that you will need to run (and please give an explanation of how you arrived at that number). Also describe the typical job parameters (e.g. number of CPU cores, amount of CPU memory, the number and type of GPUs if applicable and the average walltime and SU cost/job) for these jobs. The number of CPU cores, GPUs, and amount of memory should match the "optimal" parameters for that type of job discussed in the Code Use and Scalability section, while the average walltime and SU cost should be based on your experience from running such jobs on the cluster.

If you are requesting an increase to an existing allocation, it would be helpful to mention such, along with the existing allotment of compute time and the amount of additional compute time being requested.
Generally, you do not need to re-justify the SUs already consumed, just what will be needed for the research that is planned.

If however the additional time is needed because you need to revise your previous estimates of compute time needed (e.g. you underestimated the memory consumption so a larger memory factor for CPU time is needed, or you discovered that you need to increase the detail in the calculations, etc.), you should explain why the previous estimates were off --- while habitually underestimating the resources needed will likely not be viewed favorably, the AAC is comprised of experienced researchers who understand that the unexpected sometimes occurs while performing advanced research.

NOTE: The AAC will look at all allocations in this project when evaluating your application and determining whether you need additional resources from the AAC. E.g., if you have an 150 kSU/qu allocation from your department and are requesting (and have justified in this section) a need for 250 kSU, the AAC is going to question why you need resources from the AAC as the 150 kSU/qu from your department would cover the justified 250 kSU in 2 quarters. If you have other research projects which will requiring HPC resources from these other allocations, you should mention them in this application, both here and in the Research (Lay) Abstract section. That way the AAC will see that the resources allotted to you in any other allocations are already committed to these other projects.

If you are only requesting an increase in disk space, but not any additional compute time, you can just enter "No change to SUs requested". Be sure to complete the Disk space Justification section.

If you have reason to prefer a specific HPC cluster over another, it [% INCLUDE glossary_term term="hpc" text="HPC cluster" %] over another, is recommended that you include the reasons for your preference here. Although DIT and the AAC have the final say as to which cluster your allocation is granted on, your preference (as indicated in the Requested Cluster or Renewal Cluster fields, together with your justification for that request here, will be considered and honored if feasible and reasonable.

Disk Space Justification

If you requested additional disk space in either the Additional High-performance Scratch Disk Space (TB) or Additional SHELL (Medium-Term) Disk Space (TB) fields, this is where you are requested to provide a justification those requests. Please justify each type of storage separately.

If you are only requesting the base amounts (e.g. 100 GB of scratch and 1 TB of SHELL storage), you can just enter "No additional storage".

If you are just requesting additional compute time for an existing unexpired allocation (but no additional storage), you also can just enter "No additional storage". However, if the allocation is expired (or expiring shortly), please include a justification in this section even to continue the same level of storage as previously requested. If the justification from your previous application still applies, you likely can just copy that.

In this field you should state how you arrived at the amount of disk space that you are requesting. For scratch space, this should be related to your estimate of the amount of scratch space required for running a single job (e.g. the number of sizes of input files, temporary files, and output files) multiplied by the number of jobs you expect to be running more or less at the same time (remember that after a job finishes, you are expected to delete or move off of the scratch storage tier any data no longer needed for active jobs).

For SHELL storage, remember that SHELL storage, you should indicate the total amount of data that will need to be stored over the lifetime of the project. NOTE: Please remember that SHELL storage is not backed up and is not intended as a long term archive.

Code Use and scalability

This section is where you should discuss some technical aspects of your computation strategy. In particular, the extent to which you calculations are parallelizable. In particular, you should at least discuss whether your codes are capable of being parallelized across multiple nodes or are only able to use multiple cores on a single node, or even if they can only run sequentially.

If this application is just to increase the storage allotment for an existing allocation, you can just enter "no additional CPU time" or similar. However, for all other applications (e.g. renewal applications or other

For developemental or base level allocations, you need not put much here, e.g. "unknown" or "base" or similar.
However, any information you do volunteer will help us better understand how you are using the cluster.

For applications for larger allocations (i.e. requesting more than the initial 50 kSU base level), this section is required and will be looked at closely. The more SUs being requested, the more detail will be required.

In particular, for applications for larger allocations the AAC will want to see a discussion of how the performance of the codes being used scale with the amount of resources being allocated to the job in order to show to the AAC that you are using the cluster resources efficiently. Typically, the performance of jobs will increase significantly as additional resources (e.g. CPU cores or GPUs are made available to the job, up to some threshold value.
Increasing the resources beyond that value yields little if any increase in performance, and indeed in some cases even degrades performance. This threshold is generally best determined empirically. The AAC will wish to see that you have conducted benchmarks on the requested cluster to map performance as a function of the number of CPU cores, and show that your proposed job configuration is in the range where the job is still scaling well. This is discussed more in the section discussing how to ensure CPU efficiency.

If your CPU jobs are requesting more than the default amount of memory (usually 4 GB per CPU core), the AAC want to see that you have looked at the jobs to make sure they really require the requested memory.
This is usually best determined by using the seff command; for more information see the section on ensuring efficient use of memory.

For jobs that rely primarily on GPUs for computation, you should discuss whether the code can use multiple GPUs or not, and if it can use multiple GPUs whether it is restricted to GPUs on the same node. If multiple GPUs can be used, you should do a similar process of determining the performance of the code as a function of the number and type of GPUs being used in order to find the optimal GPU configuration to use.

Milestones

This section is where you should list some specific, concrete and verifiable research and computational goals you hope to accomplish with the HPC resources you are requesting in the application. While it is understood that your research and use of HPC resources is likely to be an ongoing, years-long process, the accomplishments you list should here some specific, concrete, measurable scientific goals that you hope to realize before the expiration of this allocation (typically a year from the initial request). When you apply for a renewal of your allocation, you should hopefully be able to write the Milestones from this application into the Past Results section of the renewal application (assuming they were actually accomplished).

The AAC assumes that you will be publishing any significant scientific accomplishments, so it is redundant to include things like proposed publications, etc. --- the AAC wants to see here the science that you hope to achieve.

The goals listed here should directly relate to the what you list in the SU justification and Disk Justification sections. It is generally recommended that big, overarching research goals be broken into smaller, specific tasks required to accomplish that goal, as this can help with writing good Code Use and scalability and SU Justification sections.

This list of Milestones should essentially be a list of "success criteria" for the project --- if all (or at least most) of the milestones are accomplished, the research project would be considered successful.

HPC Experience

This checkbox simply asks if you have experience using HPCclusters and methods. If you select yes, we will also request you enter the approximate number of years of experience you have. If you have more than a few years of experience with using HPC clusters, feel free to round off to the nearest 5 or 10 years; we do not need a precise number.

This field is just to help us collect some data about who is using the campus HPC resources, i.e. how many novice vs experienced users. Answering "No" will not cause your application to be rejected (although will raise some questions if this is a renewal application).
We encourage researchers who have not used HPC resources in the past to explore whether HPC techniques could benefit their research.

Unix Experience

This checkbox simply asks if you have experience using Unix or Unix-like (e.g. Linux, FreeBSD, etc) operating systems. This field is just for us to better understand our user base; answering "No" will not cause your application to be rejected.

The UMD HPC clusters, like most HPC clusters, run on Unix-like (specifically Linux at UMD) systems, and some advanced functionality is facilitated by (if not requires) some fluency with Unix. However, we have a web-based OnDemand portal for interfacing with the cluster which greatly reduces the amount of Unix familiarity needed to use the cluster. We hope that such can help make HPC techniques more acessable to researchers at UMD.

How do I get access for a class I am teaching?

As befits an institute of advanced learning, DIT is willing to make a reasonable amount of HPC cluster resources available to classes in most cases. If you are teaching a course and wish to use HPC resources, please submit a request to HPC admins for class access. Such requests should come from the instructor of record for the class, (if you are a student, have your instructor make the request) and should include the following information:

  • Please indicate whether this is an official UMD course (i.e. in the official UMD schedule of classes) or not. If not, please explain what the course is for and how it connects with the academic mission of UMD.
  • the course id (e.g. AMSC 663 or BIOE 658B). For use outside of official UMD courses, please provide an URL describing the course/workshop/etc.
  • the title of the course (e.g. "Advanced Scientific Computing" or "Introduction to Medical Image Analysis")
  • the estimated number of students to be enrolled in the course
  • the semester for the course. If this is part of a multi-semester course sequence and you wish to have the course allocation continue across semesters, please provide the above information for both the first and subsequent semesters, and discuss that here.
  • Please describe how the HPC resources are intended to be used in the class. In particular, discuss the following points (but feel free to expand beyond these points):
    • Will the HPC be used for in class "live" demonstrations by the instructor? How frequently? Will you need reservations of resources for such, and what resources?
    • Will the HPC be used for in class "labs" wherein students access the cluster in a "lab"-like setting (with faculty and/or TAs present for assistance). If so, how frequently and will you need reservations for such?
    • Will the cluster be used for regular homework assignments? How frequently? How much resources do you expect will be needed for this (per student and total)?
    • Will the cluster be used for long term (i.e. once per semester?) projects? How much resources do you expect will be needed for this (per student and total)?
  • For all of the above, please indicate whether you will require CPU only, GPU, or a mix of CPU and GPUs. If you will be using GPUs, what GPUs types are you able to use --- in general we would ask that you consider making as much use of the a100_1g.5gb GPUs (a virtual GPU made by splitting an A100 into 7 pieces) as possible.
  • Please summarize the total amount of resources that will be needed for the class throughout the semester. Include both CPU, GPU, memory, and storage (for both scratch and SHELL tiers) in these calculations.
    Generally, requests for 20 - 50 kSU and 0.1 - 1 TB of scratch and 1 TB of SHELL will be readily granted. Larger requests will be considered.
  • It is assumed that all students for "official" UMD courses will be formally registered and be in the UMD databases. For less "official" courses, please describe the expected student base --- will they be exclusively members of the UMD community, a mix of UMD and non-UMD people, or (almost) exclusively non-UMD people? Please give estimates of UMD vs non-UMD people. There are added difficulties associated with non-UMD access to the cluster.

Please provide the above information to the best of your ability when making a request. If you are unsure what is meant or how to answer something, let us know and we will try to clarify. The more completely you answer things the faster the process will go.