Update form attribute dynamically

Hi There

I am currently testing an interactive desktop session using Slurm and have encountered a question regarding the form.yml and submit.yml.erb files.

In my use case, I would like to display the “slurm script” attribute, which includes the #SBATCH directive, along with other attributes such as “CPU” and “hours.” This is intended for users who want to specify the Slurm script precisely.

However, the documentation mentions that submit.yml.erb dynamically processes the form.yml, and it seems that having the YAML file, form.yml, run dynamically by itself may not be possible.

Do you have any suggestions on how I can implement this feature? I have attached the current form on my web portal

Thank you.

Hey, I’m really sorry this slipped passed me and I just noticed it.

The form can still have dynamic content, we do that quite frequently in some apps. There are some examples below:

In the above, the groups are dynamically generated and fed into the form for choices to select. Is this the type of dynamic behavior you were after?

Hi Travert,

Thank you for your response; it’s great to learn that the form can be made dynamic.

I was contemplating a change that would allow the options selected by users in the form to appear dynamically within the form. For example, when a user selects ‘node_type’ as ‘CPU’ and ‘hours’ as ‘4’, the corresponding #SBATCH arguments are generated in the web portal, which advanced users can then flexibly edit.

We do have some features around dynamic changes such as this to effect number fields or choices a user makes in one form field affecting the choices available in another. The docs are here:

But, this might not quite be advanced enough for what you are attempting as it sounds like you want the choice in one field to then partially populate a field in another? As in those CPU and TIME selections then populate part of the SBATCH command to select from?

Yea, so we don’t really want to provide #SBATCH directives in the script.

Instead we typically instruct sites to submit CLI flags for the same.

So, for example, you can use bc_num_hours for setting the walltime limits (the hours the job will run for).

Anything with bc_ (or auto_) prefixes that are documented here as pre-defined elements know how to submit themselves. I.e, you don’t have to update the submit.yml.erb when using them.


Cores on the other hand - we don’t have automagic support for them. So you need to add an entry to the form that’s something like cpus and then use that value in the submit.yml.erb in the CLI flags.

Here’s a simple example of populating cores (we call it ppn here for historic reasons) then using that value in the command line for sbatch. You see we set --ntasks-per-node.

So in sum - you want to use the CLI flags in the submit.yml.erb instead of SBATCH directives in the script.

Hi Travert and Jeff,

Thank you for the response and sorry for my delayed reply.
I understand it is not recommended to let user provide #SBATCH as OOD is intended to remove barrier of entry to use slurm. I thought it would be an interesting feature for advanced users who want desktop environments.

I will keep checking the documentations and see what I can do. Thanks for the help :slight_smile: