order of run directory setup about cice

[apcraig]

@eclare108213 . I just want to clarify. You want the run directory to exist before even the build script is executed, not as part of the build script (for instance), correct?

[apcraig]

Also, just wanted to discuss this a bit. The idea behind the scripts is that at each step, the user can make changes and continue. So cice.setup just creates the case directory, cice.build creates the executable, and cice.run sets up the run directory and runs the model. If a user wants to change the run directory name in cice.settings before doing cice.run, that works perfectly fine.

If we start to create/do things before we need to, that leads to some confusion about the order of operations and what users can change as they progress. Having said that, most people will probably use the default run directory on most machines. What we can do is have the cice.setup script create the run directories. Then, if the user changes them after the case is created, the new run directory will be created as now, when the run script is executed. But the default run directories will also exist. This might cause some confusion, but that's sort of up to the user to sort out.

The other issue with this approach is keeping unique case and run directories. So, for instance, you run into the situation where a case is created, then deleted due to an error in the cice.setup call and recreated. But maybe the run directories have been created and that creates problems later.

I think another option would be to add a new script to the case directory called something like setup_run_dirs. That would be called by the cice.run script, but it could also be run by a user anytime. I think I prefer that implementation. Would that be an acceptable approach?

[eclare108213]

Having a separate script that the user could run independently, but which is also called by cice.run, would be fine as long as existing directories and content aren't wiped out by the second call. My aim is to be able to get the run directories set up before a job is submitted to actually run them. For standard testing this is not important, but for development or production, often the configuration needs to be tinkered with to get it right the first time, and that can't be attempted until the run directories exist and are populated, and at the moment that doesn't happen until a run job is submitted. So maybe this shouldn't be thought of as pulling the run directory creation forward so much as pushing the run command to the very end. It would be nice to be able to tinker while the code is being compiled, though, since that process takes a while. I do like that the user can change settings midway through the process and keep going, so let's try to keep that flexibility.

[apcraig]

Setup_run_dirs.csh was added in PR#125 in the configuration/scripts directory.