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.
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.