Standard names: *averaging kernels for mole fraction profiles of atmospheric trace gases*

[MSchneiderMetamorphoses]

Proposer's name: Matthias Schneider (KIT, IMK-ASF) Date: 22/12/2022

I would like to make two proposals (I and II)

I: - Description, averaging kernel: The averaging kernel is a decisive component of a remote-sensing retrieval because it reveals how changes of the real atmospheric state affect the retrieved atmospheric state (Rodgers, 2000). The kernel is indispensable for data interpretation and data reuse. It is an {n x n} matrix where n is the number of atmospheric levels (the dimension of the atmospheric trace gas state vector). The elements of the kernel matrix are the ratios of the differentials: delta(x_retrieved)/delta(x_real) Often the trace gas mole fractions are strongly varying with altitude. Then it is very useful to provide the fractional averaging kernels (e.g., Keppens et al., 2015). Because delta(x)/x =delta(ln(x)), the fractional averaging kernel is the same as the logarithmic scale averaging kernel. - Units: unitless (or [1]) - Term, for the averaging kernel of the methane remote sensing profile (CF-standard name “mole_fraction_of_methane_in_air”) we propose the new CF-standard names: 1: kernel_of mole_fraction_of_methane_in_air 2: fractional_kernel_of_mole_fraction_of_methane_in_air

II: - Description, storage efficient averaging kernels: The averaging kernel matrix is rather storage intensive and in order to ensure their availability for each individual retrieval, a storage efficient format is needed. In Schneider et al. (2022) a singular vector decomposition his proposed. This allows a storage efficient provision of the averaging kernels in form of the number of leading singular vectors (the rank), the left leading singular vectors, the leading singular values, and the right leading singular vectors. Weber (2019) documents the respective storage efficiency.

- Units: unitless (or [1])

- Term, for providing the storage efficient kernels of the methane remote sensing profile we propose the new CF-standard names: 1: kernel_rank_of_mole_fraction_of_methane_in_air 2: kernel_left_vector_of_mole_fraction_of_methane_in_air 3: kernel_singular_values_of_mole_fraction_of_methane_in_air 4: kernel_right_vector_of_mole_fraction_of_methane_in_air and: 1: fractional_kernel_rank_of_mole_fraction_of_methane_in_air 2: fractional_kernel_left_vector_of_mole_fraction_of_methane_in_air 3: fractional_kernel_singular_values_of_mole_fraction_of_methane_in_air 4: fractional_kernel_right_vector_of_mole_fraction_of_methane_in_air

References: Keppens, A., Lambert, J.-C., Granville, J., Miles, G., Siddans, R., van Peet, J. C. A., van der A, R. J., Hubert, D., Verhoelst, T., Delcloo, A., Godin-Beekmann, S., Kivi, R., Stübi, R., and Zehner, C.: Round-robin evaluation of nadir ozone profile retrievals: methodology and application to MetOp-A GOME-2, Atmos. Meas. Tech., 8, 2093–2120, https://doi.org/10.5194/amt-8-2093-2015, 2015.

Rodgers, C.: Inverse Methods for Atmospheric Sounding: Theory and Praxis, Series on Atmospheric, Oceanic and Planetary Physics – Vol. 2, edited by: Taylor, F. W., University of Oxford, World Scientific Publishing Co., Singapore, ISBN 981-02-2740-X, 2000.

Schneider, M., Ertl, B., Diekmann, C. J., Khosrawi, F., Weber, A., Hase, F., Höpfner, M., García, O. E., Sepúlveda, E., and Kinnison, D.: Design and description of the MUSICA IASI full retrieval product, Earth Syst. Sci. Data, 14, 709–742, https://doi.org/10.5194/essd-14-709-2022, 2022.

Weber, A.: Storage-Efficient Analysis of Spatio-Temporal Data with Application to Climate Research, Master Thesis, Karlsruhe Institute of Technology, https://doi.org/10.5281/ZENODO.3360021, 2019.

[JonathanGregory]

Dear Matthias

Thanks for your proposals. Are these quantities in common use? The main purpose of standard names is to identify quantities that are contained in datasets generated by different authors or centres, in order to indicate which are the same quantity in different datasets. In standard names and their descriptions the practice is to use language whose meaning should be obvious to someone who is not an expert in the subject concerned, which is my position wrt your proposals. On the first proposal:

• I think we need more information than "kernel" in the standard name, because many techniques have things called kernels. Looking at your description, I would be inclined to call it something like derivative_of_mole_fraction_of_methane_in_air_estimated_by_remote_sensing_wrt_actual. Is that what it means?

• If so, the fractional one would be derivative_of_logarithm_of_mole_fraction_of_methane_in_air_estimated_by_remote_sensing_wrt_actual.

• If these variables have two identical dimensions and sets of vertical coordinates, some convention is needed to specify which dimension is which. We don't like to depend on the order of dimensions in general, since this is fragile information. It might be better to define new standard names for each of the two vertical coordinates, so they can be distinguished.

The SVD version raises some more questions for me. Perhaps we could discuss these points first.

Best wishes

Jonathan

[github-actions[bot]]

This issue has had no activity in the last 30 days. This is a reminder to please comment on standard name requests to assist with agreement and acceptance. Standard name moderators are also reminded to review @feggleton @japamment

[MSchneiderMetamorphoses]

Dear Jonathan,

thanks for your response/comments and please apologize my late reply. In the following I give my replies to your comments:

Best regards, Matthias

Your comment: Are these quantities in common use?

My reply: Yes, they are. If you want to correctly use the remote sensing data the averaging kernels are essential, because they tell what is measured (sensitivity, vertical structures). A quantitative use of the data (comparison, assimilation, etc) strongly depends on the averaging kernels. I guess mostly experienced users work with the data and they know about the averaging kernels; however, the lack of a standard naming/storing of the kernels requires that the respective users have to generate slightly different tools for different data sets. I think it would be good to improve this situation.

Your comment: The main purpose of standard names is to identify quantities that are contained in datasets generated by different authors or centres, in order to indicate which are the same quantity in different datasets. In standard names and their descriptions the practice is to use language whose meaning should be obvious to someone who is not an expert in the subject concerned, which is my position wrt your proposals. On the first proposal:

I think we need more information than "kernel" in the standard name, because many techniques have things called kernels. Looking at your description, I would be inclined to call it something like derivative_of_mole_fraction_of_methane_in_air_estimated_by_remote_sensing_wrt_actual. Is that what it means?

The fractional one would be derivative_of_logarithm_of_mole_fraction_of_methane_in_air_estimated_by_remote_sensing_wrt_actual.

My reply: Ok, I understand. However, on the other hand "averaging kernel" is well established and its meaning is very clear within the remote sensing community. So, do you think it could be kept in the standard name, so my proposal would be something like:

remote_sensing_averaging_kernel_of_mole_fraction_of_methane_in_air

and

remote_sensing_logarithmic_scale_averaging_kernel_of_mole_fraction_of_methane_in_air

Your comment: If these variables have two identical dimensions and sets of vertical coordinates, some convention is needed to specify which dimension is which. We don't like to depend on the order of dimensions in general, since this is fragile information. It might be better to define new standard names for each of the two vertical coordinates, so they can be distinguished.

My reply: In GEOMS (https://evdc.esa.int/documentation/geoms/) the dimensions are clarified by an explanation in the comment/note attribute. Could it be sufficient for the CF Standard to explain this similarly, maybe in the description attribute, example of text that could be added (similar to what is used in GEOMS): "Dimension 1 are the averaging kernel rows; dimension 2 are the averaging kernel columns. First three averaging kernel values for the initial altitude level for the first measurement are: 0.0481000 0.0978700 0.0996300"

Or as you propose: we define an extra vertical dimension. For instance, if the vertical dimension is called "atmospheric_levels" we can define an additional dimension and in order to relate it clearly to the averaging kernel we call it: "atmospheric_levels_remote_sensing_averaging_kernel_column"

[github-actions[bot]]

This issue has had no activity in the last 30 days. This is a reminder to please comment on standard name requests to assist with agreement and acceptance. Standard name moderators are also reminded to review @feggleton @japamment

[JonathanGregory]

Dear Matthias @MSchneiderMetamorphoses

Thanks for your reply and apologies for my even slower one!

Google agrees that "averaging kernel" is a commonly used term. :smile: I think remote_sensing_averaging_kernel, as you suggest, would give sufficient context. Your definition text says what it is i.e. a matrix of partial derivatives of retrieved value wrt actual value.

In your reply, you suggested remote_sensing_logarithmic_scale_averaging_kernel_of_mole_fraction_of_methane_in_air for the fractional one. Could it be correctly called remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air? This would have the advantage of keeping the phrase remote_sensing_averaging_kernel unbroken.

Each standard name needs its own self-contained description. That will involve repetition of parts of your two pieces of text, but that's OK. It's normal.

The contents of comment is not normally standardised. For an analysis program, I think it's more convenient to identify the two axes of model level from standardised attributes of their individual coordinate variables. Therefore I think distinct standard names for the two coordinate variables would be best. What are the coordinates of the levels? For instance, are they model_level_number, or air_pressure, or something else? If you agree with this, it would be useful to state in the description of the averaging kernel what the standard name should be for each of the coordinate variables of level.

For the SVD decomposition, I would suggest (left_singular_vector|right_singular_vector|singular_values)_of_remote_sensing_averaging_kernel... because, again, this would keep the phrase remote_sensing_averaging_kernel. What is the dimension of these quantities? What is the "kernel rank"? Perhaps the latter is the answer to the former?

Best wishes and thanks

Jonathan

[efisher008]

Hi @MSchneiderMetamorphoses,

For your information, the names from the original proposal have now been added to the CF editor. There are 10, if I counted correctly? They can be viewed by searching in the interface here. https://cfeditor.ceda.ac.uk/proposals/1

Would you like to respond to @JonathanGregory's suggestions regarding the restructuring of parts of your proposed name remote_sensing_logarithmic_scale_averaging_kernel_of_mole_fraction_of_methane_in_air to remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air, the coordinate variables/vector terms, and the dimensions/kernel rank questions?

Once a consensus is reached about the exact phrasing/structure of the standard names and that what they describe are suitable quantities, I can amend these names in the editor and mark them for acceptance within 7 days. If you could also provide an updated, unique description for each name (as Jonathan mentioned, these are self-contained so all relevant phrases will need to be repeated for each name), this will help to get the ball rolling again. Thank you.

Best regards, Ellie

[MSchneiderMetamorphoses]

Dear Ellie and Jonathan,

thanks for reminding and again apologies for the delay in replying. See below my reply.

Dear Matthias @MSchneiderMetamorphoses

Thanks for your reply and apologies for my even slower one!

Google agrees that "averaging kernel" is a commonly used term. 😄 I think remote_sensing_averaging_kernel, as you suggest, would give sufficient context. Your definition text says what it is i.e. a matrix of partial derivatives of retrieved value wrt actual value.

In your reply, you suggested remote_sensing_logarithmic_scale_averaging_kernel_of_mole_fraction_of_methane_in_air for the fractional one. Could it be correctly called remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air? This would have the advantage of keeping the phrase remote_sensing_averaging_kernel unbroken.

Each standard name needs its own self-contained description. That will involve repetition of parts of your two pieces of text, but that's OK. It's normal.

Yes, I agree with your suggestion.

The contents of comment is not normally standardised. For an analysis program, I think it's more convenient to identify the two axes of model level from standardised attributes of their individual coordinate variables. Therefore I think distinct standard names for the two coordinate variables would be best. What are the coordinates of the levels? For instance, are they model_level_number, or air_pressure, or something else? If you agree with this, it would be useful to state in the description of the averaging kernel what the standard name should be for each of the coordinate variables of level.

So far we use "altitude" as vertical coordinate, but "air_pressure" (or other standard) can also be used. The "coordinate attribute" informs about the actually used coordinate. If I understand correctly, the preference (to avoid ambiguities) would be to have for each of the two vertical dimensions an extra vertical coordinate with a distinct standard name. However, both corresponding variables would have the same values.

In addition to "altitude", we could define the new standard name "altitude_actual_atmosphere". In the description attribute we can explain that it is to identify the dimension of the averaging kernel that refers to the actual atmosphere and that the other dimension (the existing standard "altitude") refers to the retrieved atmosphere.

For the SVD decomposition, I would suggest (left_singular_vector|right_singular_vector|singular_values)_of_remote_sensing_averaging_kernel... because, again, this would keep the phrase remote_sensing_averaging_kernel. What is the dimension of these quantities? What is the "kernel rank"? Perhaps the latter is the answer to the former?

Ok. The dimension is level x rank. "rank" is the number of considered eigenvalues. So the respective standard name could be "rank_of remote_sensing_averaging_kernel"?

Thanks and best regards, Matthias

Best wishes and thanks

Jonathan

[JonathanGregory]

Dear Matthias

altitude is also an existing CF standard name, meaning height above the geoid. Yes, I understand the problem that the two axes are the same geophysical quantity. That situation exists also for forecasts, which have two times: the time of the forecast state, and the forecast_reference_time of the starting state. It would be good similarly to give yours distinct standard names, as you say. In the forecast case the "actual" one is unqualified. That pattern would suggest altitude for the actual and altitude_of_retrieval or retrieval_altitude for the other. Would that be OK?

Yes, rank_of remote_sensing_averaging_kernel could be the standard name for the coordinate axis of the singular vectors and values. If they are in some defined order, I suppose another and more informative possibility would be to choose a standard name that says what the order is. For instance, eigenmodes might be put in decreasing order of eigenvalue, and referred to the "first", "second", etc., but what is a self-explanatory name for this ordinal number or index?

Best wishes

Jonathan

[MSchneiderMetamorphoses]

Dear Jonathan,

Dear Matthias

altitude is also an existing CF standard name, meaning height above the geoid. Yes, I understand the problem that the two axes are the same geophysical quantity. That situation exists also for forecasts, which have two times: the time of the forecast state, and the forecast_reference_time of the starting state. It would be good similarly to give yours distinct standard names, as you say. In the forecast case the "actual" one is unqualified. That pattern would suggest altitude for the actual and altitude_of_retrieval or retrieval_altitude for the other. Would that be OK?

I suggest to use 'altitude' for the dimension that describes the retrieved state, because this is what all the data product is about. Then define a new standard name 'true state_altitude' for the second vertical coordinate of the averaging kernel. The term true state is generally used in remote sensing literature (see, for instance Rodgers 2000). Please be aware that the problem with ambiguity of the vertical dimensions is avoided in the decomposed averaging kernels (left_singular_vector|right_singular_vector|singular_values)_of_remote_sensing_averagingkernel), because then we have 'left...' and 'right...' eigenvectors, which have only one vertical dimension.

Yes, rank_of remote_sensing_averaging_kernel could be the standard name for the coordinate axis of the singular vectors and values. If they are in some defined order, I suppose another and more informative possibility would be to choose a standard name that says what the order is. For instance, eigenmodes might be put in decreasing order of eigenvalue, and referred to the "first", "second", etc., but what is a self-explanatory name for this ordinal number or index?

I understand, that it might be useful to have also a standard name for the coordinate of the eigenvalues. The name 'eigenmode' seems reasonable to me. We use 'rank' actually for the number of used eigenvalues (the number of the leading eigenvalues), this number depends on the averaging kernel, i.e. it is observation specific. So in the description of 'rank_of remote_sensing_averaging_kernel' we could explain that it is the number of eigenmodes that exist for the respective kernel.

Best wishes

Jonathan

Thanks, Matthias

[JonathanGregory]

Dear Matthias

I suggest to use altitude for the dimension that describes the retrieved state, because this is what all the data product is about. Then define a new standard name true_state_altitude for the second vertical coordinate of the averaging kernel. The term true state is generally used in remote sensing literature (see, for instance Rodgers 2000).

OK, that makes sense. You could also argue that it's analogous to forecast timeand forecast_reference_time, I think.

it might be useful to have also a standard name for the coordinate of the eigenvalues. The name eigenmode seems reasonable to me. We use "rank" actually for the number of used eigenvalues (the number of the leading eigenvalues), this number depends on the averaging kernel, i.e. it is observation specific. So in the description of rank_of_remote_sensing_averaging_kernel we could explain that it is the number of eigenmodes that exist for the respective kernel.

Yes, I understand. However, it's the coordinate variable that needs the standard name, not the dimension. The "rank" is a name for the dimension, I would say. I think it would make sense to give a standard name of eigenmode to a coordinate variable whose values indicate the ordinal number of the eigenmodes (1, 2, 3 etc.). Is that what you would use for a coordinate variable? Of course, you could use the name rank for the dimension. CF does not attribute meaning to the names of variables and dimensions, as you know. e.g.

