Skip to content
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: Propose new additions to the standard names table (MODIS output from COSP simulator) #52

Open
brandonduran opened this issue Jun 25, 2024 · 30 comments
Labels
CMIP7 Vocabulary proposals for CMIP7 variables standard name (added by template) Requests and discussions for standard names and other controlled vocabulary

Comments

@brandonduran
Copy link

CF-Convention Discussion Proposal:
Proposer's name: Brandon Duran
Date: 25-6-2024

I would like to propose standard names for MODIS output from the COSP satellite simulator package, including new joint histograms of cloud droplet effective radius (CER) and cloud water path (CWP). These diagnostics are similar to those from the ISCCP satellite simulator, but feature distinction by cloud thermodynamic phase. All of the proposed names below are for joint histograms summarizing the co-variability of different cloud properties (cloud top pressure, cloud optical depth, cloud water path, cloud droplet effective radius).

Naming is guided by conventions for the ISCCP satellite simulator; specifically, clisccp, which is a 7x7 (cloud top pressure x optical depth) matrix. As such, I propose that all MODIS cloud top pressure by optical depth histograms follow this naming, with the base of clmodis and any additional modifiers. To distinguish the new CER-CWP histograms, I propose the modifier ‘cwpr’, such that the base 6x7 (CER x CWP) joint histogram is named clmodis_cwpr.

The MODIS optical depth (tau) bounds are as follows: 0-0.3, 0.3-1.3, 1.3-3.6, 3.6-9.4, 9.4-23, 23-60, >60. The MODIS cloud top pressure (CTP) bounds are as follows [hPa]: 800 and higher, 800-680, 680-560, 560-440, 440-310, 310-180, 180-0. CTP and tau bounds match bounds from the ISCCP clisccp output.

The MODIS cloud liquid water path (LWP) bounds are as follows [g/m2]: 0-10, 10-30, 30-60, 60-100, 100-150, 150-250, >250. The MODIS cloud ice water path (IWP) bounds are as follows [g/m2]: 0-20, 20-50, 50-100, 100-200, 200-400, 400-1000, >1000. The MODIS liquid cloud droplet effective radius (CER) bounds are as follows [𝜇m]: 4-8, 8-10, 10-12.5, 12.5-15, 15-20, >20. The MODIS ice cloud ice-crystal effective radius bounds are as follows [𝜇m]: 5-10, 10-20, 20-30, 30-40, 40-50, >50.

The proposed name for the joint histogram diagnostics are:
Term Long Name Units

  1. clmodis modis_cloud_area_fraction 1
    The MODIS cloud area fraction is diagnosed from atmosphere model output by the MODIS simulator software in such a way as to be comparable with the observational diagnostics of MODIS (Moderate Resolution Imaging Spectroradiometer). Cloud area fraction is also called “cloud amount” and “cloud cover.” As seen from above, mean fraction of grid column occupied by cloud of optical depths and heights specified by the tau and pressure intervals given above. Dimensions of the histogram are cloud top pressure and cloud optical depth (7x7).

  2. clmodis_liquid modis_cloud_area_fraction_liquid 1
    Liquid means liquid-topped clouds, as seen by the MODIS simulator. Dimensions of the histogram are cloud top pressure and cloud optical depth (7x7).

  3. clmodis_ice modis_cloud_area_fraction_ice 1
    Ice means ice-topped clouds, as seen by the MODIS simulator. Dimensions of the histogram are cloud top pressure and cloud optical depth (7x7).

  4. clmodis_cwpr_liquid modis_cloud_area_fraction_cloud_water_path_effective_radius_liquid 1
    Liquid means liquid-topped clouds, as seen by the MODIS simulator. Dimensions of the histogram are cloud liquid water path and cloud droplet effective radius (7x6).

  5. clmodis_cwpr_ice modis_cloud_area_fraction_cloud_water_path_effective_radius_ice 1
    Ice means ice-topped clouds, as seen by the MODIS simulator. Dimensions of the histogram are cloud ice water path and cloud ice-crystal effective radius (7x6).

Thank you!

