Include warning/ error messages when unreliable allometries are applied

[teixeirak]

Jim Lutz recommends that the R code should generate warning messages when unreliable allometries are applied.

There are several issues that need to be decided:

1. What are the criteria that should generate a warning / error message? Here's the start of a list:

   • [ ] attempt to apply allometric equation outside of the DBH range for which it was developed
   • [ ] attempt to apply a generic equation to a species for which its a terrible fit (see item 2)
   • [ ] application of an allometry that is of poor quality (e.g., low number of individuals sampled) but still the best available. For this, we need to decide criteria.

2. Should the code allow bad allometries to be applied? A couple examples:

   • if the user selects the generic equation option, which is very bad for bristlecone pine, should there be a warning message : “you can use this general equation, but its going to be really bad for bristlecone pine”, or should the expert-selected allometry automatically be applied?
   • if an allometry is assigned outside the DBH range for which it was developed, should this generate a warning (i.e., message, code still runs) or an error (i.e., code won't run unless fixed)?

3. How is this implemented in the database and code?

   • I think that one way to implement this in the database is to add a warning_notes field to both allodb_equations.csv (warnings about the allometric equation itself) and allodb_site_species.csv (warnings about application of an allometric equation to a certain tree). These can be used to manually add warnings that should be displayed when the allometry is applied.

[maurolepore]

RE your item 3 above:

I think your idea is a good one. Your database can have a column with an optional message for each row (equation), and a column with the condition that throws the error, e.g.

any( DBH < min_DBH, DBH > max_DBH )

The contents of the column condition should be valid R code; if it evaluetes to TRUE, then the message is produced. If the issues may vary in severity, we may need an additional column giving the condition_type such as inform, warn, or abort -- that is, an instruction to tell R what to do appart from producing a message.

[teixeirak]

Conclusion regarding statement above based on discussion: As we're controlling the package, there shouldn't be any instances that would warrant "abort". All messages entered in @gonzalezeb's tables should be interpreted as warnings. @maurolepore's code will throw some general warnings.

[teixeirak]

Regarding [2] in the top comment, this sort of error will not be possible within the master version. However, users could edit the tables offline and run the code. For this reason, it may make sense for the code to include an abort function to deal with unacceptable practices (e.g., if user attempts to apply an allometry way outside its range).

[gonzalezeb]

@cpiponiot Let's try to discuss some aspects of this issue today 5/12.