Skip to content
Snippets Groups Projects

Allow user to overwrite Scheduler parameters when restarting.

Merged Matthieu Schaller requested to merge allow_scheduler_changes_on_restart into master

I think this does what it says on the tin.

All the changeable Scheduler parameters are now read in again from the fresh YAML file in engine_config(), which should allow users to overwrite them when restarting.

The YAML file itself is re-read anyway and passed to engine_config().

What do you think?

Merge request reports

Merged by Matthieu SchallerMatthieu Schaller 5 years ago (Aug 12, 2019 11:06am UTC)

Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • @jch I think this should allow you to do what you want.

  • Thanks! I was going to have a go at this based on Peter's suggestions but I hadn't had time yet. I'll try this with the z=1 restart file.

  • Yes that will give Richard his effect, but these values will not be used in any calls outside of engine_config(), you'd need to change the engine->parameter_file pointer as well, but even then those values were not used in the original engine_init() (looking at some of those I'm sure they could be moved).

  • Note in passing, we are saving the re-read parameter file to used_parameters, not the parameter_file values. That is also a mess.

  • mentioned in issue #605 (closed)

  • Yes, it's all quite messy....

    The parameter file stored in engine is almost never used and definitely not used to recover values. My understanding is that on restart, we re-read the YAML file, read the restart files and then call engine_config() with the new parameter file. So everything that is set in main() or engine_config() can be (and will be) overwritten when restarting.

    Since the scehduler values John and Richard are after are globals, I think this version will overwrite them after they have been restored to their former values in space_struct_restore().

    Really not clean but a working solution for this specific problem...

  • Do we want to merge this as a temporary measure since it is as bad as what is done for the other variables until a longer term solution (#605 (closed)) is implemented?

  • I'm happy to just use this branch. It looks like it will be easy enough to keep up to date with master.

  • Unless anyone is against it, I'll nevertheless merge this. Better than having to manually merge this for every test. We just don't have to document this feature before a better solution is implemented.

  • mentioned in commit 4f738eae

Please register or sign in to reply
Loading