`variant_label` vs `member_id`

[jbusecke]

Working with the pangeo CMIP6 data, I find myself going back and forth between the attribute variant_label and the dimension member_id, which I think are exactly the same thing.
I have been working on a flexible way to combine/aggregate datasets with different variables/ensemble members etc here, which is entirely based on the datasets attributes (and a bit more flexible).

In order to make these aggregations, specifically the ensemble member aggregation, equivalent to what intake-esm does, I however need to 'artificially' change the variant_label attribute to a member_id dimension.

So I guess my question is: Why do we concatenate along 'member_id' in intake-esm, and not 'variant_label'?

[andersy005]

When I first built the catalog for CMIP6, I used the official "data reference syntax" document. In the "filename template" section, they used member_id instead of the variant_label. Because I had seen this "member_id" vocabulary used in other contexts (CESM, etc...) I didn't pay attention to what this was referred to in the actual files. I later found out that in the global attributes of the dataset, member_id was referred to as variant_label.

So I guess my question is: Why do we concatenate along 'member_id' in intake-esm, and not 'variant_label'?

There's no other reason other than the one I described above... You should be able to concatenate along the variant_label by

1. Creating a new duplicate column in your CSV named "variant_label"
2. Updating the "member_id" entry in the aggregations section of the JSON file:

{
        "type": "join_new",
        "attribute_name": "variant_label",
        "options": { "coords": "minimal", "compat": "override" }
}

I know this is not a perfect solution, but this is the easiest approach I can think of right now...

[andersy005]

@jbusecke, how painful is making variant_label and member_id synonyms in cmip6_preprocessing code-base? I was wondering if this could constitute a long term solution instead of dealing with the catalog (which I think is fragile since anyone can name the attributes/columns however they want).