Ocean Biogeochemistry Tracers

[martinjuckes]

@durack1 , @taylor13 , @japamment: in CMIP5 we had a set of 3d tracers requested as annual means in Oyr, and the same parameters were requested in Omon as monhly means for the upper ocean layer only. These variables used the same variable name and CF standard name, but had a height coordinate of "heigth0m" instead of the ocean model vertical coordinate.

In CMIP6 the situation looks a little confused: we have, for example, co3 in Oyr defined as in CMIP5 as a 3d variable (though it has a proposed new standard name which has not yet been accepted: mole_concentration_of_carbonate_ion_in_sea_water instead of mole_concentration_of_carbonate_expressed_as_carbon_in_sea_water). The Omon table contains an instruction that, as in CMIP5, such 3d tracers should be included as near surface fields in the Omon table. This is implemented in the data request, so that a co3 variable appears in the Omon table with the "height0m" dimension as for CMIP5. The confusion I'm worried about is the co3 is also defined as a 3d tracer in Omon (with the same priority, 2, as the near surface version) .. creating a variable name conflict. There is also a co3os near surface variable explicitly defined in Omon with an additional proposed standard name (surface_mole_concentration_of_carbonate_ion_in_sea_water).

(1) Where the definition of a variable is the same as CMIP5, we should use the same standard name ... and if the definition is changed we should ideally have a new variable name: for co3 has there been a change of the variable definition to justify the request for a new standard name?

(2) Do we really want to request tracers as 3d annual and 3d monthly fields? The 3d monthly fields will lead to a huge data volume.

(3) If we do need the 3d monthly fields, we should provide some advice: e.g. "Please provide either the 3d monthly fields or a combination of 3d annual fields and monthly near surface fields".

(4) The "surface...." proposed standard names are unnecessary and appear to be inconsistent with the CF approach (the units other attributes imply that these are near surface fields, as for CMIP5, not fields evaluated at the interface, which would be implied by a standard name of surface....). Can we revert to the standard names used in CMIP5?

[taylor13]

@durack1, @japamment, @martinjuckes I agree with (1) and (4)

I would suggest to OMIP (or whoever specified the variables) that they should think again about whether they really need 3d monthly fields or if annual is good enough. If 3d monthly are required, then don't ask for near-surface (but maybe for some expts. near-surface is sufficient?) Not sure it's a good idea to give two choices, as you suggest in (3).

[johndunne13]

I was certainly assuming (3), but I agree that sending all tracers 3 D monthly is overkill. the ones people were particularly interested in last time were:

O2, HTOTAL, CO3_ION, CO3_SAT_ARAG, NO3, and CHL.

So I would consider these highest priority. Maybe we make these Priority 2 and the rest priority 3 or remove to annual?

[durack1]

Ok folks, I'll make the change @johndunne13 suggested above, and just to be clear this is just biogeochemistry variables (see https://goo.gl/Fyr6QW).

