coupling prom and magpie implemented

[SongminYu]

introduced in the open-prom PR

[alextsimp]

All these variables it is better to have it in csv file that we can easily alter instead of being hardcoded.

[SongminYu]

agree, shall I create a csv file including the variable names in postprom/inst/extdata? Is that the place to save such info?

[alextsimp]

Please use camelCase in all R scripts. It is the coding standard.

[mmadianos]

Looks good. I have a few suggestions:

1. In build_climatewatch_eu28_weights.R, the output path is hard‑coded. Since this CSV is currently limited in scope, would it make sense to embed it directly in the script? Alternatively, if we expect this to be extended in the future, perhaps it should be incorporated into mrprom instead of living in postprom.
2. I noticed several repeated blocks like if (file.exists(iEmissions_magpie)). This looks like a good candidate for refactoring. One option could be to perform this check once upfront and use it to prepare the afolu object (depending on whether the file exists or not). If the downstream logic operates the same way regardless of the source of afolu, the subsequent file.exists() checks may no longer be necessary. This would reduce duplication and simplify the control flow.

[SongminYu]

Thanks @mmadianos ! I have improved the script following your first comment. Now the weights are hard-coded in the script since it is not long. It is better in this way, expecially for external users, that the script doesn't depend on the access of Climate Watch data. I also kept the script to generate these values, in case we want to change the methodology and refresh it. Furthermore, I also improved the disaggregation methodology by taking into account the cluster heterogeneity in MAgPIE, but you don't need to review this. I have tested.

Once @alextsimp and you have an agreement on the second comment, you can close the PR and I will merge it. Thanks a lot!

[alextsimp]

I made it a bit more cleaner so I think now we can merge it. @SongminYu @mmadianos