Single constituent common region can lead to unexpected results about nomenclature HOT 4 CLOSED

If I understand this correctly, this is not actually a bug but rather potentially unintuitive behavior. It is true that the highly generic example above is confusing, i.e.,

model: model_a
native_regions:
  - region_a: Region_A
common_regions:
  - Region_B:
    - region_b 

but in an actual project setting, this would like as follows:

model: model_a
native_regions:
  - EUR: model_a|EUR
common_regions:
  - Europe:
    - EUR

In my opinion, this is not a major reason for concern, but rather highlights that we need to improve our documentation, not change the logic of the processing.

from nomenclature.

I partially agree, for sure the documentation needs to be better, I'll make sure I get on that right away.

There are, however, in my opinion two issues that go beyond that:

1. Potential for data loss: If the common_region in question is renamed as is your example - Europe: EUR, the resulting data will be obtained through region processing alone. Not only is this unnecessary work, making the processing slower, as you could just use the provided data, it can also lead to data loss in case the aggregation fails.
   We had this issue in ngfs-internal recently where a variable Price|Carbon that had a weighted aggregation (using Emissions|Kyoto Gases) had a negative weight after the year 2060. As is the pyam default, the negative values were dropped. This lead to missing values in Price|Carbon even though the complete Price|Carbon timeseries was provided model natively.
   This could be mitigated¹, by skipping region aggregation and simply taking the provided model native results in case a common_region just consists of a single region.
2. Inconsistency with the renaming: I frequently find myself going over the question "What is region x now going to be uploaded as?". For native_regions it is the 'upload name' is the second value (taking your previous example: - EUR: model_a|EUR), while for common_regions it is the first one (- Europe: EUR). Maybe it's just me but I find that a bit inconsistent and as a result confusing.

from nomenclature.

As a suggestion for 1, we could split out common-region mappings that only have one component and treat them via renaming.

For 2, I still believe that a clear separation into common regions (used for comparison in a project) vs. native region is the more intuitive approach for modelers. The alternative (assuming you would want to save the native region and the compare-region) would be to have

model: model_a
native_regions:
  - EUR: model_a|EUR
  - EUR: Europe

which will be just as confusing for larger models...

from nomenclature.

Both proposed points sound good to me, let's do it that way.

from nomenclature.