@johndunne13 I wonder if any of the chemistry variables also need a priority revisit (see https://goo.gl/BrXVgb) there are considerably less variables included there

[johndunne13]

Thanks for pointing that out. If we are bothering to save SF6 and CFCs as monthly 3D variables, then we should definitely add DIC to the previous list of O2, HTOTAL, CO3_ION, CO3_SAT_ARAG, NO3, and CHL as priority 3D monthly variables.

[johndunne13]

I forgot dissolved iron (FED) - that is another monthly 3D variable in which there has been considerable interest.

[durack1]

@johndunne13 so this can be implemented, can you please list the changes (using the output variable name and sheet and cell e.g. Omon F6) that you want made? I tried to find O2, HTOTAL etc in the Omon sheet and didn't get very far

[martinjuckes]

@johndunne13 Are the following mappings correct (with the MIP name in brackets): DIC = Dissolved Inorganic Carbon Concentration (dissoc) O2 = Dissolved Oxygen Concentration (o2) HTOTAL = pH -negative log10 of hydrogen ion concentration with the concentration expressed as mol H kg-1. (ph) CO3_ION = Carbonate ion Concentration (co3) CO3_SAT_ARAG =Mole Concentration of Dimethyl Sulphide in sea water -- mole_concentration_of_carbonate_expressed_as_carbon_at_equilibrium_with_pure_aragonite_in_sea_water (co3satarag) NO3 = Dissolved Nitrate Concentration (no3) CHL = Mass Concentration of Total Phytoplankton expressed as Chlorophyll in sea water (chl)

[durack1]

@martinjuckes, there are multiple instances of the chl variable (Omon, F92), so e.g. chlos (Omon, F39), chldiatos (Omon, F40), chldiatzos (Omon, F41), etc also Oday and Oyr needs to be considered. The same is true for other variables (e.g. co3, co3os etc)

I'm working with @johndunne13 to get these sorted and will update you once these are done - I also need to double check some of the rejected standard_name requests with @japamment, as the mappings were not clear to me

[johndunne13]

All are correct except the one for DIC which should be "dissic". "dissoc" is "Dissolved Organic Carbon"

On Wed, May 17, 2017 at 8:01 AM, Martin notifications@github.com wrote:

@johndunne13 https://github.com/johndunne13 Are the following mappings correct (with the MIP name in brackets): DIC = Dissolved Inorganic Carbon Concentration (dissoc) O2 = Dissolved Oxygen Concentration (o2) HTOTAL = pH -negative log10 of hydrogen ion concentration with the concentration expressed as mol H kg-1. (ph) CO3_ION = Carbonate ion Concentration (co3) CO3_SAT_ARAG =Mole Concentration of Dimethyl Sulphide in sea water -- mole_concentration_of_carbonate_expressed_ascarbon at_equilibrium_with_pure_aragonite_in_sea_water (co3satarag) NO3 = Dissolved Nitrate Concentration (no3) CHL = Mass Concentration of Total Phytoplankton expressed as Chlorophyll in sea water (chl)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/150#issuecomment-302068917, or mute the thread https://github.com/notifications/unsubscribe-auth/AaiQMgmnNc5WIUojWT458FIBAQcFeg3oks5r6uGigaJpZM4M1UfU .

[durack1]

@martinjuckes there seems to be two issues here if I am following your https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/150#issue-219833470 above. Following 1-3 questions above (I believe 4 has been resolved by using the same standard_name as the 3D quantity but including an *os in the output variable name.) it seems we have to resolve following your points: 1) inconsistencies between CMIP5 and CMIP6 variable names and definitions, and naming conflicts. As noted in the "File name template" and "Directory structure template" in the DRS document (https://goo.gl/v1drZl) the table_id is part of the filename and the DRS/directory for output files, so Oyr and Omon should lead to filename differences. Inconsistencies between CMIP5 and CMIP6 is a grey area to me - do you have any specific examples from the current versions of the sheets? 2) a consideration of tracer field priorities. As noted in https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/171#issuecomment-302260639, we have dropped the priority of the Omon 3D request for chemistry variables (https://goo.gl/BrXVgb) sf6, cfc11 and cfc12, and increased the priority of the Oyr request for the same variables. I believe you are suggesting a similar strategy for the biogeochemistry variables (https://goo.gl/Fyr6QW). Resolving this query would then answer your question 3 above too

Can you please explain how you are using the "priority" entry in the sheets?

[martinjuckes]

1. In CMIP5 two dimension monthls versions of 3d annual tracers used the same variable name and the same standard name as the annual tracers (e.g. dissic: mole_concentration_of_dissolved_inorganic_carbon_in_sea_water ), you are proposing, in https://goo.gl/Fyr6QW that the two dimensional monthly versions have a different name. This is not consistent with CMIP5.

The first line of data in the Omon sheet of https://goo.gl/Fyr6QW implies that two dimensional tracer variables are requested with the same names as the 3d variable in Oyr. In subsequent rows you request the same variables again with different names. THIS IS NOT ACCEPTABLE .. PLEASE EITHER REMOVE ROW 6 or REMOVE THE ROWS WHICH DUPLICATE THE REQUEST IN ROW 6 (fi you don't understand this please talk to @taylor13 about the interpretation of row 6).

2. You also need to explain how you want people to deal with the duplications in the request, e.g. you are asking for dissic as a 3-d annual variable, a 3-d monthly variable and a 2-d monthly variable. Archiving all 3 is clearly unnecessary. If you are requesting mutually redundant variables, you need to explain why.

For the priority, see https://earthsystemcog.org/site_media/projects/wip/CMIP6DataRequestCompilationGuidanceNote_150116.pdf : the priority can be used by modelling centres to filter variables. Those wanting to make a minimal contribution (which is still large) can start be looking at only priority one variables.

[martinjuckes]

PS: I should add that you need to be careful about assigning priority 1 to variables, as it all adds to the workload of the participating modelling centres. Since "modelling centres must commit to supplying all priority 1 variables associated with at least one science question for Tier 1 experiments of any MIP which they participate in", priority 1 should only be assigned when the variables are required for the primary science objectives of a MIP.

[johndunne13]

Hi Martin,

Requesting both 2D and 3D monthly variables was my idea - the objective being to ease the downloading burden of users at the initial phases of analysis. If this approach is inconsistent with CMIP6 standards, then I would suggest eliminating the redundant 2D monthly and 3D annual variables. As for priorities, that is a Jim Orr should make. I am not sure if he is on this list/thread, so I have cc'd him.

Cheers, John

On Wed, May 31, 2017 at 12:29 PM, Martin notifications@github.com wrote:

1. In CMIP5 two dimension monthls versions of 3d annual tracers used the same variable name and the same standard name as the annual tracers (e.g. dissic: mole_concentration_of_dissolved_inorganic_carbon_in_sea_water ), you are proposing, in https://goo.gl/Fyr6QW that the two dimensional monthly versions have a different name. This is not consistent with CMIP5.

The first line of data in the Omon sheet of https://goo.gl/Fyr6QW implies that two dimensional tracer variables are requested with the same names as the 3d variable in Oyr. In subsequent rows you request the same variables again with different names. THIS IS NOT ACCEPTABLE .. PLEASE EITHER REMOVE ROW 6 or REMOVE THE ROWS WHICH DUPLICATE THE REQUEST IN ROW 6 (fi you don't understand this please talk to @taylor13 https://github.com/taylor13 about the interpretation of row 6).

1. You also need to explain how you want people to deal with the duplications in the request, e.g. you are asking for dissic as a 3-d annual variable, a 3-d monthly variable and a 2-d monthly variable. Archiving all 3 is clearly unnecessary. If you are requesting mutually redundant variables, you need to explain why.

For the priority, see https://earthsystemcog.org/site_media/projects/wip/ CMIP6DataRequestCompilationGuidanceNote_150116.pdf : the priority can be used by modelling centres to filter variables. Those wanting to make a minimal contribution (which is still large) can start be looking at only priority one variables.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/150#issuecomment-305242414, or mute the thread https://github.com/notifications/unsubscribe-auth/AaiQMqidHqg6g9XQwdFeuRnfA5wTOVcqks5r_ZWDgaJpZM4M1UfU .

[martinjuckes]

There is one duplication that needs to be removed because it is clearly pointless: 2d monthly variables are being requested twice with two different names. It will make the conversation a lot clearer if this could be dealt with.

[johndunne13]

Which variable is that? I looked in https://goo.gl/Fyr6QW but couldn't find any duplicate 2D variables.

On Thu, Jun 8, 2017 at 9:06 AM, Martin notifications@github.com wrote:

There is one duplication that needs to be removed because it is clearly pointless: 2d monthly variables are being requested twice with two different names. It will make the conversation a lot clearer if this could be dealt with.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/150#issuecomment-307097342, or mute the thread https://github.com/notifications/unsubscribe-auth/AaiQMm0ZKRbBNm-EWv4x_OqOvmTJyr61ks5sB_HzgaJpZM4M1UfU .

[martinjuckes]

Row 6 states that all 3d fields on Oyr should be included as 2d fields with priority 2 .. then in subsequent rows some or all of them are requested again.

[johndunne13]

Thanks, now I understand... Paul, I had thought you had suggesting deleting that row after our last conversation... am I correct that it should now be removed?

On Thu, Jun 8, 2017 at 11:18 AM, Martin notifications@github.com wrote:

Row 6 states that all 3d fields on Oyr should be included as 2d fields with priority 2 .. then in subsequent rows some or all of them are requested again.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/150#issuecomment-307135842, or mute the thread https://github.com/notifications/unsubscribe-auth/AaiQMg-Akle9KGZeM4Sl3sDz2LzTRfzZks5sCBCqgaJpZM4M1UfU .

[durack1]

@martinjuckes apologies, I am having a hard time getting inside your head to determine the issue. After @johndunne13's prompting I now see the issue, which is the verbose descriptor row 6 in the "Omon" sheet. I have just purged this entry, and noted the change on the "general" sheet.

As I am now starting to purge information to clean up these sheets, can you give me an all clear to delete the redundant "working" columns (they generally include "AP" in the column title as Alison was working on the sheet - so for e.g. in Omon biogeochemistry columns H through P) that were generated in the biogeochemistry (https://goo.gl/Fyr6QW) and chemistry (https://goo.gl/BrXVgb) sheets during the CF standard name discussions?

We are still awaiting many of the physics names to be approved, so will do the physics (https://goo.gl/Rhrcwp) sheet cleanup after the standard name updates are completed

[martinjuckes]

@durack1 Please do not delete any columns ... I don't want to deal with more format changes.

Looking back over this conversation, I really do not understand why we are wasting time with superficial changes at this stage. People have started model runs .... we need to finalise what variables are needed. What is the justification for changing the variable names of the 2d monthly ocean tracers relative to CMIP5 (e.g. dissic --> dissicos)?

You still have multiple versions of the same parameter requested, e.g. talk as a annual 3d field, a monthly 3d field and (as talkos) as a monthly 2d field, all priority one. In CMIP5 such fields were requested as annual 3d fields and as 2d monthly fields with priority 2. What is the reasoning behind the dramatically increased volume of data being requested? (Please also respond to Karl's comment from April 12th above [@taylor13] )

[durack1]

@martinjuckes apologies for responding slowly to this. My intention of deleting deprecated information was to ensure that you are not keying off wrong information. As noted above there are duplicate entries for standard_name in many of the sheets, with only one column being updated to align with the latest CF standard name entries.

Regarding the dissic -> dissicos this conversation was undertaken on the CF mailing list.

Regarding duplicate frequency requests for variables (so for e.g. a variable requested in both the Omon and the Oyr sheet), as I am not a biological oceanographer I am not certain of what fields are required for a seasonal cycle resolution (i.e. Omon requested data), and what can be analysed for the long-term changes, ignoring the seasonal cycle (i.e. Oyr requested data). I have spoken with @taylor13 about this and we'll need to interact with @johndunne13 and @jamesorr about finalizing these

[martinjuckes]

@durack1 I'm sorry, but I can't see any mention of the justification for changing the variable name from dissic to dissicos in the CF mailing list discussion you refer to.

[durack1]

@martinjuckes you may need to follow that thread a little, Alison et al was happy with the change and we received no disagreements - see here

If you would like to revert this change, then please feel free to reopen the discussion on the CF-list, or alternatively reconfigure the entries in the google sheets

[martinjuckes]

@durack1 I'm talking about the variable name "dissicos": Alison's role is to review the standard names. The standard name discussion appears to have rejected the proposal to change the standard name of the surface variables: the near surface mole concentration of inorganic carbon in sea water will be archived in CMIP6 using the same standard name as used in CMIP5. The question is, why do we need to change the variable name? Who proposed the change and what is the reasoning behind it?

[johndunne13]

I was the one who originally proposed adding the names - not for any passionate need but only to have the BGC variables consistently extend the physical variable naming convention as to the distinction between to/so as 3D variables and tos/sos as uppermost layer (2D) values. Like you say, several on the list did not like that idea, and I appreciate their concerns. My memory is that Karl Taylor proposed an alternative that appeared more palatable to the group and I thought that was going to be the approach moving forward, but I was never clear on the details on how Karl's recommendation would be implemented.

On Fri, Jun 30, 2017 at 4:52 AM, Martin notifications@github.com wrote:

@durack1 https://github.com/durack1 I'm talking about the variable name "dissicos": Alison's role is to review the standard names. The standard name discussion appears to have rejected the proposal to change the standard name of the surface variables: the near surface mole concentration of inorganic carbon in sea water will be archived in CMIP6 using the same standard name as used in CMIP5. The question is, why do we need to change the variable name? Who proposed the change and what is the reasoning behind it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/150#issuecomment-312213383, or mute the thread https://github.com/notifications/unsubscribe-auth/AaiQMgPHwsyHWWwJ9ZeX3204u0CtgX9Kks5sJLc5gaJpZM4M1UfU .

[martinjuckes]

@johndunne13 : Hello John, I appreciate the intention of creating more consistency, but I think the use of "s" for surface is an occasional feature rather than a convention. The CMIP5 usage does not appear to have caused any problems, so I would hope that Karl's alternative was to stick with what was done in CMIP5: consistency with CMIP5 brings some advantages for people comparing output between MIPs. There is also a strong case for sticking with the names listed in the GMD paper ... I don't think dissicos is mentioned there. We should try to keep changes from the GMD paper to a miniumum.

Can you comment on the question Karl posed on April 12th, near the top of this discussion, about whether 3d monthly fields are really needed? [and, I would like to add, whether they need are needed at priority one -- which implies a model cannot be properly assessed without them]

[johndunne13]

Hi Martin,

I am not comfortable making priority changes with Jim Orr's (ccd) involvement. As the ocean bgc lead, he would be the best person to comment on the value of the different variables and priorities, but I thought that Paul and I did an interaction on the monthly 3D request to limit it to six or so variables with the assumption that if something like CFC was a monthly priority 1 variable, that these 6 or so bgc variables would be as well. If Jim can't help, perhaps you should have a brief telecon with the ocean bgc steering committee to come to a final decision on these issues? I don't feel like I have all the information myself to give you a helpful and authoritative answer on behalf of the other laboratories and intended users.

John

On Jun 30, 2017, at 2:55 PM, Martin notifications@github.com wrote:

@johndunne13 : Hello John, I appreciate the intention of creating more consistency, but I think the use of "s" for surface is an occasional feature rather than a convention. The CMIP5 usage does not appear to have caused any problems, so I would hope that Karl's alternative was to stick with what was done in CMIP5: consistency with CMIP5 brings some advantages for people comparing output between MIPs. There is also a strong case for sticking with the names listed in the GMD paper ... I don't think dissicos is mentioned there. We should try to keep changes from the GMD paper to a miniumum.

Can you comment on the question Karl posed on April 12th, near the top of this discussion, about whether 3d monthly fields are really needed? [and, I would like to add, whether they need are needed at priority one -- which implies a model cannot be properly assessed without them]

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[durack1]

@johndunne13 @martinjuckes @jamesorr @taylor13.

For CMIP5 the 3D variable dissic (and many of the other tracer fields) was requested only in the annual Oyr table, see here. In the case of the monthly requested variables, these were only 2D see here

For CMIP6, the biogeochemistry (https://goo.gl/Fyr6QW) Omon and Oyr sheets indicate in the top rows "All diagnostics on ocean grid. Archive Omon fields even if also saving Oyr versions". The request duplicates requested data, which is the first issue that @martinjuckes has raised.

@johndunne13 and @jamesorr to resolve this issue, would it be suitable to request the 3D variables e.g. dissic et al. only for the annual frequency Oyr, and the 2D variables e.g dissicos only for the monthly frequency Omon - this will replicate what was done in CMIP5 (see above).

If the above is agreed to, then the second issue (surface names; adding os to existing names - so dissic vs dissicos) goes away, as these variables will be requested in separate tables, and consequently there will be no clashes with duplicate filenames (so no 2D AND 3D variable co-existing in Omon for e.g. which would lead to overwrites if a user is using CMOR). If this is not agreed to, we need to continue to keep unique CMOR names for each unique variable in a table e.g. Omon

[taylor13]

@johndunne13 @jamesorr @martinjuckes @durack1 I have again reviewed the issues raised here and examined the biogeochemical ocean variable request. We can no longer wait much longer to iron out the details, so we will proceed as follows unless we hear objections before July 20 from the BGC steering committee (or its authorized representative):

1) We will focus here on priority 1 variables (and leave the lower priority variables unmodified in https://goo.gl/Fyr6QW). For monthly mean variables, please check whether the following changes in priority between the GMD article and the data request are justified:

a)  Variables that were priority 2 in GMD but are priority 1 in https://goo.gl/Fyr6QW: no3os, talknat, o2, o2sat, no3, nh4, dfe, chl.  (All but the first of these are 3-d and if needed at priority 1, this will substantial increase the "mandatory" data volume.)
b)  Also, po4, was priority 1 in GMD but is priority 2 in https://goo.gl/Fyr6QW

2) If a monthly-mean variable is requested, then its annual mean will not also be requested. 3) If a 3-D field is requested, then the corresponding surface field will not also be requested. 4) The GMD paper seems to indicate that results will be analyzed for the 2 OMIP1 simulations. Are there other experiments where these fields are likely to be essential (e.g., the 2 OMIP2 simulations? piControl?, historical? other DECK runs? CH4MIP expts? Paleo simulations? scenarioMIP simulations?) For each experiment (in the request), state how many years (and which years) should be reported for each group of variables. Don’t ask for more data than will likely be analyzed.

