Closed dustinswales closed 6 years ago
@alejandrobodas
@RobertPincus
I'm moving this part of the conversation from the issue into here.
add a variable for each of the dimensions. For instance, when I read the MISR histogram, I get MISR CFAD / (%) (altitude_bin_centers: 16; cloud_optical_depth_bin_centers: 7; -- : 153)
but when I read in the 3D calipso cloud fraction I get:
Calipso cloud-fraction / (%) (-- : 40; -- : 153)
The '--' indicates that there is no variable associated with that axis. Hopefully adding these is not too much work.
The CF checker complains of the following: latitude variable 'latitude' should define standard_name='latitude' (same for longitude)
Global attribute 'Conventions' field is not present
Whenever possible, I would add the standard_name attribute.
Some of the long names are not strictly correct, e.g. use of 'CFAD' for ISCCP and MISR histograms.
Alejandro, thanks for taking a look at the new output file. I've taken your suggestions and incorporated them in the latest commit. One thing I'm not certain of, what should I put in the global attribute "Conventions"?
Alejandro, thanks for taking a look at the new output file. I've taken your suggestions and incorporated them in the latest commit. One thing I'm not certain of, what should I put in the global attribute "Conventions"?
See http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/ch02s06.html .
@dustinswales Thanks Dustin, that's great. You can use "CF-1.6" for the conventions. The CF-checker throws a few errors. I list them below, with the correct standard names or units below each error. Some of the variables don't have standard name, so we can leave them without it. You can check the new file using: http://pumatest.nerc.ac.uk/cgi-bin/cf-checker-dev.pl
ERROR: (3.3): Invalid standard_name: cloud_optical_depth atmosphere_optical_thickness_due_to_cloud
ERROR: (3.3): Invalid standard_name: cloud_optical_depth atmosphere_optical_thickness_due_to_cloud
ERROR: (3.3): Invalid standard_name: column No standard name.
ERROR: (3.3): Invalid standard_name: cloud_optical_depth atmosphere_optical_thickness_due_to_cloud
ERROR: (3.1): Units are not consistent with those given in the standard_name table. dBZ
ERROR: (3.3): Invalid standard_name: cloud_top_height cloud_top_altitude
ERROR: (3.3): Invalid standard_name: effective_radius_of_cloud_liquid_particle effective_radius_of_cloud_liquid_water_particle
ERROR: (3.3): Invalid standard_name: effective_radius_of_cloud_liquid_particle Doesn't exist.
ERROR: (3.1): Units are not consistent with those given in the standard_name table. hPa
ERROR: (3.3): Invalid standard_name: atmosphere_cloud_ice_water_content atmosphere_mass_content_of_cloud_ice
ERROR: (3.3): Invalid standard_name: histogram_of_cloud_optical_depth_over_particle_size ice_cloud_area_fraction_in_atmosphere_layer
ERROR: (3.3): Invalid standard_name: effective_radius_of_cloud_ice_particle Doesn't exist.
ERROR: (3.3): Invalid standard_name: histogram_of_cloud_optical_depth_over_particle_size liquid_water_cloud_area_fraction_in_atmosphere_layer
ERROR: (3.3): Invalid standard_name: effective_radius_of_cloud_liquid_particle effective_radius_of_cloud_liquid_water_particle
@alejandrobodas Thanks for this. I went ahead and fixed these errors. I ran the new reference file through the CF compliance checker:
Using CF Checker Version 3.0.0 Checking against CF Version CF-1.6 Using Standard Name Table Version 50 (2018-03-14T11:01:19Z) Using Area Type Table Version 7 (14 March 2018) .... ERRORS detected: 0 WARNINGS given: 0 INFORMATION messages: 0
Thanks, Dustin. As far as I'm concerned, this change is fine. If no-one else has comments, I think this can be merged.
A question for you, @alejandrobodas - we have heard exactly nothing from the users’ group about the proposal to remove the off-line capability. Should @dustinswales remove that as part of this merge, or wait?
Thanks, Dustin. As far as I'm concerned, this change is fine. If no-one else has comments, I think this can be merged.
Hi @RobertPincus personally I think there is no need to wait for longer. @klein21, do you agree?
Yes, I agree that there is no need to wait longer. Robert, please send another e-mail to thread saying that you are moving forward. Who knows, it might stir a reaction.
Steve
From: alejandrobodas notifications@github.com Reply-To: "CFMIP/COSPv2.0" reply@reply.github.com Date: Monday, March 19, 2018 at 6:36 AM To: "CFMIP/COSPv2.0" COSPv2.0@noreply.github.com Cc: "Klein, Stephen A." klein21@llnl.gov, Mention mention@noreply.github.com Subject: Re: [CFMIP/COSPv2.0] New offline driver for COSP2. (#7)
Hi @RobertPincushttps://github.com/robertpincus personally I think there is no need to wait for longer. @klein21https://github.com/klein21, do you agree?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CFMIP/COSPv2.0/pull/7#issuecomment-374213490, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AfO_cNLkztQYJ7HJ7XEJM6Ggie2ne_nmks5tf7RCgaJpZM4So-YW.
I propose to merge the changes from the newDriver branch onto the master branch. The newDriver branch contains a new offline driver, which does not rely on CMOR, instead output is written to a single netCDF file. Modified regression tools are provided.
Also included in this request is a somewhat substantial re-organization of the code. While working with Brian Eaton at NCAR to implement COSP2 in CESM2, we realized that the code could be organized in a more accommodating manner for inline use with GCMs. This reorganization does not impact any of the COSP2 code, as everything in src/ remains the same. What has changed is the organization of the overlaying driver/model-interface region.
Dustin