cluster config discussion

[JenkeScheen]

Took a first shot at extending the cluster config generator page. Relates to branch cluster_config. Some notes:

• currently the submit button is being 'pushed out of the page', i.e. it disappears under the bottom bar unless I zoom out to ~30%. Needs to be fixed somehow.
• I'm not sure if the example paths are the cleanest way to go. Giving the example as a default value creates the risk of users leaving the example in and then downloading the config file with the example path in it.
  • perhaps it would be possible to have 'extended' help buttons with a pop-up that summarises what the point is of the field and what the value should look like?
• I have not made any changes to the way this information is ported into config.py so that is still to do.
• I have not included any checks to see if inputs are valid. Should be easy to do once we're happy with the fields.

some less important notes:

• we might want to add sub-headers to split the form into some sections (i.e. main stuff, paths to stuff, further SLURM settings, etc)
• the runtime field could benefit from a slider/time picker, but we have to make sure it ends up as d-hh:mm:ss
• For the additional SLURM module it would be best to have a field, then a '+' button to add another field (i.e. fill in another module), etc.
• preferably we'd have QDYN/QPREP/QFEP in uppercase. Not sure how to do this.

disclaimer: I have little understanding of what happens with this config file. It might be worth for one of the Q people to check whether this all makes sense and whether any info is missing/redundant.

[xbello]

• Submit button: it is what it is. Lots of inputs -> huge form -> bottom of the form out of screen. Inputs can be made narrower, though.
• Example paths: It looks clear to me. If someone is going to deal with Slurm, I expect him to know how to set a path. Maybe make more clear if paths are relative or absolute.
• Should be straight forward to do, but tedious.
• This verification is up to the config reader (e.g. qligfep code): do the dir exist? do it include the needed binary or files?

Extras:

• Extra headers: AKA fieldset, they rock.
• Gonna look into it, maybe somebody already did the job for us.
• Didn't understand.
• Uppercase: gonna look into it, should be easy.

disclaimer: you're right. I have this feeling that this is going to be in a bundled file, along with the needed PDBs and SDFs and Jsons and friends, so the user decompress it and it just works. Ideally, the Q program can read this bundle directly, if we can agree on a structure.

[JenkeScheen]

to clarify that extra bullet point: I mean something like this: https://formidableforms.com/features/dynamically-add-form-fields/ but simpler (i.e. just the fields and the + button).

[xbello]

to clarify that extra bullet point: I mean something like this: https://formidableforms.com/features/dynamically-add-form-fields/ but simpler (i.e. just the fields and the + button).

Got it. Messy to implement, but it could be done.

[JenkeScheen]

OK, good to know it's at least possible. Again, not sure if this is worth it because I don't understand why users would want to load additional modules (Q is Q, why would it need other modules?)

edit: the only reason I can think of why users would want additional modules is when they are writing custom code to run FEP with other software interacting with it. Which is pretty much the exact opposite of what we're trying to accomplish for this project (i.e. automating Q FEP)

[xbello]

Commits f79238c to cddfa88 should address some problems:

• Sample paths added as placeholders (i.e. they disappear as soon as you start writting).
• Splitted the form in three fieldsets.
• Runtime is now a DurationField, which parses into something like a timedelta (but not quite).
• Uppercase for some fields.

Main TODO: translate the fields from the form into the config.py file (template at cluster/templates/cluster/config_detail.html). Notice that despite having a Html extension, this file is somewhat between a shell script and a Django template.