Again, time is of the essence, so unless we hear otherwise we will proceed with the current list of variables (subject to the revisions implied by 2 and 3 above). We will also restrict our request of these variables to only the OMIP1 runs, piControl, historical, and C4MIP simulations, unless otherwise instructed.

thanks, Karl

[jamesorr]

@taylor13 @durack1 @johndunne13 @martinjuckes

1. No, the changes between the final OMIP-BGC paper in GMD and the latest version of the data request at https://goo.gl/Fyr6QW are not justified. Coauthors of that paper agreed to limit the request of the priority 1 monthly 3-D data to the bare minimum. Thus the GMD paper requests at priority 1 only four 3-D variables: dissic, talk, ph, po4.

This is a big reduction relative to the current data request spreadsheet. That is, the seven 3-D monthly variables in Karl's point 1(a) are not requested as priority 1. But the po4 variable in point 1(b) is requested as priority 1. Since I did not have permission to edit the spreadsheet of the data request online, here is a modified version with the above mentioned changes (highlighted in pink): CMIP6_OMIP_biogeochemistry_standard_output_orr_20170722.xlsx

2. Dropping the annual mean request if the monthly output of that variable is requested at the same priority seems a good idea, but it puts the burden on the data users only interested in the annual data.

3. The plan to suppress the surface field request when there is a request for the 3-D data of the same variable seems inconsistent with what was done for ocean temperature and salinity in CMIP5 (tos, sos).

