You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A proposed --reset argument on drivers would direct them to remove run materiel before proceeding.
In the simplest and safest case, this might simply remove the entire run directory. This would probably be easy to implement, but may also not add much value on top of rm --rf rundir, assuming rundir is readily known, though it's possible that it is computed in the config based on Jinja2 expressions, possibly involving cycle and/or leadtime information, in which case the --reset switch would free the user from having to figure this out, or mistakenly removing the wrong directory.
More nuanced behavior might remove only the affected asset(s). For example, uw some_driver namelist_file --config <config> --reset might only remove the namelist file. uw some_driver linked_files --config <config> --reset might remove all the linked files. Every task method would need to define its own logic for removing the asset(s) it is responsible for, and might then provide logic, before any yield statements, like
if self._reset: # set in the constructor
# remove this task's assets
Either way, I'm not sure how much value this really adds. For example, if a user modifies their input config, they don't necessarily know which assets in the run directory are affected by that change, so how would they know which uw call to make to reset and re-create those? If they do know that, they can (often) just as easily just manually rm those assets – assuming they know where they are, but they are probably trying to recreate them because they've inspected them and found issues, so they do know where they are. Another edge case would be a desire to remove a bunch of assets (e.g. a bunch of linked files), which might involve a long sequence of rm commands instead of a single uw --reset command.
The text was updated successfully, but these errors were encountered:
A proposed
--reset
argument on drivers would direct them to remove run materiel before proceeding.In the simplest and safest case, this might simply remove the entire run directory. This would probably be easy to implement, but may also not add much value on top of
rm --rf rundir
, assuming rundir is readily known, though it's possible that it is computed in the config based on Jinja2 expressions, possibly involving cycle and/or leadtime information, in which case the--reset
switch would free the user from having to figure this out, or mistakenly removing the wrong directory.More nuanced behavior might remove only the affected asset(s). For example, uw some_driver namelist_file
--config <config> --reset
might only remove the namelist file.uw some_driver linked_files --config <config> --reset
might remove all the linked files. Every task method would need to define its own logic for removing the asset(s) it is responsible for, and might then provide logic, before anyyield
statements, likeEither way, I'm not sure how much value this really adds. For example, if a user modifies their input config, they don't necessarily know which assets in the run directory are affected by that change, so how would they know which
uw
call to make to reset and re-create those? If they do know that, they can (often) just as easily just manually rm those assets – assuming they know where they are, but they are probably trying to recreate them because they've inspected them and found issues, so they do know where they are. Another edge case would be a desire to remove a bunch of assets (e.g. a bunch of linked files), which might involve a long sequence of rm commands instead of a singleuw --reset
command.The text was updated successfully, but these errors were encountered: