Projman will check a number of things when you ask for more resources. If you ask for storage it will check if the storage is needed and if the project looks like it's active. If you ask for more core hours it will check if you need more core hours at the moment and if the efficiency of the jobs run lately are efficient enough for you to get more hours. If any of these checks fail you will get a message about it and a link to this page where we can explain the messages in a bit more detail.
If the changes you request passes all checks you will see a summary of the changes that will be made under the heading "The following changes were successful".
There are two other types of messages your can get; errors and warnings. The errors under "The following changes failed", and the warnings will be displayed under the heading "Additional notes". The errors mean that something was so wrong that the requested change could not be done. The warnings are messages that mean something went a little bit wrong, but the script could adjust your requests slightly and make it possible to carry them out.
The requested number of core hours exeeds 5 000: Larger projects have higher demands on how they use their resources than smaller projects. If you need more than 5 000 core hours you will have to apply for a medium project in SUPR.
The project still has core hours left to use, only X out of Y (Z%) is used: As the message say, the project still has plenty of core hours left to use. The stats are updated daily (nightly), so if you used up all your remaining hours today you might still get this message. If you do still have hours left, use them and ask for more when you are closer to the core hour limit. The efficiency of the used hours will be used to determin if you can have more or not.
The job efficiency is too low: As the message say, the efficiency of the used hours is too low to allow you to have any more hours without correcting your scripts. Please have a look at the jobstats user guide for more infromation about how your can improve your efficiency.
No resources used: Some projects only use our storage as a delivery system for sequencing data. The actual analysis takes place somewhere else, like the research groups own server or other place. Since we (unfortunately) have limits of how much data we can store on our hard drives, we would rather see that the storage is used by projects that actually use our clusters for analysis as well. Long-term storage is not a service we provide, as that is the responsibility of the researchers host universities. The long-term storage of all bioinformatics data by our users would have overfilled our storage system years ago if we were to keep it all.
The requested duration date is further than 12 months in the future, reducing it to fit: The duration date has been reduced to 12 months from now.
Core hour usage is very low: This is usally one of the signs of an inactive project. If the storage activity is also low your project will be considered as inactive and getting project extensions will be hard. If you are using the data in this project in analyses carried out in another project you might want to consider moving the data to that project instead. That way you have one less project to worry about.
The data in the projects has not changed in any large extent, seems like an inactive project: The data has hardly changed anything at all during the last 6 months, and this is a sign of an inactive project. If this is old data you should delete it or move it to your university's local storage.
The efficiency during the last 30 and/or 3 days of the project is below 70%: The efficiency of the last 30 days is becoming so low that it might be a problem to get more core hours if you run out. Please look at the jobstats user guide for information on how you can improve your efficiency.
The requested proj/nobackup increase is more than 5TiB (X to Y TiB): To avoid overallocation we increase sizes in steps. Run this script again when you are starting to run out of space, or contact email@example.com if you have a reason this larger increase should be implemented directly. The requested size is reduced to 5TiB from your current allocation. You can run the script again when you are close to running out of storage again.
The requested expiry date is further than 12 months in the future: Since extensions and allocations are only increased 6 months at a time, the requested expiry date is changed to 6 months from now.