4. The 3-D monthly output will be analysed during OMIP1, OMIP2, and subsequent phases of the same project. It will also be analyzed in CMIP6 in the historical, scenarioMIP, and C4MIP simulations. It is not needed for other CMIP6 experiments. But in those other simulations, we still need to request the equivalent monthly surface fields.

Thanks,

Jim

[martinjuckes]

Hello Jim,

Thanks for going through those.

On your point 3: sos is defined as a the salinity at the surface (i.e. at the boundary with the atmosphere). In CMIP5 the ocean bio-geochemical tracers (dissic etc) where requested as near-surface variables, meaning the value in the upper model layer. It may be that the distinction was not very meaningful in the context of the CMIP5 models, but, if the model has any concept of vertical structure in salinity within the top model layer there is no redundancy between sos and so. For the tracers, do you want to follow the approach of CMIP5 and ask for the upper layer, or should groups try to estimate surface values.

On point (1) I'd just like to point out that Paul's google sheets are not the data request .. they are what I have been provided with as input to the data request.

[martinjuckes]

Hello Jim,

A further question: there are 3 3d annual fields which are completely omitted from the monthly request, pnitrate, pbsi and pbfe. Is this intentional?

[jamesorr]

@martinjuckes

Actually, in CMIP5 the dissic variable was requested as 3-D annual-means as well as 2-D monthly means, so it was not only a top-layer variable.

