Clashes between default options of different schedulers about experi HOT 1 OPEN

Thanks for all the issues you have raised in relation to SLURM. It will take me a little while to work through and consider all of them. I don't actually have a production SLURM system to test on so I really appreciate you testing this functionality out.

Is this just the clash of the N? Possibly also o. Yes this is definitely a bug

I definitely agree that the SchedulerOptions class and subclasses needs some refactoring. I thought there was going to be far more overlap between the different schedulers when I started writing that code.

It would be better to have some structure which allows new users to easily plug in the options for their particular scheduler, and not have to worry about whether they have correctly overwritten all the default behaviour.

This is exactly what I would like. It would probably be possible with an abstract base class, yet that doesn't help that the classes are rather clunky.

Or just do away with defaults completely...

One of design goals of the project is that there are sensible defaults. I realise I should document this, along with the other design goals somewhere #67. An alternative idea to this I have had is to use system specific configuration options #52, where the general options like name, are specified generally, then something like Project which is specific to a system specified separately.

Again thanks for raising all the issues/pull requests, I am getting to them all.

from experi.