-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standard names: *averaging kernels for mole fraction profiles of atmospheric trace gases* #147
Comments
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:
The SVD version raises some more questions for me. Perhaps we could discuss these points first. Best wishes Jonathan |
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 |
Dear Jonathan, thanks for your response/comments and please apologize my late reply. 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" |
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 |
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 In your reply, you suggested 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 For the SVD decomposition, I would suggest ( Best wishes and thanks Jonathan |
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 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, |
Dear Ellie and Jonathan, thanks for reminding and again apologies for the delay in replying. See below my reply.
Yes, I agree with your suggestion.
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. 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.
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,
|
Dear Matthias
Yes, Best wishes Jonathan |
Dear Jonathan,
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).
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.
Thanks, |
Dear Matthias
OK, that makes sense. You could also argue that it's analogous to forecast
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
I don't know whether the above makes sense! I'm guessing. Best wishes Jonathan |
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:
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?
Or I guess to avoid confusion we also need an extra dimension:
Thanks for your support and best regards, |
Dear Matthias Yes, your first example looks right, for the kernels. I guess that the dimension Also, does the altitude depend on
Would it be acceptable to have a singular 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
Best wishes Jonathan |
Dear Jonathan,
yes, correct, the actual rank of the kernel varies, depending on 'observation_id'
yes, also the altitude varies with 'observation_id'
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.
ok!
Thanks again, and I wish you a peaceful Christmas break and a happy new year, |
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 |
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!
and two extra standard names raised in the discussion:
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.
Best regards (and a happy new year!), |
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, |
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, Are there any more comments you'd like to make on these names? Best regards, |
Dear Matthias, As there hasn't been any further discussion yet on the units for the "newest" proposed names Best regards (and a happy Easter/Ramadan), |
Dear Matthias @MSchneiderMetamorphoses and Ellie @efisher008 Thank you both for you work on this and for your flexibility, Matthias. Cheers Jonathan |
Dear Matthias @MSchneiderMetamorphoses and Jonathan @JonathanGregory, I have now accepted these names (except for 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, |
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 ( Best regards, |
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). |
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.
The text was updated successfully, but these errors were encountered: