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
It seems failing early on setting params incorrectly would be helpful for users, especially with GLM errors aren't the easiest to track down. Starting with really simple ones first to create a pattern for implementing these rules would be ideal, making it easier for others to propose and implement more complex ones in the future.
For the time being, I am thinking about a couple of things:
Conflicts between lake_depth and the_depths where we should fail if max(the_depths) > lake_depth
variables that specify the length of a vector, but that vector is a different length (in this case, GLM will ignore the values after the specified length), such as bsn_vals and its relationship to H and A. (Others are csv_point_nvars, num_depths, num_inflows, inflow_varnum, num_outlet, n_zones and probably additional...). If using a default, perhaps these should warn instead of error?
Seems like a good starting point. Would be nice to be able to avoid errors or warnings if you want, so that should be coded in the validation checker.
The text was updated successfully, but these errors were encountered:
jordansread
changed the title
Create error, warning, or ignore system for params that conflict
Create error, warning, or ignore system for nml params that conflict
Jan 4, 2020
jordansread
pushed a commit
to jordansread/glmtools
that referenced
this issue
Jan 8, 2020
It seems failing early on setting params incorrectly would be helpful for users, especially with GLM errors aren't the easiest to track down. Starting with really simple ones first to create a pattern for implementing these rules would be ideal, making it easier for others to propose and implement more complex ones in the future.
For the time being, I am thinking about a couple of things:
lake_depth
andthe_depths
where we should fail if max(the_depths
) >lake_depth
bsn_vals
and its relationship toH
andA
. (Others arecsv_point_nvars
,num_depths
,num_inflows
,inflow_varnum
,num_outlet
,n_zones
and probably additional...). If using a default, perhaps these shouldwarn
instead oferror
?Seems like a good starting point. Would be nice to be able to avoid errors or warnings if you want, so that should be coded in the validation checker.
The text was updated successfully, but these errors were encountered: