We should not distinguish model code from model parameterization/configuration

[platipodium]

@alee wrote in #137

The configuration files, output analysis scripts, code, and other objects in the computational model archive are pertinent to reuse, not accessibility. You don't need them or know anything about them unless you are intending to reuse the model in some way.

Often, it is not easy to distinguish this. As an example: we have a source code that does generic calculations based on configuration files that determine the functionality. So the configuration file determines the scientific model.

It may not be useful to make distinction between model and its parameterization/configuration

[alee]

I think there is some confusion - I wasn't saying we don't need to keep configuration along the archived / deposited computational model - just that it is a reusability concern, not an accessibility one 😅

That said, I think parameterizations or configuration sets for a model can potentially be included with the model or kept separately. If a base configuration or parameterization is needed to even run the model, it should be included. If there are 100 different treatments, perhaps it's better to keep those as a living dataset that lives elsewhere (on figshare, OSF, etc.) and has a permanent identifier or link included in the model description / metadata.

Regardless I think we can close this as I think this will depend on the model being deposited and this sort of thing can be hashed out during model certification or peer review.