dimensions:
   rank=10;
   alttude=20;

variables:
  float lsv(altitude,rank);
    lsv:standard_name="left_singular_vector_of_remote_sensing_averaging_kernel_of_methane_in_air";
  float rank(rank);
    rank:standard_name="eigenmode";

I don't know whether the above makes sense! I'm guessing.

Best wishes

Jonathan

[MSchneiderMetamorphoses]

Dear Jonathan,

ok, I would like to summarize to make sure that I fully understand where we need dimensions and where variables with standard names:

dimensions:
   observation_id=100
   rank=10;
   levels=20;

variables:
   long time(observation_id);
      :standard_name = "time";
      :units = "seconds since 2000-01-01 00:00:00";
      :axis = "T";
  float lat(observation_id);
      :standard_name = "latitude";
      :units = "degrees_north";
      :axis = "Y";
   float lon(observation_id);
      :standard_name = "longitude";
      :units = "degrees_east";
      :axis = "X";
   float altitude_levels(observation_id, levels);
      :standard_name = "altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
   float eigenmode(observation_id);
      :standard_name = "eigenmode";
      :units = "1";
   float avk_lsv(observation_id,levels,rank):
      :standard_name="left_singular_vector_of_remote_sensing_averaging_kernel_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon altitude_levels eigenmode";
   float avk_rsv(observation_id,levels,rank):
      :standard_name="right_singular_vector_of_remote_sensing_averaging_kernel_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon altitude_levels eigenmode";
   float avk_sv(observation_id,rank):
      :standard_name="singular_values_of_remote_sensing_averaging_kernel_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon eigenmode";
   float avk_r(observation_id):
      :standard_name="rank_of_remote_sensing_averaging_kernel_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon";

Is this correct for the decomposed kernels?

And for the full kernel we need an additional standard_name for the second altitude. I still don't fully understand, how we then clearly distinguish between the two vertical dimensions. Is this accomplished by the coordinates attribute?

float true_state_altitude_levels(observation_id, levels);
      :standard_name = "true_state_altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
float avk_full(observation_id,levels,levels):
      :standard_name="remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon altitude_levels true_state_altitude_levels";

Or I guess to avoid confusion we also need an extra dimension:

dimensions:
   observation_id=100
   rank=10;
   levels=20;
   true_state_levels=20;

float true_state_altitude_levels(observation_id, true_state_levels);
      :standard_name = "true_state_altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
float avk_full(observation_id,levels,true_state_levels):
      :standard_name="remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon altitude_levels true_state_altitude_levels";

Thanks for your support and best regards, Matthias

[JonathanGregory]

Dear Matthias

Yes, your first example looks right, for the kernels. I guess that the dimension rank must be the maximum rank you need to consider, and the actual rank of the kernel varies, depending on observation_id. If the rank were always the same, you would not need the variable avk_r. Is that correct?

Also, does the altitude depend on observation_id? If it doesn't, it could be a coordinate variable, rather than an auxiliary coordinate variable:

dimensions:
   observation_id=100;
   rank=10;
   altitude=20;

variables:
   float altitude(altitude);
      :standard_name = "altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
   float eigenmode(observation_id);
      :standard_name = "eigenmode";
      :units = "1";
   float avk_lsv(observation_id,altitude,rank);
      :standard_name="left_singular_vector_of_remote_sensing_averaging_kernel_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon eigenmode";

Would it be acceptable to have a singular value in the standard name singular_value_of_remote_sensing_averaging_kernel_of_methane_in_air, instead of values? We don't have many standard names for discrete quantities, but I think singular is usual e.g. realization and latitude.

To distinguish the two altitudes, you need two dimensions, as in your third example. You've written it with the true state altitude as an auxiliary coordinate variable, with their altitudes depending on observation_id. If the true state altitudes were the same for all observations, it could be a coordinate variable too:

dimensions:
   observation_id=100
   altitude=20;
   true_state_altitude=20;

variables:
   float altitude(altitude);
      :standard_name = "altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
  float true_state_altitude(true_state_altitude);
      :standard_name = "true_state_altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
  float avk_full(observation_id,altitude,true_state_altitude):
      :standard_name="remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon";

Best wishes

Jonathan

[MSchneiderMetamorphoses]

Dear Jonathan,

Dear Matthias

Yes, your first example looks right, for the kernels. I guess that the dimension rank must be the maximum rank you need to consider, and the actual rank of the kernel varies, depending on observation_id. If the rank were always the same, you would not need the variable avk_r. Is that correct?

yes, correct, the actual rank of the kernel varies, depending on 'observation_id'

Also, does the altitude depend on observation_id? If it doesn't, it could be a coordinate variable, rather than an auxiliary coordinate variable:

yes, also the altitude varies with 'observation_id'

dimensions:
   observation_id=100;
   rank=10;
   altitude=20;

variables:
   float altitude(altitude);
      :standard_name = "altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
   float eigenmode(observation_id);
      :standard_name = "eigenmode";
      :units = "1";
   float avk_lsv(observation_id,altitude,rank);
      :standard_name="left_singular_vector_of_remote_sensing_averaging_kernel_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon eigenmode";

Would it be acceptable to have a singular value in the standard name singular_value_of_remote_sensing_averaging_kernel_of_methane_in_air, instead of values? We don't have many standard names for discrete quantities, but I think singular is usual e.g. realization and latitude.

yes, "singular_value_of_remote_sensing_averaging_kernel_of_methane_in_air" instead of "singular_values_of_remote_sensing_averaging_kernel_of_methane_in_air" is fine.

To distinguish the two altitudes, you need two dimensions, as in your third example. You've written it with the true state altitude as an auxiliary coordinate variable, with their altitudes depending on observation_id. If the true state altitudes were the same for all observations, it could be a coordinate variable too:

dimensions:
   observation_id=100
   altitude=20;
   true_state_altitude=20;

variables:
   float altitude(altitude);
      :standard_name = "altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
  float true_state_altitude(true_state_altitude);
      :standard_name = "true_state_altitude";
      :units = "m";
      :axis = "Z";
      :positive = "up";
  float avk_full(observation_id,altitude,true_state_altitude):
      :standard_name="remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air"
      :units = "1";
      :coordinates = "time lat lon";

ok!

Best wishes

Jonathan

Thanks again, and I wish you a peaceful Christmas break and a happy new year, Matthias

[JonathanGregory]

Dear Matthias

That's great. I am glad that I have understood correctly what you mean, and that we have agreed. When you have a moment, please could you restate what we have agreed since Ellie's posting two weeks ago, so that she can make these changes to your proposal in the editor? Thanks.

Best wishes to you too for holidays and 2024

Jonathan

[efisher008]

Dear @MSchneiderMetamorphoses,

I have summarised the new version of the proposal below based on the discussion. Is there anything you'd like to change about it?

I have tried to base these directly on the numbered list in the original proposal, please let me know if I have made a mistake!

1. Term: remote_sensing_averaging_kernel_of_mole_fraction_of_methane_in_air Original term: kernel_of mole_fraction_of_methane_in_air

2. Term: remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air Original term: fractional_kernel_of_mole_fraction_of_methane_in_air

3. Term: rank_of_remote_sensing_averaging_kernel_of_mole_fraction_of_methane_in_air Original term: kernel_rank_of_mole_fraction_of_methane_in_air

4. Term: left_singular_vector of_remote_sensing_averaging_kernel_of_mole_fraction_of_methane_in_air Original term: kernel_left_vector_of_mole_fraction_of_methane_in_air

5. Term: singular_value_of_remote_sensing_averaging_kernel_mole_fraction_of_methane_in_air Original term: kernel_singular_values_of_mole_fraction_of_methane_in_air

6. Term: right_singular_vector of_remote_sensing_averaging_kernel_of_mole_fraction_of_methane_in_air Original term: kernel_right_vector_of_mole_fraction_of_methane_in_air

7. Term: rank_of_remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air Original term: fractional_kernel_rank_of_mole_fraction_of_methane_in_air

8. Term: left_singular_vector of_remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air Original term: fractional_kernel_left_vector_of_mole_fraction_of_methane_in_air

9. Term: singular_value_of_remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air Original term: fractional_kernel_singular_values_of_mole_fraction_of_methane_in_air

10. Term: right_singular_vector_of_remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air Original term: fractional_kernel_right_vector_of_mole_fraction_of_methane_in_air

and two extra standard names raised in the discussion:

11. Term: true_state_altitude

12. Term: eigenmode

If you could correct the above names according to your understanding, and also propose a description for each name (this will of course repeat parts of the description, but a description for each is needed for clarity), that would be great.

I would also suggest that the references you included in your original post on this issue be added to the descriptions for these standard names, i.e.

• Keppens, A., Lambert, J.-C., Granville, J., Miles, G., Siddans, R., van Peet, J. C. A., van der A, R. J., Hubert, D., Verhoelst, T., Delcloo, A., Godin-Beekmann, S., Kivi, R., Stübi, R., and Zehner, C.: Round-robin evaluation of nadir ozone profile retrievals: methodology and application to MetOp-A GOME-2, Atmos. Meas. Tech., 8, 2093–2120, https://doi.org/10.5194/amt-8-2093-2015, 2015.
• Rodgers, C.: Inverse Methods for Atmospheric Sounding: Theory and Praxis, Series on Atmospheric, Oceanic and Planetary Physics – Vol. 2, edited by: Taylor, F. W., University of Oxford, World Scientific Publishing Co., Singapore, ISBN 981-02-2740-X, 2000.
• Schneider, M., Ertl, B., Diekmann, C. J., Khosrawi, F., Weber, A., Hase, F., Höpfner, M., García, O. E., Sepúlveda, E., and Kinnison, D.: Design and description of the MUSICA IASI full retrieval product, Earth Syst. Sci. Data, 14, 709–742, https://doi.org/10.5194/essd-14-709-2022, 2022.
• Weber, A.: Storage-Efficient Analysis of Spatio-Temporal Data with Application to Climate Research, Master Thesis, Karlsruhe Institute of Technology, https://doi.org/10.5281/ZENODO.3360021, 2019.

Best regards (and a happy new year!), Ellie

[MSchneiderMetamorphoses]

Dear Ellie,

many thanks for your collaboration!

I edited your summarised listing (my edits are marked as yellow). Please find it as a word file in the attachment. Let me know if this is what you expected or if you need more information.

Best regards,

Matthias CF-standard_names_discussion_v240115.docx

[efisher008]

Dear Matthias,

Thank you very much for the summary and for providing the definitions for each name. These do make sense and I'm glad the name changes match my understanding!

I have made the changes in the editor and added the three new names, true_state_altitude, eigenmode, and true_state_pressure along with their definitions. What are the units for these: do true_state_altitude and true_state_pressure have units of metres and Pascals respectively, perhaps?

Are there any more comments you'd like to make on these names?

Best regards, Ellie

[efisher008]

Dear Matthias,

As there hasn't been any further discussion yet on the units for the "newest" proposed names true_state_altitude, eigenmode, and true_state_pressure, I suggest that the other 10 names in this proposal can be accepted in 7 days if there are no further comments, and these three will require a little further discussion.

Best regards (and a happy Easter/Ramadan), Ellie

[JonathanGregory]

Dear Matthias @MSchneiderMetamorphoses and Ellie @efisher008

Thank you both for you work on this and for your flexibility, Matthias.

Cheers

Jonathan

[efisher008]

Dear Matthias @MSchneiderMetamorphoses and Jonathan @JonathanGregory,

I have now accepted these names (except for true_state_altitude, eigenmode, and true_state_pressure as agreed), and they will be published in the next release of the standard names table (v85), currently planned for mid-May.

If you have any further comments for the three above which are still under discussion, I would be happy to update these in the editor. Most importantly they are missing units.

Best, Ellie

[efisher008]

Dear Matthias @MSchneiderMetamorphoses,

During final review of the accepted names to be published in v85 of the standard names table, it was noticed that three of the proposed names (left_singular_vector of_remote_sensing_averaging_kernel_of_mole_fraction_of_methane_in_air, right_singular_vector of_remote_sensing_averaging_kernel_of_mole_fraction_of_methane_in_air and left_singular_vector of_remote_sensing_averaging_kernel_of_logarithm_of_mole_fraction_of_methane_in_air) had spaces instead of underscores after the word 'vector'. These have now been fixed and the issue marked as accepted.

Best regards, Ellie

[efisher008]

Closing this issue as these names have been accepted in version 85 of the CF standard names table, published on 21 May 2024 (https://cfconventions.org/Data/cf-standard-names/85/build/cf-standard-name-table.html).