Open tniet opened 6 months ago
Hi @tniet, I agree that there may be features used for CLEWs that are potentially heavy and unneded for other uses of OSeMOSYS. Having too many parameters may also create confusion for new users? I would go with option 2, even though it will require updating the branch. We should decide however whose responsibility it is to update the branch, I think. Or should we leave it to the community?
Hi @tniet,
thanks for initiating this discussion and highlighting the existing options.
From what you write I assume that we are talking about multiple additions/modifications to the OSeMOSYS code, am I right?
I think the best way is option 1. As you say and I agree, it is a lot easier to maintain the code having one main branch. Furthermore, I think it is more confusing for users to have different versions of code than having a few more parameters. I assume that many new parameters can be defined with a default that doesn't require the user to do anything about them unless the parameter is used, like for example the DiscountRateIdv
.
But of course there might be features that require a separate branch, but I would suggest to try keeping this the exception. It could quickly get, or actually is already, messy with keeping track of which version incorporates which feature.
Finally, I think it needs to be decided on a case by case base for each feature.
I've been asked to take a look at how/where we integrate the UN CLEWs code into the GitHub Repo for OSeMOSYS. There's some features they are using that would be good to make available to the community, and vice versa, there's some changes that the UN wants to pull in.
I see a couple of possible paths for integrating these changes:
Thoughts/suggestions on which option is best and/or other suggested approaches?