table filename and "table_id" need to match

[durack1]

The table filename and the table_id in the file need to match, so e.g.,:

mip-cmor-tables/Tables/MIP_ACmon.json

Line 13 in 490b9b8

"table_id": "ACmon"

Needs to become

"table_id": "MIP_ACmon"

@wolfiex @matthew-mizielinski ping

[matthew-mizielinski]

Hi @durack1 ,

If the above change is implemented we'll end up with "MIP_" embedded in the filenames. The table_id entry in the CVs needs to be consistent with the table_id value here, so I think it is the CVs that need to change.

[durack1]

@matthew-mizielinski yes that was what I had thought would be useful, so that we follow the same notation as in the past CMIP5_Amon, CMIP6_Amon. I figure that having the MIP prefix means at least there is some additional context to APmon etc, but happy to chat about this - it is 4 repeating characters for every single entry

[matthew-mizielinski]

@durack1, Just in case I wasn't clear above, with this change the netcdf output files would be named, for example,

tas_MIP_APmon_HadGEM3-GC31-LL_hist-lu_f2023-r12i1p1f3_gn_190001-195012.nc

i.e. what would appear to be an extra facet within the output netCDF file names.

I'm not particularly keen on this as it breaks a lot of the file naming patterns we've had for CMIP6 without a huge amount of benefit. If you want to clearly credit the table names I would suggest you consider how the table_info field is used by CMOR as this will end up in global attributes.

[taylor13]

Like Matt, my take is that "MIP" contains no distinguishing information among datasets, except to limit what table names might follow it. Seems like it unnecessarily increases the apparent complexity of the filename.

[durack1]

@taylor13 @matthew-mizielinski absolutely agree now that the example is clear. In CMIP6, we had
"table_id": "Table Amon",

And CMIP5, we had
table_id: Table Amon

And CMIP3, we had
table_id: Table A1 ! table id

All had the redundant "Table " prefix, which I agree should be removed.