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_depthandthe_depthswhere we should fail if max(the_depths) >lake_depthbsn_valsand its relationship toHandA. (Others arecsv_point_nvars,num_depths,num_inflows,inflow_varnum,num_outlet,n_zonesand probably additional...). If using a default, perhaps these shouldwarninstead 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.