Static (fx) variables priority

[jesusff]

The I4C data request file has been copied over from the CORDEX-CMIP6 general data request. Some variables have been revised in 10eb9ab to meet the I4C request. However, the rest still needs to be completed.

To avoid the I4C-nan entries when rendering the tables as html (see here), the variables/frequencias not requested in I4C should be deleted, instead of leaving an empty priority field as was done e.g. here:

T32-CPRCM/data-request.csv

Line 5 in 6a42995

tasmax,mon,K,Daily Maximum Near-Surface Air Temperature,air_temperature,,maximum from all integrated time steps per day,area: mean time: maximum within days time: mean over days,area: areacella,longitude latitude time height2m,real,,,,,

[pia-freisen]

data-request-i4c.csv
I've updated the WP's requests here. I think an issue might be that the priority column in this table refers to the "priority in CORDEX variable list" not in I4C?

[jesusff]

Hi @pia-freisen
Fix variables (orog, sftlf, ...) still seem to be missing from the I4C data request file
https://impetus4change.github.io/T32-CPRCM/data-request-i4c-merged.html?search.search=fx

Could you look into this?

[pia-freisen]

The fix variables were not requested by any WP in I4C in the google docs table. If I add them back into the I4C csv table, it should show the same (no priority listing for I4C) in the merged table.

[jesusff]

Hi,
yes, even if not requested explicitly by any WP, these variables will be needed to interpret the results. These variables take no space, so I would say to include as many as possible. Here, the priority would be based on the availability of these variables in the different models. We can make TIER1 those that cannot be provided by some model. I'd say to have as CORE at least orog, sftlf and sfturf. We can insert these for the moment and I ping other people here (@sam-somot, @obchristensen, @ozanmert ) to have also their input regarding static variables priority

[ozanmert]

Noted. Thanks @jesusff and @pia-freisen