Regarding so and sos, those two variables are the identical in CMIP5 models in the top layer. i know of no ocean models that do not assume that the top layer is uniform in salinity.

Thanks for clarifying my mistake in point 1 about the data request.

[jamesorr]

@johndunne13 John, could you confirm that we do not want monthly output for the pnitrate, pbsi, and pbfe variables?

[johndunne13]

I think we would want monthly surface fields of these variables in the request.

On Aug 2, 2017, at 9:14 AM, James Orr notifications@github.com wrote:

@johndunne13 John, could you confirm that we do not want monthly output for the pnitrate, pbsi, and pbfe variables?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[martinjuckes]

@johndunne13 I'll put them in for now.

@jamesorr : thanks, I realise dissic was requested as a 3d annual field. I was making the point that it was requested in Omon as a upper layer field, not as a surface field. I appreciate that this may not make any difference to data values, but, in the context of the data request, asking for something at the surface is not the same as asking for it in the upper layer. In CMIP5 these variables had dimensions longitude latitude time depth0m: I suggest we stick to this for CMIP6, to avoid giving the impression that there is any change in the intended approach.

For temperature and salinity, on the other hand, the tos and sos variables were and are described explicitly as surface values. We had a discussion back in 2015 which concluded that some CMIP6 models may be able to resolve the difference between surface temperature and upper layer temperature, so the distinction is important there.

