add "-q" option.
Default is still "cygno-custom", because it has larger number of cores and memory. But resources are limited.
If one uses "-q cygno", it will submit to the standard queue dedicated to CYGNO, where more jobs should run, but:
it cannot mount the /mnt/ssdcache to store the input (it will automatically use /tmp/$USER), so it will be a bit slower to read, not a problem at all - the time is CPU-dominated
max number of threads is 8 and max RAM is 9GB. The submission script thresholds this automatically
So to recap:
---> <script> -q cygno-custom (or without the option, since it is the default)
sends the jobs with 24 core / 30GB RAM. Faster, but only if the queue is free. It's your subaru impreza
---> <script> -q cygno
sends the jobs with 8 cores / 8 GB RAM. Slower, but you should have more likely some job running. It's your FiatAgri 130
add "-q" option.
Default is still "cygno-custom", because it has larger number of cores and memory. But resources are limited.
If one uses "-q cygno", it will submit to the standard queue dedicated to CYGNO, where more jobs should run, but:
So to recap: --->
<script> -q cygno-custom(or without the option, since it is the default)sends the jobs with 24 core / 30GB RAM. Faster, but only if the queue is free. It's your subaru impreza
--->
<script> -q cygnosends the jobs with 8 cores / 8 GB RAM. Slower, but you should have more likely some job running. It's your FiatAgri 130@baracch @gdimperi @gmazzitelli @davidepinci