Closed vdejager closed 1 year ago
Thank you for your user request, Vic! I have opened an internal ticket to fulfill this request.
@vdejager we have implemented the feature you requested, and it will be available in the next release of PGAP. In the interim, it would be very helpful to us if you could test it by running pgap.py from the dev branch (which can be found here: https://github.com/ncbi/pgap/blob/dev/scripts/pgap.py).
Please note that you'll need to provide the --no-self-update option.
Let us know if you have any questions.
Thanks, I will try to test it this week.
Best Victor
Thanks, works perfectly
Op di 15 aug. 2023 om 16:44 schreef george-coulouris < @.***>
Closed #240 https://github.com/ncbi/pgap/issues/240 as completed.
— Reply to this email directly, view it on GitHub https://github.com/ncbi/pgap/issues/240#event-10097837502, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRXHZYRRWT7W7PR4XLYLG3XVODNNANCNFSM6AAAAAAT5ZIFW4 . You are receiving this because you were mentioned.Message ID: @.***>
Is your feature request related to a problem? Please describe. When submitting a PGAP singularity job using SLURM to a node slice, PGAP grabs all cores, which leads to problems for the other jobs running on that node
(our nodes have 128 cores /256 GB and a slice is 32 cores / 64GB, more than enough for our average PGAP job)
Describe the solution you'd like determine the number of cores from the scheduler info, see additional context
Describe alternatives you've considered provide the --cpus option similar to the node job settings. The PGAP logs still show 128 cores.
Additional context https://stackoverflow.com/questions/56267313/determine-number-of-processors-assigned-to-job