@taylor13 : note that at the moment all these variables get included in the DECK request for data from piControl, abrupt4xCO2, 1pctCO2, and historical , since you specified that the entire Omon table should be included. The Omon data as a block is also requested by HighResMIP, LS3MIP, C4MIP, GeoMIP, GMMIP, AerChemMIP. Other several other MIPs are requesting subsets of the OMIP request from their experiments. Around 140 Omon variables have been requested from ScenarioMIP experiments by a range of MIPs.

In John's latest sheet there are 51 variables which are requested as 3-d field in Omon and Oyr and also as upper layer fields in Omon (possibly with a modified name). 26 of these have the same priority across all 3 versions, while the others have a lower priority for the monthly 3-d field (e.g. phabio and phnat have priority 2 from Omon 3d, priority 1 for Oyr 3d and priority 2 for Omon 2d). So, if I filter out the redundant variables (except that we will continue to allow salinity and temperature to be exceptions) where they are requested with the same priority we will still have some duplications, where groups may choose to submit only the higher priority and lower volume variant.

I hope to get an update out tomorrow, and will try to implement the approach described in the last paragraph. It may be worth contacting HighResMIP, LS3MIP, C4MIP, GeoMIP, GMMIP, AerChemMIP to see whether they really need the whole range of variables in Omon.

