Delete results if parameters/inputs changed

BaRatin-tools / BaRatinAGE

BaRatin Advanced Graphical Environment

https://baratin-tools.github.io/en/

GNU General Public License v3.0

4 stars 0 forks source link

Delete results if parameters/inputs changed #17

Closed JeromeLeCoz closed 10 months ago

JeromeLeCoz commented 1 year ago

Wouldn't it be safer to delete the results (RC prior, RC post, flow series) when changing one of the parameters or inputs used to calculate them? On the display, one can currently see results that do not correspond to the inputs/parameters (e.g. a RC post with a different set of gauges than the one used to calculate it).

benRenard commented 1 year ago

The problem should be addressed indeed, but I can imagine several ways:

force deletion as suggested
force recomputing of all 'children' objects
Flag all 'children' objects as 'out of date' and use some visual clue to make this flag apparent
ask user what to do amongst the 3 options above
others?

JeromeLeCoz commented 1 year ago

I think we should apply a single option. I wonder why a user would change the inputs/parameters of a RC (for instance) if not to recompute that RC immediately? Then deletion looks logical. Same thing for children objects: you may wish to test alternative hydraulic configs and keep your RC / series results, but then you would create anoter hydraulic config, not change the one already used for the RC/series you want to keep...

Maybe I'm too strict here but I think that automatic deletion of all children objects is the most logical solution (maybe with a warning?).

IvanHeriver commented 1 year ago

I do not have a clear opinion but I think we should keep things simple: if a parent gets deleted or modified, all children should be deleted (or recomputed). After prompting the user to confirm, of course. In addition, maybe ask the user if he/she wants to duplicate the item (gauging, hydro conf, etc.) instead of modifying it?

The "out-of-date" flag approach is the approach which was actually used in BaMit but I'm not sure I like this solution.

IvanHeriver commented 1 year ago

In addition, maybe add a visual indicator next to the parent element (in the navigation panel) which clearly indicates that this element is being used by another element.

IvanHeriver commented 10 months ago

BaRatinAGE v3 address this issue using the following approach:

any change that would affect a BaM result (rating curve or hydrograph) makes a warning appear
if the changes that happen are within the current component (e.g. change in RC stage grid), changes can be canceled
if changes are in one of the parent component, the user is offered the possibility to create a new parent component matching the current result

The latter feature was chosen to address the fact that a parent component should not be changed from a child component because it can be used by other children.

This is a choice resulting from a lot of testing of the different approaches discussed here (and others).

I think this issue could be closed and other issues open to address bugs/features related to the current new approach. At least, the issue should be renamed to something like "handle synchonization issues between results and configuration, and in between components"

benRenard commented 10 months ago

Agree to close and open new tickets as needed