-
Notifications
You must be signed in to change notification settings - Fork 8
Modis lidar bug fix #4
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
Conversation
Dustin, I thought we had already approved this. Or maybe this was COSP2, and not COSP1? While the changes look fine to me, I don't recall if we decided how we were going to treat any further changes to COSP1. Did we agree on that? Namely, the issue of whether we would make a separate release, calling this v1.4.3 for example, so that user can revert to 1.4.2 if they so chose. After all we put a lot of effort into making it clear to the community their options regarding version (i.e. the cospVersionTable) and I wouldn't want new confusion to arise if the code for 1.4.2 suddenly differs from the code that was in 1.4.2 on the date (1 Feb 2018) we announced the previous MODIS bug fix. It is unfortunate, but I suspect necessary that once we have created a v1.4.3 that we will need to announce it to the community again. Robert, Alejandro do you agree? Steve |
Steve -
If we decide to put this code on the master we will want to issue a new release. If we do make a new release we should make it very clear that moving to the new release is not necessary expect under the two circumstances I mentioned (bothered by divide-by-zeros, want to use MODIS hi/mid/low).
- Robert
On Apr 5, 2018, at 3:50 PM, klein21 <notifications@github.com<mailto:notifications@github.com>> wrote:
Dustin,
I thought we had already approved this. Or maybe this was COSP2, and not COSP1?
While the changes look fine to me, I don't recall if we decided how we were going to treat any further changes to COSP1. Did we agree on that? Namely, the issue of whether we would make a separate release, calling this v1.4.3 for example, so that user can revert to 1.4.2 if they so chose.
After all we put a lot of effort into making it clear to the community their options regarding version (i.e. the cospVersionTable) and I wouldn't want new confusion to arise if the code for 1.4.2 suddenly differs from the code that was in 1.4.2 on the date (1 Feb 2018) we announced the previous MODIS bug fix.
It is unfortunate, but I suspect necessary that once we have created a v1.4.3 that we will need to announce it to the community again.
Robert, Alejandro do you agree?
Steve
|
Thanks, I was responding before I had seen your post on the PMC thread. I’m now responding to that…
From: Robert Pincus <notifications@github.com>
Reply-To: CFMIP/COSPv1 <reply@reply.github.com>
Date: Thursday, April 5, 2018 at 1:09 PM
To: CFMIP/COSPv1 <COSPv1@noreply.github.com>
Cc: "Klein, Stephen A." <klein21@llnl.gov>, Comment <comment@noreply.github.com>
Subject: Re: [CFMIP/COSPv1] Modis lidar bug fix (#4)
Steve -
If we decide to put this code on the master we will want to issue a new release. If we do make a new release we should make it very clear that moving to the new release is not necessary expect under the two circumstances I mentioned (bothered by divide-by-zeros, want to use MODIS hi/mid/low).
- Robert
On Apr 5, 2018, at 3:50 PM, klein21 <notifications@github.com<mailto:notifications@github.com>> wrote:
Dustin,
I thought we had already approved this. Or maybe this was COSP2, and not COSP1?
While the changes look fine to me, I don't recall if we decided how we were going to treat any further changes to COSP1. Did we agree on that? Namely, the issue of whether we would make a separate release, calling this v1.4.3 for example, so that user can revert to 1.4.2 if they so chose.
After all we put a lot of effort into making it clear to the community their options regarding version (i.e. the cospVersionTable) and I wouldn't want new confusion to arise if the code for 1.4.2 suddenly differs from the code that was in 1.4.2 on the date (1 Feb 2018) we announced the previous MODIS bug fix.
It is unfortunate, but I suspect necessary that once we have created a v1.4.3 that we will need to announce it to the community again.
Robert, Alejandro do you agree?
Steve
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#4 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AfO_cG01JE5BtfV1EVu5GkSAysxh2Uc6ks5tlnmsgaJpZM4TI7To>.
|
For the record, the discussion that went to the PMC is below.
|
Hi @dustinswales , please can you merge this request? I don't seem to have write permissions for this repository (I think I do for COSPv2). Thanks! |
Hi @dustinswales please can you label this commit as v1.4.3? As discussed in the last PMC call, I'll announce the new releases in the users list. Thanks! |
@alejandrobodas. Done. Thanks! |
Recently some small issues were uncovered by modeling centers implementing COSP1.4.2. and I propose we include these changes on the COSP1 master branch.
*) In the LIDAR simulator there was a division-by-zero for scenes for really thick clouds. This does not impact any of the CALIPSO LIDAR diagnostics
*) In the MODIS simulator, some of the gridmean diagnostics were being set to zero for clear scenes, when they should have been set to undefined. This impacted the averaging being performed by the model, resulting in much large values than expected. In the offline tests, we see the following:
lwpmodis: 69.28 % of values differ, relative range: -5.19e-01 to 3.00e+00
tautlogmodis: 9.15 % of values differ, relative range: -8.96e-01 to 1.43e+00
iwpmodis: 34.64 % of values differ, relative range: -1.16e-01 to 4.26e-01
tauimodis: 0.65 % of values differ, relative range: 1.03e-01 to 1.03e-01
tauwmodis: 8.50 % of values differ, relative range: -5.66e-01 to 3.10e+00
tautmodis: 9.15 % of values differ, relative range: -5.66e-01 to 3.10e+00
reffclimodis: 34.64 % of values differ, relative range: -2.24e-01 to 4.26e-01
reffclwmodis: 69.28 % of values differ, relative range: -1.85e-01 to 3.21e-01
tauwlogmodis: 8.50 % of values differ, relative range: -8.96e-01 to 1.43e+00
clwmodis: 8.50 % of values differ, relative range: -8.00e-01 to 6.67e-01
cltmodis: 9.15 % of values differ, relative range: -8.00e-01 to 1.76e-01
cllmodis: 5.88 % of values differ, relative range: -8.00e-01 to -2.50e-01
climodis: 0.65 % of values differ, relative range: -1.43e-01 to -1.43e-01
clhmodis: 1.31 % of values differ, relative range: -1.25e-01 to 2.14e-01
pctmodis: 9.15 % of values differ, relative range: -4.26e-01 to 1.05e-01
tauilogmodis: 0.65 % of values differ, relative range: 6.50e+00 to 6.50e+00
clmodis: 0.04 % of values differ, relative range: -3.33e-01 to 6.00e-01
For both cases, diagnostics requested for CFMIP3/CMIP6 are not impacted.