Closed elbeejay closed 1 year ago
Yeah it's an important conversation. I've been thinking about this too (e.g., where to put my implementation of Lauzon's VegetationModel
).
Of your options, I like number 3 and that's more or less what I've been thinking. My follow up would be whether the "pyDeltaRCM model zoo" actually hosts the model code or just links to the model code in other repositories. I'm thinking I like the idea that each implementation is hosted in separate repositories and then we just link to those repos in the zoo. That way we can link to anywhere (personal repos, bitbucket), and also not be responsible for the code...
Yeah I agree that we want to avoid being responsible for the various custom model codes. I think we could probably do both 2 and 3, by providing a link from the pyDeltaRCM documentation itself to the "model zoo" repository (which has links to source-code for each various subclass model). It's likely the main model documentation sees the most traffic, which is why I think it makes sense to have some sort of connection to navigate from there out to the various custom codes.
We should come up with a plan for organizing / centralizing all of the various subclass implementation of the core
DeltaModel
that are created. One already published set of subclass models are theSelengaModel
andMississippiFaultsModel
from @amoodie 's 2021 faulting-subsidence paper. As things stand now, someone looking at the pyDeltaRCM project and documentation would have no idea these custom subclassed codes exist. I think we should aim to collect or list all of the subclass models that end up being released/published - this should help avoid further fragmentation of the general DeltaRCM community.Some potential ideas:
I'm not sure what the best route to go down is, but I think we should develop a strategy sooner rather than later, and hopefully this will also help in the development of a user/developer community around the pyDeltaRCM model itself.