Precipitating Convective Cloud (PCC): cloud-radiation feedbacks for BMJ Cumulus Scheme #921
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s scheme (Koh and Fonseca, 2016, QJRMS).
|
@rmfonsecaweb
Once you get these ironed out, then we'll be able to more seriously look at your PR. |
rmfonsecaweb
changed the title
|
@rmfonsecaweb |
|
Thanks Dave. Hope everything is OK now.
It is the first time I am using Github so apologies for this.
Ricardo
On Tuesday, June 4, 2019, 7:55:08 AM GMT+4, Dave Gill <notifications@github.com> wrote:
@rmfonsecaweb
Ricardo,
In the PR commit message, you can see that the hash tag symbol is used to reference pull request numbers. Use a different method to refer to the citations.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@rmfonsecaweb |
|
@rmfonsecaweb @dudhia @weiwangncar |
|
Our PCC scheme is not coupled with the new RRTMG-K radiation scheme. We considered this option but the scheme was found not to be very computationally efficient when compared to the RRTMG scheme. On the other hand, the RRTMG fast was found to give a similar performance to the RRTMG scheme with a reduction in the computational time by roughly 20 to 50%.
Just to be clear: you can use any cloud microphysics scheme with our BMJ-PCC scheme, no issues there, you only have to use the RRTM or RRTMG or RRTMG fast radiation schemes for the coupling to work. Our recommendation was solely based on simulations we did with different cloud microphysics scheme in the tropics. We found that, when modifying the BMJ by reducing the "Fs" parameter as stated in the text and using the one of the WDM* MP schemes, WRF gives a good estimate of the observed surface radiation fluxes in the convective tropics as well as the observed precipitation. If your interest is on the shallow cumulus and stratocumulus clouds that are ubiquitous on the eastern side of the subtropical oceans than other MP schemes are probably a better choice.
Ricardo
On Tuesday, June 4, 2019, 8:02:14 AM GMT+4, Dave Gill <notifications@github.com> wrote:
@rmfonsecaweb
Ricardo,
Maybe since you recommend the WSM* or WDM* MP schemes, should you (by default) support the rrtmgk radiation schemes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
davegill
changed the title
|
Hi Dave,
I understand. We have talked to Jimy Dudhia and more recently to Judith Berner and highlighted the value of our PCC scheme. Why is this scheme important? Well, in the current WRF version, sub-grid cloud interaction with radiation can be switched on in mass flux schemes in particular in the GF, G3, GD and KF cumulus schemes, but is not available for adjustment schemes that donot deal with condensates like the BMJ scheme. Our PCC scheme is fully general and can easily be extended to any other convective adjustment scheme. As a result, regardless of the cumulus scheme the user decides to employ in his simulations, sub-grid cloud- radiation interactions can be accounted for. We believe you agree that it would be very good to have this scheme available in the model. Let's see what the experts have to say about this. We would really like to see our contributions available in a future version of WRF. Thank you!
Hope you have a pleasant day and a great week!
Best wishes,Ricardo
On Tuesday, June 4, 2019, 8:07:57 AM GMT+4, Dave Gill <notifications@github.com> wrote:
@rmfonsecaweb @dudhia @weiwangncar
Ricardo,
When a developer modifies a routine that is originally from a different developer, such as you introducing code into the BMJ scheme, we might need to have the BMJ developer(s) agree. The same might be true for the radiation schemes. Let's see what the WRF physics group says about this point.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@rmfonsecaweb If there are specific choices that you recommend for a user with your scheme, we should include that information in share/module_check_a_mundo.F. Here is an example of what I am referring to: |
|
Dave,Thank you for your suggestion. Assuming that our contributions will be added to an upcoming version of the model, what we had in mind was to mention these things in the release note, sort of what e.g. Anders Jensen did with the new ISHMAEL cloud microphysics scheme. We do not want to be restrictive and just state those recommendations for users to bear in mind for their work.
On Tuesday, June 4, 2019, 8:18:42 AM GMT+4, Dave Gill <notifications@github.com> wrote:
@rmfonsecaweb
Ricardo,
Thanks for the detailed responses so far.
If there are specific choices that you recommend for a user with your scheme, we should include that information in share/module_check_a_mundo.F. Here is an example of what I am referring to:
!-----------------------------------------------------------------------
! Check that mosiac option cannot turn on when sf_urban_physics = 2 and 3
!-----------------------------------------------------------------------
DO i = 1, model_config_rec % max_dom
IF ( model_config_rec % sf_surface_mosaic .EQ. 1 .AND. &
(model_config_rec % sf_urban_physics(i) .EQ. 2 .OR. &
model_config_rec % sf_urban_physics(i) .EQ. 3 ) ) THEN
wrf_err_message = '--- ERROR: mosaic option cannot work with urban options 2 and 3 '
CALL wrf_message ( wrf_err_message )
wrf_err_message = '--- ERROR: Fix sf_surface_mosaic and sf_urban_physics in namelist.input.'
CALL wrf_message ( wrf_err_message )
wrf_err_message = '--- ERROR: Either: use Noah LSM without the mosaic option, OR change the urban option to 1 '
CALL wrf_debug ( 0, TRIM( wrf_err_message ) )
count_fatal_error = count_fatal_error + 1
END IF
ENDDO
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Actually this should first be put on a contributor branch because we need
more formal approval
for the develop branch. I might suggest naming the branch something related
to the scheme.
Jimy
…On Mon, Jun 3, 2019 at 9:48 PM Dave Gill ***@***.***> wrote:
@rmfonsecaweb <https://github.com/rmfonsecaweb>
Ricardo,
1. Change the base branch to be develop (not master). It is unlikely
that you really want to change 53 files. Just click the edit button up at
the top of this github page.
2. Update the pull request commit message (there are prompts ready to
help out). Goto #921 <#921>
3. Provide more detail than "PCC scheme" in the title.
Once you get these ironed out, then we'll be able to more seriously look
at your PR.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#921?email_source=notifications&email_token=AEIZ77DLISHWDM2JY5DXPXTPYXQ2RA5CNFSM4HSYD7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW3KPKA#issuecomment-498509736>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEIZ77C4RKINFQ4OXQ3F4TLPYXQ2RANCNFSM4HSYD7BA>
.
|
rmfonsecaweb
changed the title
|
There is not an option contributor in the base, only "develop" and "master" and then the WRF releases. The name has been updated and I think it is suggestive of what the scheme does: it adds cloud-radiation feedbacks for the BMJ cumulus scheme. Thank you!
Ricardo
On Tuesday, June 4, 2019, 6:43:14 PM GMT+4, dudhia <notifications@github.com> wrote:
Actually this should first be put on a contributor branch because we need
more formal approval
for the develop branch. I might suggest naming the branch something related
to the scheme.
Jimy
On Mon, Jun 3, 2019 at 9:48 PM Dave Gill ***@***.***> wrote:
@rmfonsecaweb <https://github.com/rmfonsecaweb>
Ricardo,
1. Change the base branch to be develop (not master). It is unlikely
that you really want to change 53 files. Just click the edit button up at
the top of this github page.
2. Update the pull request commit message (there are prompts ready to
help out). Goto #921 <#921>
3. Provide more detail than "PCC scheme" in the title.
Once you get these ironed out, then we'll be able to more seriously look
at your PR.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#921?email_source=notifications&email_token=AEIZ77DLISHWDM2JY5DXPXTPYXQ2RA5CNFSM4HSYD7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW3KPKA#issuecomment-498509736>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEIZ77C4RKINFQ4OXQ3F4TLPYXQ2RANCNFSM4HSYD7BA>
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@rmfonsecaweb You mentioned that the option can be run with and without radiation feedback, that is good. When the feedback is turned off, can you replicate the result in a standard WRF without your code? I see code changes (e.g. from CLDEFI=EFIMNSM+STEFI(1.-SM) to CLDEFI=(EFIMN-0.1)SM+(1.+0.1)(1.-SM) ) that might not allow it to go back to original BMJ, even if radiation feedback is off. |
|
Dear Reviewer,
Thank you for your e-mail. Yes, that is correct. We give the user the option of switching off/on our PCC scheme by setting the flag "bmj_rad_feedback" in the physics section of the namelist to "FALSE"/"TRUE" (the default is "FALSE"). This is similar to what is done for other cumulus scheme such as the Kain-Fritsch the reviewer mentions which use the flag "cu_rad_feedback" (-> "icloud_cu") instead. As we made clear, the PCC scheme is only coupled with the RRTM (long-wave), RRTMG (long-wave and short-wave) and RRTMG fast (long-wave and short-wave) radiation schemes. Thank you!
Regarding the line of code mentioned, please note that STEFI = 1, and the referred change, as well as the one below
+++
! CLDEFI=AVGEFI*SM+STEFI*(1.-SM)
CLDEFI=(EFIMN-0.2)*SM+(1.+0.2)*(1.-SM)
+++
does not impact at all the model results. This is done so that when the user prints out the cloud efficiency parameter, CLDEFI, he/she can know whether the deep convection scheme was called but then it was aborted because the cloud was too thin and/or no CAPE was present (line above), or whether the shallow convection scheme was called instead (the line the reviewer mentions, that is also in line 924). In other words, you can distinguish between those two cases. For those that are not interested in looking at this parameter (I would guess most of the users), these changes have no impact at all.
We would like to thank again the reviewer for taking the time to look into our codes and share with us his/her feedback. Please let us know if you have any additional concerns regarding your PCC scheme. Thank you!
Hope you have a pleasant day and a great weekend!
Best wishes,
Ricardo
On Saturday, January 25, 2020, 12:05:58 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb You mentioned that the option can be run with and without radiation feedback, that is good. When the feedback is turned off, can you replicate the result in a standard WRF without your code? I see code changes (e.g. from CLDEFI=EFIMNSM+STEFI(1.-SM) to CLDEFI=(EFIMN-0.1)SM+(1.+0.1)(1.-SM) ) that might not allow it to go back to original BMJ, even if radiation feedback is off.
In radiation code, do you see to make your changes in the radiation driver (there are examples there to deal with Kain-Fritsch, for example when cu_rad_feedback is on), rather than in each radiation scheme themselves?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@rmfonsecaweb Thanks for your reply. Can you answer the question about whether you can get identical results if you are using the same version of the code with and without your modification (but with the feedback option off)? Also what do you think of the comment about code changes in radiation? |
|
We thank the reviewer for his/her e-mail.
Regarding the first question, the answer is yes. In the tests we conducted we got the same results if we use the same version of the code with and without our PCC scheme (for the former with the feedback option switched off). When "bmj_rad_feedback" is set to false, all relevant arrays such as "QCCONV", "QICONV" and "CCLDFRA" are always set to zero, and hence there are no impacts on the radiation fields.
Regarding the second question, in the end we decided to make the changes in the radiation schemes to which the PCC scheme is coupled instead of making them in the radiation driver. Doing the latter would have meant that the user could have selected any radiation scheme, as the (qc, qi, CLDFRA) arrays would have been modified before the schemes are called. We do not want this to happen. We understand that a flag could have been used for this purpose, but we believe that making the changes in the radiation schemes themselves is more practical. After all, we are just reading in three additional arrays, so it is not a major change to the code. Having said that, we accept that this is not standard procedure, e.g. Jensen's ISMAHEL scheme is only coupled to the RRTMG radiation scheme (at least according to the description given on WRF's webpage) but the changes were made in the radiation driver. We hope the reviewer agrees with the way we changed the code in the radiation subroutines. Thank you!
On Sunday, January 26, 2020, 01:20:14 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb Thanks for your reply. Can you answer the question about whether you can get identical results if you are using the same version of the code with and without your modification (but with the feedback option off)? Also what do you think of the comment about code changes in radiation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@rmfonsecaweb Thank you for answering the first question more definitely. Regarding the second question, the reason for our question is that we'd like to keep input to radiation (such as cloud fraction, cloud mixing ratio, etc.) outside the radiation code. We will look into this a bit more. |
|
We thank the reviewer for his/her e-mail.
If the reviewer prefers to keep all input to radiation (i.e. cloud fraction, cloud mixing ratio, etc.) in the radiation driver then no problem at all, we will make that change to the codes. On the link below the reviewer can download the updated version of all relevant files. Please note that the files for the individual radiation schemes (i.e. RRTM long-wave, and RRTMG / RRTMG FAST long-wave and short-wave) are the default/original ones, as all changes are now made in the radiation driver. Thank you!
Link to download: files:https://atmospheres.research.ltu.se/owncloud/index.php/s/qEzvnTIgOOUQ5wq
If the existing files are replaced with these new ones, the model should compile as per normal and the results will be the same as before. Please let us know if you have any additional questions. Thank you!
On Monday, January 27, 2020, 04:24:30 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb Thank you for answering the first question more definitely. Regarding the second question, the reason for our question is that we'd like to keep input to radiation (such as cloud fraction, cloud mixing ratio, etc.) outside the radiation code. We will look into this a bit more.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@rmfonsecaweb I fixed a few places, and the code is now working for both ARW and NMM. @dudhia This code is ready to merge into repository. Please review. |
davegill
approved these changes
Feb 5, 2020
|
We thank the reviewer for taking the time to look into the code and fixing all lingering issues, much appreciated. We are very happy to know that the code is now working for both ARW and NMM, that is very good news. Thank you!
On Wednesday, February 5, 2020, 04:38:49 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb I fixed a few places, and the code is now working for both ARW and NMM.
@dudhia This code is ready to merge into repository. Please review.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@rmfonsecaweb You are very welcome. I'm glad too that the code is now in good shape. |
|
@rmfonsecaweb However, I just ran two tests, one with the code before your change (after PR#1063), and one with your change with bmj_rad_feedback off, the results are different. The attached plot below show the two 3 h forecast of convective rainfall from a case in US. This was the question I asked you before. We would like the results before and after your change to be the same when the new code is not activated. Can you help resolving this issue? If you find anything, please point the code to me. |
|
I believe I know what the problem is, and would like to apologize profusely for this. The "default" version of the code I used was not the *true* default version as provided on your website, but one where we corrected a bug in the BMJ scheme. This work goes back to our 2015 paper, when we looked at the code in detail and even exchanged a few e-mails with Zavisa Janjic to clarify some of the aspects of the code. I am really sorry that I did not mention this before.
The lines below
!
SUMDE=0.
SUMDP=0.
!
DO L=LTOP,LB
SUMDE=((TK(L)-TREFK(L))*CP+(QK(L)-QREFK(L))*EL(L))*DPRS(L) &
& +SUMDE
SUMDP=SUMDP+DPRS(L)
ENDDO
!
HCORR=SUMDE/(SUMDP-DPRS(LTOP))
LCOR=LTOP+1
were replaced by
SUMDE=0.
SUMDP=0.
!
DO L=LTOP,LB
SUMDE=((TK(L)-TREFK(L))*CP+(QK(L)-QREFK(L))*EL(L))*DPRS(L) &
& +SUMDE
DHDT=(QREFK(L)*A23M4L/((TREFK(L)*APEK(L)/APESK(L))-A4)**2+CP)*DPRS(L) &
& +DHDT
SUMDP=SUMDP+DPRS(L)
ENDDO
!
HCORR=SUMDE/(SUMDP-DPRS(LTOP))
DHDT=DHDT/(SUMDP-DPRS(LTOP))
LCOR=LTOP+1
and the lines below
DO L=LCOR,LB
TSKL=TREFK(L)*APEK(L)/APESK(L)
DHDT=QREFK(L)*A23M4L/(TSKL-A4)**2+CP
TREFK(L)=HCORR/DHDT+TREFK(L)
THSKL=TREFK(L)*APEK(L)
QREFK(L)=PQ0/PSK(L)*EXP(A2*(THSKL-A3*APESK(L)) &
& /(THSKL-A4*APESK(L)))
ENDDO
were replaced by
DO L=LCOR,LB
TREFK(L)=HCORR/DHDT+TREFK(L)
THSKL=TREFK(L)*APEK(L)
QREFK(L)=PQ0/PSK(L)*EXP(A2*(THSKL-A3*APESK(L)) &
& /(THSKL-A4*APESK(L)))
ENDDO
Please note the difference in the way "DHDT" is defined, it is now correctly set. Proof that our changes to DHDT are correct is given in pages #7 and 8 of the PDF below:
https://atmospheres.research.ltu.se/owncloud/index.php/s/tP6EhuPnf6nOZJQ
If the reviewer makes the referred changes to the code, the results should be the same, we have just confirmed this in a test run. Thank you!
Once again apologies for this, I should have made this clear at the beginning. If the reviewer does a diff between the original and modified "module_cu_bmj.F", the reviewer will see these differences, plus the ones related to the PCC scheme as well as the ones related to the cloud efficiency ("CLDEFI") we discussed before. Thank you!
On Wednesday, February 5, 2020, 09:12:26 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb However, I just ran two tests, one with the code before your change (after PR#1063), and one with your change with bmj_rad_feedback off, the results are different. The attached plot below show the two 3 h forecast of convective rainfall from a case in US. This was the question I asked you before. We would like the results before and after your change to be the same when the new code is not activated. Can you help resolving this issue? If you find anything, please point the code me me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Maybe we should also include this bug-fix? Can you give us more information
to justify the bug-fix.
Thanks,
Jimy
On Tue, Feb 4, 2020 at 10:36 PM rmfonsecaweb <notifications@github.com>
wrote:
… I believe I know what the problem is, and would like to apologize
profusely for this. The "default" version of the code I used was not the
true default version as provided on your website, but one where we
corrected a bug in the BMJ scheme. This work goes back to our 2015 paper,
when we looked at the code in detail and even exchanged a few e-mails with
Zavisa Janjic to clarify some of the aspects of the code. I am really sorry
that I did not mention this before.
The lines below
! SUMDE=0. SUMDP=0.! DO L=LTOP,LB
SUMDE=((TK(L)-TREFK(L))*CP+(QK(L)-QREFK(L))*EL(L))*DPRS(L) & &
+SUMDE SUMDP=SUMDP+DPRS(L) ENDDO!
HCORR=SUMDE/(SUMDP-DPRS(LTOP)) LCOR=LTOP+1
were replaced by
SUMDE=0. SUMDP=0.! DO L=LTOP,LB
SUMDE=((TK(L)-TREFK(L))*CP+(QK(L)-QREFK(L))*EL(L))*DPRS(L) & &
+SUMDE
DHDT=(QREFK(L)*A23M4L/((TREFK(L)*APEK(L)/APESK(L))-A4)**2+CP)*DPRS(L) &
& +DHDT SUMDP=SUMDP+DPRS(L) ENDDO!
HCORR=SUMDE/(SUMDP-DPRS(LTOP)) DHDT=DHDT/(SUMDP-DPRS(LTOP))
LCOR=LTOP+1
and the lines below
DO L=LCOR,LB TSKL=TREFK(L)*APEK(L)/APESK(L)
DHDT=QREFK(L)*A23M4L/(TSKL-A4)**2+CP
TREFK(L)=HCORR/DHDT+TREFK(L) THSKL=TREFK(L)*APEK(L)
QREFK(L)=PQ0/PSK(L)*EXP(A2*(THSKL-A3*APESK(L)) & &
/(THSKL-A4*APESK(L))) ENDDO
were replaced by
DO L=LCOR,LB TREFK(L)=HCORR/DHDT+TREFK(L)
THSKL=TREFK(L)*APEK(L)
QREFK(L)=PQ0/PSK(L)*EXP(A2*(THSKL-A3*APESK(L)) & &
/(THSKL-A4*APESK(L))) ENDDO
Please note the difference in the way "DHDT" is defined, it is now
correctly defined. Once again apologies for this, I should have made this
clear at the beginning. If you do a diff between the original and modified
"module_cu_bmj.F" you can see these differences, plus the ones related to
the PCC scheme as well as the modified cloud efficiency ("CLDEFI") we
discussed before. Thank you!
On Wednesday, February 5, 2020, 09:12:26 AM GMT+4, weiwangncar <
***@***.***> wrote:
@rmfonsecaweb However, I just ran two tests, one with the code before your
change (after PR#1063), and one with your change with bmj_rad_feedback off,
the results are different. The attached plot below show the two 3 h
forecast of convective rainfall from a case in US. This was the question I
asked you before. We would like the results before and after your change to
be the same when the new code is not activated. Can you help resolving this
issue? If you find anything, please point the code me me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#921?email_source=notifications&email_token=AEIZ77DHOYLTUO5P73PLKD3RBJF5DA5CNFSM4HSYD7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK2GQPY#issuecomment-582248511>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIZ77DQ5THCN73SX47LDN3RBJF5DANCNFSM4HSYD7BA>
.
|
|
It would be great if you could include this bug-fix as well. You can find the derivation of the equation for DHDT on pages #7-8 of the PDF below, DHDT is the denominator of the bottom term of equation (A18). In a nutshell, it is an integral from p_bot to p_top and not computed at every level as done in the original version of the code. Thank you!
https://atmospheres.research.ltu.se/owncloud/index.php/s/tP6EhuPnf6nOZJQ
The reference paper for this work is the one below we published back in 2015. Thank you!
https://www.geosci-model-dev.net/8/2915/2015/
Ricardo
P.S.: Due to the time difference between yours and mine time zone, I will not check my e-mails for the next couple of hours. Thank you for your understanding. Thank you!
On Wednesday, February 5, 2020, 8:22:14 PM GMT+4, dudhia <notifications@github.com> wrote:
Maybe we should also include this bug-fix? Can you give us more information
to justify the bug-fix.
Thanks,
Jimy
On Tue, Feb 4, 2020 at 10:36 PM rmfonsecaweb <notifications@github.com>
wrote:
I believe I know what the problem is, and would like to apologize
profusely for this. The "default" version of the code I used was not the
true default version as provided on your website, but one where we
corrected a bug in the BMJ scheme. This work goes back to our 2015 paper,
when we looked at the code in detail and even exchanged a few e-mails with
Zavisa Janjic to clarify some of the aspects of the code. I am really sorry
that I did not mention this before.
The lines below
! SUMDE=0. SUMDP=0.! DO L=LTOP,LB
SUMDE=((TK(L)-TREFK(L))*CP+(QK(L)-QREFK(L))*EL(L))*DPRS(L) & &
+SUMDE SUMDP=SUMDP+DPRS(L) ENDDO!
HCORR=SUMDE/(SUMDP-DPRS(LTOP)) LCOR=LTOP+1
were replaced by
SUMDE=0. SUMDP=0.! DO L=LTOP,LB
SUMDE=((TK(L)-TREFK(L))*CP+(QK(L)-QREFK(L))*EL(L))*DPRS(L) & &
+SUMDE
DHDT=(QREFK(L)*A23M4L/((TREFK(L)*APEK(L)/APESK(L))-A4)**2+CP)*DPRS(L) &
& +DHDT SUMDP=SUMDP+DPRS(L) ENDDO!
HCORR=SUMDE/(SUMDP-DPRS(LTOP)) DHDT=DHDT/(SUMDP-DPRS(LTOP))
LCOR=LTOP+1
and the lines below
DO L=LCOR,LB TSKL=TREFK(L)*APEK(L)/APESK(L)
DHDT=QREFK(L)*A23M4L/(TSKL-A4)**2+CP
TREFK(L)=HCORR/DHDT+TREFK(L) THSKL=TREFK(L)*APEK(L)
QREFK(L)=PQ0/PSK(L)*EXP(A2*(THSKL-A3*APESK(L)) & &
/(THSKL-A4*APESK(L))) ENDDO
were replaced by
DO L=LCOR,LB TREFK(L)=HCORR/DHDT+TREFK(L)
THSKL=TREFK(L)*APEK(L)
QREFK(L)=PQ0/PSK(L)*EXP(A2*(THSKL-A3*APESK(L)) & &
/(THSKL-A4*APESK(L))) ENDDO
Please note the difference in the way "DHDT" is defined, it is now
correctly defined. Once again apologies for this, I should have made this
clear at the beginning. If you do a diff between the original and modified
"module_cu_bmj.F" you can see these differences, plus the ones related to
the PCC scheme as well as the modified cloud efficiency ("CLDEFI") we
discussed before. Thank you!
On Wednesday, February 5, 2020, 09:12:26 AM GMT+4, weiwangncar <
***@***.***> wrote:
@rmfonsecaweb However, I just ran two tests, one with the code before your
change (after PR#1063), and one with your change with bmj_rad_feedback off,
the results are different. The attached plot below show the two 3 h
forecast of convective rainfall from a case in US. This was the question I
asked you before. We would like the results before and after your change to
be the same when the new code is not activated. Can you help resolving this
issue? If you find anything, please point the code me me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#921?email_source=notifications&email_token=AEIZ77DHOYLTUO5P73PLKD3RBJF5DA5CNFSM4HSYD7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK2GQPY#issuecomment-582248511>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIZ77DQ5THCN73SX47LDN3RBJF5DANCNFSM4HSYD7BA>
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@rmfonsecaweb I just made a separate PR to capture the bug fix you put in without the PCC change. Please review PR#1074 to see if the code is correct. I suspect there is still something I missed since I'm not getting the same results even with these changes added to the run I'm trying to compare with. |
|
We thank the reviewer for his/her comment and for the time and effort spent conducting sensitivity simulations and generating a new PR. Thank you!
Indeed, we have looked at the actual convective precipitation numbers and there are very small (but non-negligible) differences between a simulation with the default WRF version and one with our modified version with the flag "bmj_rad_feedback" set to FALSE. We have performed many tests and we believe we found the reason why. First, this difference only affects the convective precipitation. All other fields (including the radiation fields) are the same, so the problem must lie somewhere in the file "module_cu_bmj.F". It is unlikely to come from the arrays "QCCONV", "QICONV", "CCLDFRA", "CONVCLD" as they are all set to zero. In addition, and as highlighted before, the changes made to the cloud efficiency ("CLDEFI") have no impact at all in the model forecasts. So what can be wrong?
Well, we started from the default version with the aforementioned bug corrected and found something intriguing. Let's take this version as the control, and compare the RAINC with that given by WRF when two additional changes are made to "module_cu_bmj.F":
(1) The arrays "PVPR" and "JPR" are defined. This is done by adding the line
REAL,DIMENSION(KTS:KTE) :: PVPR,JPR
below the line
REAL,DIMENSION(KTS:KTE) :: DPCOL,DQDT,DTDT,PCOL,QCOL,TCOL
(2) Initialize these two arrays to zero. This is done by replacing
DO K=KTS,KTE
DQDT(K)=0.
DTDT(K)=0.
ENDDO
with
DO K=KTS,KTE
DQDT(K)=0.
DTDT(K)=0.
JPR(K)=0.
PVPR(K)=0.
ENDDO
When we compare the convective precipitation given by these two simulations we find differences in the range -0.2 to +0.1, comparable in magnitude to the differences reported by the reviewer. If (2) is not done the results are the same as in the control simulation. For some reason, initializing these two arrays leads to very small (but non-negligible) differences in the model-predicted convective rainfall.
The other local arrays we define are scalars and, from the experiments we conducted, they do not impact the model performance. It is these one-dimensional arrays that are causing the differences.
Initializing the two arrays in a separate K-loop does not solve the problem. If only one variable is initialized, the differences are not exactly the same as when the two are initialized but are of a comparable magnitude. Changing the name of the variables also does not help. Any ideas on why this may be happening? Other variables like "DQDT" and "DTDT" are defined in the same way.
The thing is, we need these arrays for the PCC scheme so we cannot delete them in the modified version. The difference plot the reviewer shows contains both positive and negative values, I guess of a much smaller magnitude than the actual precipitation. It could be regarded as noise but we still need to understand why the changes mentioned above are causing it.
+++++++
We have performed some more tests. Could this be related to the compiler used? We have tried two compilation options: IFORT DMPAR (15) and GFORTRAN SERIAL (32). With the latter this issue is present, but with the former it is not, even when running with just one processor. However, this does not seem to fix the full problem: when comparing the default WRF version with the changes above with the modified one with "bmj_rad_feedback" switched to FALSE, there are still differences, even though of a slightly smaller magnitude. If the reviewer has any ideas we would be interested to hear them. In the meantime, we will be giving it some more thought. Thank you!
On Thursday, February 6, 2020, 03:51:32 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb I just made a separate PR to capture the bug fix you put in without the PCC change. Please review PR#1074 to see if the code is correct. I suspect there is still something I missed since I'm not getting the same results even with these changes added to the run I'm trying to compare with.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@rmfonsecaweb There is no need to keep merging your code with develop branch. Github will check whether the code can be merged, and will let us know when the code is finally merged. Mistake can be easily made if the merging is not done properly, and not done using right git commands. I had to deal with this a few times. So be careful when you merge. Always check the changed files to see if those differences are those you made after push up a new commit. For example, after your latest merge, there is a new section of code in module_radiation_driver.F (new lines 64-76) that I don't think are any change related to your PCC code. If you copy over an old copy of module_radiation_driver.F over the newly clone WRF code, git may think some differences are intended changes. |
|
We thank the reviewer for his/her comment. Noted with thanks. There was a message regarding potential conflicts, so I just moved a portion of our code above the new entries. I was careful to do it properly and will be even more careful in the future. The thing is, if you do not resolve the conflicts and make additional changes to your code, the Jenkins' test cannot run. In any case, we thank the reviewer for raising this issue. Thank you!
On Friday, February 7, 2020, 7:47:27 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb There is no need to keep merging your code with develop branch. Github will check whether the code can be merged, and will let us know when the code is finally merged. Mistake can be easily made if the merging is not done properly, and not done using right git commands. I had to deal with this a few times. So be careful when you merge. Always check the changed files to see if those differences are those you made after push up a new commit. For example, after your latest merge, there is a new section of code in module_radiation_driver.F (new lines 64-76) that I don't think are any change related to your PCC code. If you copy over an old copy of module_radiation_driver.F over the newly clone WRF code, git may think some differences are intended changes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
We would like to thank the reviewer for removing the CLDEFI changes and for lining up the code. It looks good now. We are happy to know that the issue of the discrepancy between the model-predicted convective precipitation between the simulations with the PCC scheme with the flag "bmj_rad_feedback" set to FALSE and without the PCC scheme has been resolved. Thank you! |
… qc_save, qi_save, and recovered later in the driver
|
@rmfonsecaweb I've added two other changes: 1. removed the four new variables from history output - they can be added by any user who is interested in these variables; 2. removed arrays qc_old and qi_old in radiation driver. The two fields have already been saved to qc_save and qi_save before cloud fraction is computed and recovered later in the driver. Hope you're ok with both changes. |
|
We once again thank the reviewer for the time taken to work on this.
Regarding change no. 1, we agree. After all, most users are not interested in those variables anyway, and those who are can manually modify the Registry file to output them.
Regarding change no. 2, it is fine as well. No need to have duplicate arrays that serve the same purpose.
Thank you!!!
On Tuesday, February 11, 2020, 01:53:18 AM GMT+4, weiwangncar <notifications@github.com> wrote:
@rmfonsecaweb I've added two other changes: 1. removed the four new variables from history output - they can be added by any user who is interested in these variables; 2. removed arrays qc_old and qi_old in radiation driver. The two fields have already been saved to qc_save and qi_save before cloud fraction is computed and recovered later in the driver. Hope you're ok with both changes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TYPE: New Feature
KEYWORDS: PCC scheme, BMJ cumulus scheme
SOURCE: Tieh-Yong Koh (Earth Observatory of Singapore, Nanyang Technological University, Singapore); Ricardo Fonseca (Earth Observatory of Singapore, Nanyang Technological University, Singapore); Chee-Kiat Teo (Temasek Laboratories, Nanyang Technological University, Singapore); Tengfei Zhang (Earth Observatory of Singapore, Nanyang Technological University, Singapore)
DESCRIPTION OF CHANGES: We have added to the BMJ cumulus scheme a Precipitating Convective Cloud (PCC) scheme that accounts for sub-grid cloud interaction with radiation. The parameterization scheme is presented in the paper below. For it to be switched on, the flag "bmj_rad_feedback" in the physics section of the namelist has to be set to true. In other words, the user can run WRF with the BMJ scheme and with or without our proposed PCC scheme.
+++
Koh, T.-Y. and R. Fonseca (2016), "Subgrid-scale cloud-radiation feedback for the Betts-Miller-Janjic convection scheme", Quarterly Journal of the Royal Meteorological Society, 142(695), 989-1006. doi: 10.1002/qj.2702
+++
LIST OF MODIFIED FILES:
Registry/Registry.EM_COMMON
Registry/Registry.NMM
dyn_em/start_em.F (code line-up only)
dyn_em/module_first_rk_step_part1.F
dyn_nmm/module_PHYSICS_CALLS.F
phys/module_physics_init.F (code line-up only)
phys/module_cumulus_driver.F
phys/module_cu_bmj.F
phys/module_radiation_driver.F
TESTS CONDUCTED:
For tropical applications, we recommend this PCC to be used with the WDM5, WDM6 or WDM7 cloud microphysics schemes, and with the RRTMG / RRTMG fast radiation scheme. The BMJ scheme should also be modified according to paper 3 below by reducing the "Fs" parameter from its default value of 0.85 to 0.6 so that it produces a good estimate of the observed tropical precipitation on pentad time-scales as given by the TRMM satellite data.
+++
Paper 1:
Koh, T.-Y. and R. Fonseca (2016), "Subgrid-scale cloud-radiation feedback for the Betts-Miller-Janjic convection scheme", Quarterly Journal of the Royal Meteorological Society, 142(695), 989-1006. doi: 10.1002/qj.2702
Paper 2:
Fonseca, R., T.-Y. Koh and C.-K. Teo (2018), "Multi-scale interactions in a high-resolution tropical-belt experiment and observations", Climate Dynamics, in press. DOI: 10.1007/s00382-018-4332-y
Paper 3:
R. M. Fonseca, T. Zhang and K. T. Yong (2015), "Improved simulation of precipitation in the tropics using a modified BMJ scheme in the WRF model", Geosci. Model Dev., 8, 2915-2928, doi:10.5194/gmd-8-2915-2015
These papers can be downloaded on the website below:
https://isotope.suss.edu.sg/stade/tykoh/publication.htm
+++
Release Note: A capability to add BMJ cumulus feedback to radiation is added and activated by namelist option bmj_rad_feedback option. See the following paper for science details: Koh, T.-Y. and R. Fonseca (2016), "Subgrid-scale cloud-radiation feedback for the Betts-Miller-Janjic convection scheme", Quarterly Journal of the Royal Meteorological Society, 142(695), 989-1006. doi: 10.1002/qj.2702.