@brandonduran brandonduran added add to cfeditor (added by template) Moderators are requested to add this proposal to the CF editor standard name (added by template) Requests and discussions for standard names and other controlled vocabulary labels Jun 25, 2024
Copy link

Thank you for your proposal. These terms will be added to the cfeditor (http://cfeditor.ceda.ac.uk/proposals/1) shortly. Your proposal will then be reviewed and commented on by the community and Standard Names moderator.

@efisher008
Copy link
Collaborator

Dear Brandon,

Thank you for your proposal. I have now added the names to the CF editor. Thanks for your patience as the editor had been experiencing some technical issues, which are now resolved. I have used the long names as the "interim" names (as abbreviations are not generally accepted in names aside from where the usage is well-defined) , but there will need to be some discussion on the format of these, in particular the longer names to ensure they are comprehensible and consistent with existing names.

You can view the entries here:

  1. modis_cloud_area_fraction - https://cfeditor.ceda.ac.uk/proposal/5355/edit
  2. modis_cloud_area_fraction_liquid - https://cfeditor.ceda.ac.uk/proposal/5357/edit
  3. modis_cloud_area_fraction_ice - https://cfeditor.ceda.ac.uk/proposal/5354/edit
  4. modis_cloud_area_fraction_cloud_water_path_effective_radius_liquid - https://cfeditor.ceda.ac.uk/proposal/5356/edit
  5. modis_cloud_area_fraction_cloud_water_path_effective_radius_ice - https://cfeditor.ceda.ac.uk/proposal/5353/edit

Should the matrix dimensions (i.e. numbers in brackets at the end of the description) be included in the editor entries?

Best regards,
Ellie

@efisher008 efisher008 removed the add to cfeditor (added by template) Moderators are requested to add this proposal to the CF editor label Jul 15, 2024
@brandonduran
Copy link
Author

Hi Ellie,

No worries about the delay. I think it is fine to omit the dimensions. Although the MODIS output differs from ISCCP output in that not all histograms share the same (7x7) shape, this would simply be reflected in the output of these proposed variables and probably does not need to be included in the editor entries.

Thanks!
-Brandon

@taylor13
Copy link

Without a careful analysis, it would be nice to make the names a little easier for humans to parse. For example, can somehow "liquid cloud top" be worked into the name? (I must confess I can't come up with anything that works.)

@brandonduran
Copy link
Author

Perhaps the names could be modified as such, although they do become a mouthful:

  1. modis_cloud_area_fraction_liquid --> modis_cloud_area_fraction_liquid_topped
  2. modis_cloud_area_fraction_ice --> modis_cloud_area_fraction_ice_topped
  3. modis_cloud_area_fraction_cloud_water_path_effective_radius_liquid --> modis_cloud_area_fraction_cloud_water_path_effective_radius_liquid_topped
  4. modis_cloud_area_fraction_cloud_water_path_effective_radius_ice --> modis_cloud_area_fraction_cloud_water_path_effective_radius_ice_topped

Another variation of this convention could be:

  1. modis_cloud_area_fraction_liquid --> modis_liquid_topped_cloud_area_fraction
    etc., which retains the cloud area fraction expression, but rearranges the position of 'ice' and 'liquid' to more directly specify that we are referring to liquid- and ice-topped clouds separately.

I would strongly suggest leaving modis_cloud_area_fraction unchanged, as this diagnostic is not partitioned by cloud-top phase. At most, it could be modified to modis_total_cloud_area_fraction

@taylor13
Copy link

I liked your suggestions and agree with your last remark. Let's see what others think.

@efisher008
Copy link
Collaborator

Hi @brandonduran and @taylor13,

I agree with the variation stated in @brandonduran's post: having the liquid/ice-topped component earlier in the term e.g. modis_liquid_topped_cloud_area_fraction seems sensible as it is more understandable that we are distinguishing between liquid- and ice-topped clouds with the name variations. There are currently no names in the CF standard names table with modis as a component, so this will be an opportunity to establish a new precedent for these sort of variables going forward.

As a compromise which does not break up the modis_cloud_area_fraction string but still has a more intelligible order, how does
the format {ice_topped/liquid_topped}_cloud_area_fraction{_etc.} sound?

Best,
Ellie

@JonathanGregory
Copy link
Contributor

Dear @brandonduran

Thanks for working on this.

If these quantities are histograms, the standard name should be histogram_of_X, where X is the variable that has been histogrammed. This pattern is in the guidelines, and there are a couple of existing standard names which use it. The reason for this is that a histogram of X isn't the same geophysical quantity as X itself. The histogram is a dimensionless (in the sense of being a pure number) number of counts in the bin, whereas X could have any dimension (i.e. any canonical unit) e.g. a histogram of temperature has units of 1, not K. Area fraction is dimensionless anyway, so the unit is not affected in your case, but a histogram of cloud area as a function of cloud-top pressure and cloud optional depth is not the same quantity as cloud area as a function of the same two variables. The former is a count, which could be zero or any positive integer, while the latter is a floating-point number between 0 and 1.

If these are all histograms, I suppose that (1) is histogram_of_cloud_area_fraction, (2) and (4) are histogram_of_liquid_water_topped_cloud_area_fraction, and (3) and (5) histogram_of_ice_topped_cloud_area_fraction. (Other standard names use the liquid_water, not just liquid, to describe clouds.) I'm mot sure I've understood this correctly, but it looks like (2) and (4) are distinguished only by the dimensions of the histogram (array dimensions, that is, not the same sense of "dimension" as above), likewise (3) and (5). Those pairs can each have the same standard name, because the physical quantity is the same. That is perfectly fine for CF, since the coordinate variables are also metadata.

Alternatively, the standard names could say what the dimensions are. The guideline allows for that as well with _over_Y; these are two-dimensional histograms, so they'd be _over_Y_and_Z, I suppose. If these were probability density functions, rather than histograms, it would be necessary to identify the dimensions, because they affect the unit. For example, the units of probability density of cloud area fraction as a function of liquid water path and effective radius are (kg m-2)-1 m-1 = kg-1 m.

Best wishes

Jonathan

@brandonduran
Copy link
Author

Hi @JonathanGregory , thanks for your very thorough review. I will attempt to clarify in what follows.

These variables can all be thought of variations of the CMIP6 clisccp variable, or what is often called FISCCP1_COSP. As such, their units are really percentages, such that summing up the histogram over all bins yields the total grid-box cloud fraction (as a percentage). In this sense, these are not true 'histograms' and are more accurately described as cloud area percentages as a function of different cloud properties; I simply have adopted the traditional nomenclature of referring to these as ISCCP or MODIS joint histograms. This artifact is a result of the observational version of these quantities, which indeed are pixel counts of clouds, representing a true histogram. Your clarification is important though, as the method in which these diagnostics have currently been implemented in the COSP code package results in them being reported in percentages, not fractions. Therefore, I will modify all that follows to represent these as cloud area percentages %, rather than cloud area fractions 1. I'm not sure if this is a necessary change, as my understanding is that isccp_cloud_area_fraction is still reported in units of %, rather than 1, so please advise regarding this. Apologies for the confusion and mistake on my end.

In light of this, it seems like the histogram_of_ prefix would not be an accurate description of these variables. Your second point, however, is correct. (2) and (4), and (3) and (5) are only distinguished by the array dimensions of the 'histogram.' They represent the same physical quantity, but differ in how they are partitioned (cloud-top pressure x optical depth, cloud water path x effective radius).

Incorporating your thoughts and @efisher008 suggestions:

  1. modis_cloud_area_percentage or modis_total_cloud_area_percentage
  2. modis_ice_topped_cloud_area_percentage , coordinate variables: (cloud-top pressure x optical depth)
  3. modis_liquid_topped_cloud_area_percentage, coordinate variables: (cloud-top pressure x optical depth)
  4. modis_ice_topped_cloud_area_percentage, coordinate variables: (cloud water path x effective radius)
  5. modis_liquid_topped_cloud_area_percentage, coordinate variables: (cloud water path x effective radius)

Note that now (2) and (4), and (3) and (5) share the same standard name due to their representation of the same physical quantity. For CF, they would be distinguished by their differing coordinate variables in the metadata. I think that we should retain modis at the front of the standard names, following the standard for other COSP output, where the name of the simulator precedes the geophysical quantity (ie, isccp_cloud_area_fraction). I am not averse to rearranging, though, given that this is the first instance of the modis qualifier .

Thanks for the discussion and happy to clarify the above further.

@JonathanGregory
Copy link
Contributor

JonathanGregory commented Jul 22, 2024

Dear @brandonduran

Thanks for your careful explanation. This is interesting! I'm not sure I understand yet exactly what these quantities are. "Area fraction of X" (where X is something that is either present or absent at a given location, e.g. cloud, land or sea-ice) means the area (canonical unit m2) where X is found divided by the area (also m2) considered. For example, land_area_fraction in a cell of a latitude--longitude grid means the area occupied by cloud in the gridbox divided by the area of the gridbox.

Your coordinates are cloud-top pressure and optical depth, not longitude and latitude, but a cloud area fraction should have the same meaning. You divide up the area of the globe into a grid of 7x7 in these quantities. You could express any quantity in these coordinates e.g.

dimensions:
  ctp=7;
  tau=7;
  two=2;
variables:
  float ctp(ctp);
    ctp:standard_name="air_pressure_at_cloud_top";
    ctp:units="Pa";
    ctp:bounds="ctp_bounds";
  float ctp_bounds(ctp,two);
  float tau(tau);
    tau:standard_name="atmosphere_optical_thickness_due_to_cloud";
    tau:units="1";
    tau:bounds="tau_bounds";
  float tau_bounds(tau,two);
  float rsut(ctp,tau);
    rsut:standard_name="toa_outgoing_shortwave_flux";
    rsut:units="W m-2";
    rsut:cell_methods="area: mean";
    rsut:cell_measures="area: ctptauarea";
  float ctptauarea(ctp,tau);
    ctptauarea:standard_name="cell_area";
    ctptauarea:units = "m2";
  float caf(ctp,tau);
    caf:standard_name="cloud_area_fraction";
    caf:units="1";
    caf:cell_methods="area: mean";
    caf:cell_measures="area: ctptauarea";

rsut is calculated by the GCM as a latitude--longitude field in the first instance. We assign each latitude--longitude gridcell to one of the (ctp,tau) cells. The area of each (ctp,tau) cell is the sum of the areas of the latitude--longitude cells that are assigned to it, and I've shown that the area is stored in ctptauarea in case it's useful. We multiply rsut in each latitude--longitude gridcell by the area of the cell, giving a quantity in W, we assign these products to the (ctp,tau) cells and add them up within those cells. Now for each (ctp,tau) cell we have a quantity in W and its area in m2. We divide the former by the latter to get the rsut in (ctp,tau) cells in W m-2. This is the area-mean TOA outgoing shortwave flux as a function of cloud-top pressure and cloud optical depth.

The GCM also produces a cloud area fraction on its latitude--longitude grid, which specifies the fraction of the area of each cell which is occupied by cloud. We assign this field to the same set of (ctp,tau) cells. Each (ctp,tau) cell has an area (the number in ctptauarea, the same as before) and a cloud area, which is the sum of the area of cloud contained in all of the latitude--longitude cells assigned to the (ctp,tau). Both of these are areas. By dividing the cloud area by the gridcell area, we obtain caf, the cloud area fraction as a function of cloud-top pressure and cloud optical depth.

Is caf the same sort of quantity as the ones you are using? If so, I agree they are cloud area fractions! Actually the canonical unit is 1 and they should be called fraction, not percentage, as you first had it. % means 0.01, which is dimensionally the same as 1, so it's fine if you provide the data in units="%". Sorry about that confusion.

We probably had a discussion over ISCCP about why it's necessary to put isccp_ at the front of the name, and it's the same with MODIS. Is there some reason why a modis_cloud_area_fraction isn't the same geophysical quantity as a cloud_area_fraction in a GCM or as generally understood? If they are supposed to be comparable geophysical quantities, they ought to have the same standard name. That is the main purpose of standard names.

Best wishes and thanks for your work on this

Jonathan

@brandonduran
Copy link
Author

Hi @JonathanGregory,

Here are some answers to the questions you've posed:

why a modis_cloud_area_fraction isn't the same geophysical quantity as a cloud_area_fraction in a GCM

They aren't the same quantity because the latter is the model native cloud fraction, whereas the former is the cloud area fraction as detected by the MODIS satellite simulator. Because the simulator is meant to reproduce what the MODIS satellite observes in reality, it is not inherently meant to capture the same quantity. In principle, the simulator should faithfully reproduce the satellite (including all of its biases), and is simulating what the MODIS satellite would retrieve when looking at the model atmosphere. It is looking at the same population of clouds captured by cloud_area_fraction, but is then reporting its own cloud_area_fraction given its method of sampling / detection. The same is true for the ISCCP simulator. Both MODIS and ISCCP cloud_area_fraction are different from GCM cloud_area_fraction and from each other because of differences in retrieval, detection, etc. Hopefully that clears up the difference.

Is caf the same sort of quantity as the ones you are using?
From your description, I believe so. In a given grid cell, the MODIS simulator captures a certain cloud_area_fraction, which is then partitioned into the bins of the histogram (ie, ctp and cot) such that the sum of over all histogram bins gives the grid cell cloud_area_fraction. From your clarification, we should keep the names as cloud_area_fraction rather than cloud_area_percentage (still units of %). Each histogram bin thus contains the area of clouds in a grid cell that fall within the respective bounds of said bin divided by the area of the grid cell.

I'll include below a truncated example of this output for one of the four histograms proposed above, as it is currently implemented in a few GCMs, in case that is useful:

dimensions:
   lat = 180 ;
   lon = 360 ;
   cosp_lwp_modis = 7;
   cosp_reffliq = 6 ;
   time = 12 ;
float CLMODIS_LWPR(time, cosp_reffliq, cosp_lwp_modis, lat, lon);
   units = "%"
   cell_measures = 'area: area'
   cell_methods = 'time: mean'

cosp_lwp_modis (length n) and cosp_reffliq (len m) represent the midpoints of the histogram bins. Accordingly, there are complementary coordinates of cosp_lwp_modis_bnds (length n+1) and cosp_reffliq_bnds (len m+1), which give the bin edges for the respective histograms. These midpoints and bounds are intended to match the corollary quantities of the observational data.

I'm tagging in @caseywall7926 , who helped with the development of these histograms. Casey, any additions?

Hopefully we are converging to closer agreement, but also happy to continue clarifying! Thanks!

@caseywall7926
Copy link

caseywall7926 commented Jul 23, 2024

Hi all,

Thanks for this discussion. The MODIS diagnostics represent the fraction of gridbox area occupied by clouds, so they are indeed cloud area fractions. The MODIS diagnostics each represent the cloud area fraction as a function of two different cloud properties (cloud-top pressure vs. cloud visible optical thickness or cloud particle effective radius vs. cloud water path). The MODIS diagnostics also have different variables for liquid-topped clouds and ice-topped clouds, as reported by the MODIS simulator. In other words, the MODIS diagnostics are similar to caf but are expressed as a function of different cloud properties rather than just the overall cloud area fraction.

As Brandon said, the MODIS diagnostics are very similar to the ISCCP variable clisccp, which represents the cloud area fraction as a function of cloud-top pressure and cloud visible optical thickness. (One point of clarification is that these are passive satellite instruments, so they report the cloud-top pressure of the highest cloud in the column and the total column cloud visible optical thickness for each pixel.) The MODIS diagnostics are different from clisccp because they separate the data into liquid-topped clouds and ice-topped clouds and some of the variables express the cloud area fraction as a function of cloud-particle-size vs. cloud-water-path rather than cloud-top-pressure vs. cloud-optical thickness.

Best,
Casey

@JonathanGregory
Copy link
Contributor

Dear @brandonduran and @caseywall7926

Thanks for your helpful clarifications. I think that answers my questions. These quantities are indeed cloud_area_fractions of various kinds, canonical unit 1 (but % could be used for units), and I understand why it's necessary to prefix them with modis_. I believe that we've agreed you need three modis_ standard names, then - right?

I hadn't appreciated that the fields are functions of latitude and longitude as well as the two cloud-related variables. That makes sense. I think they should also be mentioned in the cell_methods as well. Imagine that the data had much higher resolution for effective radius and liquid water path. You would derive the field you have at the coarser resolution in these dimensions by aggregating many 2D cells into one 2D cell by meaning them, wouldn't you. Since mean is a linear operation, if there is no missing data it wouldn't matter whether you did the axes separately and in which order, or both at once. If there could be missing data, it does matter. Actually the data doesn't come from a coarse-graining operation like that, but from binning to make a two-dimensional histogram. Since both dimensions are processed at once in making the histogram, I think area: mean cosp_lwp_modis: cosp_reffliq: mean would be the most accurate description of the process. If the histogramming is done timestep by timestep, and the monthly means calculated later, time: mean should appear last.

Best wishes

Jonathan

@caseywall7926
Copy link

Hi @JonathanGregory,

The histogramming is done timestep by timestep with simulated "satellite pixel data" that are meant to be smaller than the gridbox, and monthly means of the histograms are calculated later. In case it helps to clarify, the calculation of simulated "satellite pixel data" and the averaging process are described in section 4b and 4c of Pincus et al. (2012), respectively.

@JonathanGregory
Copy link
Contributor

Thanks, @caseywall7926. That confirms my suggestion that cell_methods="area: mean cosp_lwp_modis: cosp_reffliq: mean time: mean" for these quantities. (You didn't ask about that, I know, but I was prompted by Brandon's CDL example.)

@caseywall7926
Copy link

Great, thanks @JonathanGregory for your suggestions and discussion to clarify the description of these diagnostics!

Best,
Casey

@efisher008
Copy link
Collaborator

Dear @brandonduran @caseywall7926 @JonathanGregory,

Thank you all for the detailed discussion and it looks as though you have come to a common conclusion about the description of the MODIS diagnostics represented by three standard names. Would you please summarise what the agreed format of these standard names will be, and which original names they are "descended from" in this sense? Is the following correct, and is there anything further to add to the descriptions?

modis_cloud_area_fraction:
The MODIS cloud area fraction is diagnosed from atmosphere model output by the MODIS simulator software in such a way as to be comparable with the observational diagnostics of MODIS (Moderate Resolution Imaging Spectroradiometer). Cloud area fraction is also called “cloud amount” and “cloud cover.” As seen from above, mean fraction of grid column occupied by cloud of optical depths and heights specified by the tau and pressure intervals given above. Dimensions of the histogram are cloud top pressure and cloud optical depth.

modis_ice_topped_cloud_area_fraction:
Ice means ice-topped clouds, as seen by the MODIS simulator.

modis_liquid_topped_cloud_area_fraction:
Liquid means liquid-topped clouds, as seen by the MODIS simulator.

Best wishes,
Ellie

@brandonduran
Copy link
Author

Hi @JonathanGregory @caseywall7926 @efisher008 ,

I believe the 3 standard names posted above are what we agreed upon. As established, both modis_ice_topped_cloud_area_fraction and modis_liquid_topped_cloud_area_fraction have two versions that differ in their coordinate variables, but as Jonathan pointed out, they can share a common name.

The modis_ prefix descends from the isccp_cloud_area_fraction standard. To distinguish that these are cloud area fractions as seen by a specific satellite instrument simulator, not the same as cloud area fractions diagnosed by the native model, the prefix format of satellite name_ is employed. The three standard names, rather than one, are proposed because the MODIS simulator is able to partition clouds by their thermodynamic phase. The ISCCP simulator does not have this capability.

Hope this covers it all! Cheers,
-Brandon

@efisher008
Copy link
Collaborator

efisher008 commented Jul 25, 2024

Hi @brandonduran,

As it looks like the names and descriptions have been agreed, if no further comments or feedback have been received after 7 days, these will be accepted and published in the next version of the standard names table, which is expected to be released in August.

Thanks,
Ellie

@efisher008 efisher008 added the accept within 7 days Starts 7 day countdown to accept a change to standard names or other controlled vocabulary label Jul 25, 2024
@japamment japamment transferred this issue from cf-convention/discuss Jul 29, 2024
@efisher008
Copy link
Collaborator

Dear @brandonduran,

As the 7-day period has passed, these names have now been accepted and will be released in v86 of the standard names table, scheduled for the second half of August. Thank you again for your proposal.

Best wishes,
Ellie

@efisher008 efisher008 added accepted Agreed for inclusion in the next release of the standard name table or other controlled vocabulary and removed accept within 7 days Starts 7 day countdown to accept a change to standard names or other controlled vocabulary labels Aug 1, 2024
@brandonduran
Copy link
Author

Great! Thank you so much @efisher008

@efisher008
Copy link
Collaborator

efisher008 commented Aug 13, 2024

Dear @brandonduran,

This is just to make you aware that the following text has been added to the description of your three accepted MODIS names to clarify the definition of the phrase area_fraction (as decided in #24):
"Area fraction" is the fraction of a grid cell's horizontal area that has some characteristic of interest. It is evaluated as the area of interest divided by the grid cell area, or if the cell_methods restricts the evaluation to some portion of that grid cell (e.g. "where sea_ice"), then it is the area of interest divided by the area of the identified portion.
This does not require any action from you.

Best,
Ellie

@japamment japamment added the CMIP7 Vocabulary proposals for CMIP7 variables label Aug 29, 2024
@martinjuckes
Copy link

Dear @brandonduran , @efisher008 , @japamment .

Hello all, sorry to re-open this, but I'd like to question some inconsistency which appears to have crept in between the treatment of cloud fractions for ISCCP, MISR and the new MODIS variables. The first two use the existing standard names cloud_area_fraction_in_atmosphere_layer, liquid_water/ice_cloud_area_fraction_in_atmosphere_layer. The _in_atmosphere_layer suffix is generally used to distinguish area fractions associated with part of the atmospheric column rather than the full column. The question is, I think, whether we want the models view of what is in the appropriate atmospheric layer which corresponds to the MODIS data, or is there some specific way in which the cloud cover in a given atmospheric layer is calculated which is specific to MODIS? The distinction between ice_topped and liquid_water_topped looks clear, but I'm not clear whether we are asking for a specific MODIS interpretation of what is at the top of a cloud.

Secondly, the following two sentences are in the description in the current standard name table: "As seen from above, mean fraction of grid column occupied by cloud of optical depths and heights specified by the tau and pressure intervals given above. Dimensions of the histogram are cloud top pressure and cloud optical depth. " The sentence first refers to comments "above" in the github discussion and so is not much use to readers of the CF Standard Name table. The second makes reference to specific vertical coordinates. The usual practice is to recommend that variables use dimensions to specify any required coordinates. Also, as noted by @JonathanGregory , this quantity is not considered as a histogram.

Regards,
Martin

@brandonduran
Copy link
Author

Hi @martinjuckes ,

To address your second point, the following text could be inserted into the description for modis_cloud_area_fraction : "The MODIS optical depth (tau) bounds are as follows: 0-0.3, 0.3-1.3, 1.3-3.6, 3.6-9.4, 9.4-23, 23-60, >60. The MODIS cloud top pressure (CTP) bounds are as follows [hPa]: 800 and higher, 800-680, 680-560, 560-440, 440-310, 310-180, 180-0. CTP and tau bounds match bounds from the ISCCP clisccp output." Instead of "dimensions of the histogram," perhaps we could say cloud area fraction as a function of cloud top pressure and cloud optical depth? That would seem to solve the issue you raised.

I'm not sure I can answer your first point adequately. For absolute clarity, @caseywall7926 can you comment on this?

Thanks,
Brandon

@taylor13
Copy link

I think this issue probably needs reconsideration. The revised description given immediately above addresses two of Martin's concerns since the MODIS cloud categories are defined by the specific pressure and optical depth values now given in the description.

Turning to the issue of in_atmosphere_layer: I think that in CMIP6 using the existing standard names cloud_area_fraction_in_atmosphere_layer and liquid_water/ice_cloud_area_fraction_in_atmosphere_layer for the ISCCP and MISR cloud amount "histograms" might have been a mistake. It is true that the values reported from the cloud satellite simulators are a function of height (pressure), but the height is the top of the cloud, whereas the amount actually reported reflects the full cloud column, so this is a bit different from reporting the cloud in a single layer (of a model or otherwise). Relevant to this claim, note that in the definition of cloud_area_fraction, the description includes the directive: "For the cloud area fraction between specified levels in the atmosphere, standard names including "cloud_area_fraction_in_atmosphere_layer" are used." In future CMIP phases I think we should use the standard names isccp_cloud_area_fraction and a new standard name misr_cloud_area_fraction without the suffix in_atmosphere_layer when reporting the "histograms" of ISCCP and MISR cloud fractions. If this is done, then modis_cloud_area_fraction will be consistent.

One might wonder what the standard name should be for total ISCCP or MISR cloud fraction. I think that isccp_cloud_area_fraction and misr_cloud_area_fraction can be used regardless if the the values are binned by pressure/optical depth categories or reported as a total summed over all categories. This would be analogous to radiative fluxes being spectrally resolved or "total" over all wavelengths, which in CF share the same standard name. The cloud fraction variables would distinguishable, of course, by looking at whether or not the tau/pressure coordinates were included.

One final point regarding terminology. In scientific publications, the cloud fraction data which is a function of optical depth and cloud top height is commonly referred to as a "histogram", but this does seem to be inconsistent with the strict definition of a histogram. These are histograms where cloud counts are weighted by cloud fraction (and they might be specially normalized).

@brandonduran or @caseywall7926: please correct anything above that seems incorrect. I'm not an expert.

@martinjuckes
Copy link

@taylor13 : Thanks, I agree with your points. We should modify the standard names used for ISCCP and MISR variables.

I also agree that we don't need specific "total" variants of standard names. This distinction is made clear by the dimensions in the CF metadata and by the long_name for human-friendly text.

@efisher008 efisher008 added moderator attention (added by GitHub action) Moderators are requested to consider this issue and removed accepted Agreed for inclusion in the next release of the standard name table or other controlled vocabulary labels Oct 14, 2024
@efisher008
Copy link
Collaborator

Hi @brandonduran, @taylor13, @martinjuckes,

Thank you for your comments. I am removing the "accepted" label and adding the "moderator attention" label for the time being, while this issue is addressed.

Best wishes,
Ellie

@github-actions github-actions bot removed the moderator attention (added by GitHub action) Moderators are requested to consider this issue label Oct 14, 2024
@efisher008 efisher008 added the moderator attention (added by GitHub action) Moderators are requested to consider this issue label Oct 18, 2024
@efisher008
Copy link
Collaborator

Hi all,

I have entered the three previously accepted names from this issue back into "under discussion" in the CF editor. The terms are viewable here:

If an informed consensus has been reached on how to modify/standardise the structure and description text of these names, I would appreciate if a post could be made with a formal proposal to make these changes.

Thank you,
Ellie

@github-actions github-actions bot removed the moderator attention (added by GitHub action) Moderators are requested to consider this issue label Oct 22, 2024
@martinjuckes
Copy link

Hi Ellie,

Could you also add misr_cloud_area_fraction as proposed by Karl above?

@efisher008
Copy link
Collaborator

Hi @martinjuckes,

I have added the name misr_cloud_area_fraction to the CF editor. The entry is here: https://cfeditor.ceda.ac.uk/proposal/5501
Please let me know if there is additional text which should be added to the description.

If either you or @taylor13 (with input from @brandonduran and/or @caseywall7926) could now make a post with a formal proposal (in this issue) for changes to the existing standard names/descriptions as discussed above, that would be much appreciated.

Best wishes,
Ellie

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CMIP7 Vocabulary proposals for CMIP7 variables standard name (added by template) Requests and discussions for standard names and other controlled vocabulary
Projects
None yet
Development

No branches or pull requests

7 participants