CLEWs UN Code Integration

[tniet]

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:

1. Adding the changes into the main OSeMOSYS branch. This has the benefit of maintaining one code version rather than multiple, but changes might not be valuable to all OSeMOSYS users.
2. Adding the changes to a separate branch of OSeMOSYS (similar to the alternate storage code branch that is available right now). This is OK but also requires the branch to be updated with changes if the main code changes.
3. Creating a separate repo and maintaining separate code bases. This isn't ideal as it means the code bifurcates and makes it more challenging to reintegrate later.

Thoughts/suggestions on which option is best and/or other suggested approaches?

[FraGard]

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?

[HauHe]

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.