[durack1]

@jamesorr I had an unresolved query a number of months ago that should be revisited here. A number of the fluxes are requested with different units:

surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon, fgco2, kg m-2 s-1 (Omon, 161)
surface_downward_mass_flux_of_carbon_dioxide_natural_analogue_expressed_as_carbon, kg m-2 s-1 (Omon, 162)
surface_downward_mass_flux_of_carbon_dioxide_abiotic_analogue_expressed_as_carbon, kg m-2 s-1 (Omon, 163)
surface_downward_mass_flux_of_carbon14_dioxide_abiotic_analogue_expressed_as_carbon, kg m-2 s-1 (Omon, 164)
surface_downward_mass_flux_of_carbon13_dioxide_abiotic_analogue_expressed_as_carbon13, kg m-2 s-1 (Omon, 165)
surface_downward_mole_flux_of_molecular_oxygen, mol m-2 s-1 (Omon, 166)
surface_upward_mole_flux_of_dimethyl_sulfide, mol m-2 s-1 (Omon, 167)

I'm not sure this is an issue, but it would be a good idea for you to review the "final" version of the request that @martinjuckes has been ingesting.

@martinjuckes on this matter, if you have started altering the data request away from what is provided in the google sheets, is there a need to me to continue to update these? For the biogeochemistry (https://goo.gl/Fyr6QW) and the chemistry (https://goo.gl/BrXVgb) I had finalised the standard_name updates, but there were some remaining for the physics sheet (https://goo.gl/Rhrcwp) that should be undertaken. I'm happy for you to take over this role.

[martinjuckes]

@durack1 : for the ocean biogeochemistry I'm now using the spreadsheet which Jim provided 12 days ago, with the corrected priorities. I had to make some adjustments to the standard names (there was a correct standard name in each row .. just not always in the same row), but it is now incorporated into version 01.00.15 of the request.

With the range 3d variables as specified in Jim's table, the OMIP request is estimated at 17Tb for priority 1 variables (this is for a nominal model which may not correspond to what people end up using, but should give some idea of the relative sizes of different parts of the request). This makes it one of the larger MIPs, but not the largest (that prize goes to HighResMIP). But OMIP variables make up a large fraction of the data requested by some of the other MIPs.

[martinjuckes]

Variables now updated with priorities as defined in #171