Add option to `xmlchange` to reset case

[jasonb5]

Currently a ./case.setup --reset is required after changing some variables with ./xmlchange e.g. NTASKS, NTHREADS, NINST, etc.

This feature would add an optional --reset to ./xmlchange which would reset the case after changing the variables. This convenience option would simply save the user a command, not intended to replace the current workflow.

Example, ./xmlchange NTASKS=56 --reset.

[whannah1]

I don't understand how this is helpful. Why is it better to require the user to know about this flag instead of knowing to redo the case setup step? The latter seems much more transparent. Also, I'm not sure this even applies to all xmlchange commands.

[jasonb5]

I've updated the description.

You are correct this does not apply to all xmlchange commands.

It's also not designed to replace the current workflow, just a optional convenience flag intended to save the user a command when changing variables that require a case reset.

[ekluzek]

@jasonb5 I see the point where this could sometimes be a convenence. It could be used for experts that know when a reset needs to happen.

But, I'm concerned that adding it, would be at the expense of new users, who don't know when it shoudl be used. By, having it as a seperate step -- it does make the user recognize it as a distinct step. I'd also be concerned if new users thought they always had to use it -- and started using it all the time. Or just if new users then became confused between the two ways of doing things. The xmlchange itself is directed to just the variables that you are changing -- wheras the case.setup is a global operation over the whole case so seems good to keep distinct.

Personally I ussually end up doing a list of xmlchange commands and do the case.setup --reset at the end, so it's not repeated. This potentially has you ending up doing it more often if you keep the --reset option in each xmlchange command, just because you are copying previous xmlchange commands.

And for robustness -- if you use it for a variable that doesn't need it -- do you still run the "reset" -- or flag that as an error? I suppose case.setup, allows you to run it as often as you like without a warning, so maybe this would function similarly? I suppose it's fine that the "case.setup --reset" always runs even when it's not needed. It could maybe detect that it wasn't needed and say something about it -- but that also might be confusing to users. So the same might apply here for this option.

I'm not necessarily convinced this shouldn't happen -- but I wanted to talk through some of the disadvantages I'm concerned about. Maybe if it's just documented well as an expert user, convenience option?

[jasonb5]

@ekluzek This would be an expert option.

I can see how this might be confusing for new users. Good documentation and logging could help with that. Both workflows would result in the same outcome so it would really be user preference on which method is used. While ./xmlchange and ./case.setup have distinct purposes there is some overlap when variables are changed that required a call to ./case.setup or ./case.build, we do print warnings from xmlchange when these are required.

The main use case I had in mind was additional changes made after the initial user customization for eample I customized the case, called setup and build but want to change say NTASKS which requires ./case.setup --reset before I can submit.

Since this is intended to be an expert option, it would be up to the user to know when to use it. It will not be smart and attempt to know whether the case needs to be reset, simply make the requested changes and reset the case.

@rljacob @jedwards4b @jgfouca What are your thoughts?

[jedwards4b]

Frankly the user is already alerted to the need to run case.setup --reset, I see no need to do it for them.