Passing in SLURM Constraints

Greetings,

The Cori system at NERSC now requires batch submissions to include a constraint parameter (-C) to specify whether to run on Haswell processors or KNL processors.

I was able to handle this with the pre_rocket option in my qadapter config file.

pre_rocket: “#SBATCH -C haswell”

Is that the “recommended” way to deal with this or is there another mechanism.

Thanks,

–Shane

Hi Shane

There are two ways to do this:

i) The manner you described with “pre-rocket”

ii) to add “constraint: haswell” to your my_qadapter.yaml (recommended way). I am pretty sure this is the same thing as -C but let me know if not.

More details:

The way the qadapter.yaml works is that it fills in the variables for the template located in:

fireworks/user_objects/queue_adapters/SLURM_template.txt

You can see that the SLURM_template.txt file has a line that says:

#SBATCH --constraint=$${constraint}

with the $${} notation indicating a variable to be set in the my_qadapter.yaml file. If you don’t set the variable, that entire line gets skipped.

If for some reason we did not already have the “constraint” parameter in the SLURM template, you could add it to fireworks/user_objects/queue_adapters/SLURM_template.txt and submit a pull request. In this case, it seems to already be there.

Best

Anubhav

···

On Wednesday, March 1, 2017 at 3:48:03 PM UTC-8, Shane Canon wrote:

Greetings,

The Cori system at NERSC now requires batch submissions to include a constraint parameter (-C) to specify whether to run on Haswell processors or KNL processors.

I was able to handle this with the pre_rocket option in my qadapter config file.

pre_rocket: “#SBATCH -C haswell”

Is that the “recommended” way to deal with this or is there another mechanism.

Thanks,

–Shane