Closed teixeirak closed 4 years ago
It may be a good idea but I'm not totally convinced yet, so I prefer to first walk with you over the pros and cons. In going from two to one package I think we gain a little in simplicity but it may complicate managing issues. Peple will report bugs in the code in the same place where they report bugs in equations. In practice, you will be dealing with equation issues and I'll be dealing with code issues.
Can we chat a so I learn (1) what you want to achieve?, and (2) what you worry about building a modular structure with two focused packages instead of a single one?
This doesn’t require an immediate decision to get a functioning product; its more about presentation,correct? Let’s discuss next time we meet in person.
@maurolepore, after discussing this with @gonzalezeb, we think the goal here should be: 1- Functions designed to handle allodb (allofind, units conversion, etc.) should be described in the allodb publication, with example code to run them, and be readily accessible to users who aren't using ForestGEO data or other functions in the fgeo.biomass package. 2- It's fine if these live in fgeo.biomass.
Closing issue because allodb is stand-alone package.
@maurolepore,
@gonzalezeb was suggesting that some of the functions that are currently in fgeo.biomass should be within allodb so that its core functionality works without fgeo.biomass. That is, given site, sp, and dbh, it should return a biomass value.
One specific example is that units conversion should occur within allodb (see my diagram in issue #68).