Final-final GFS v16 updates #531
Merged
Conversation
This file contains 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
This was referenced Dec 10, 2020
Thanks for the clarification, Fanglin. I changed the description. Want to make sure that those who did the work get the credit. |
climbfuji
requested review from
grantfirl,
JulieSchramm and
llpcarson
as code owners
SMoorthi-emc
approved these changes
Dec 11, 2020
|
Dom, thanks for doing the tests. I tried to submit some jobs on hera, they
are still waiting in the queue. It's good to confirm that the line does not
have any impact (if it does, it indicates error in flag_cice). So for this
purpose, can we remove the line so that people won't get confused with it?
…On Thu, Dec 10, 2020 at 10:56 PM Dom Heinzeller ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In physics/GFS_surface_composites.F90
<#531 (comment)>:
> @@ -571,6 +571,7 @@ subroutine GFS_surface_composites_post_run (
snowd(i) = snowd_ice(i)
!tprcp(i) = cice(i)*tprcp_ice(i) + (one-cice(i))*tprcp_wat(i)
qss(i) = qss_ice(i)
+ tsfc(i) = tsfc_ice(i)
This change was not in Shan's PR from last week.
I did some tests using @yangfanglin <https://github.com/yangfanglin>'s
C768 testcase and the C96 GFS v16 regression test (both uncoupled, binary
landmask), and that line doesn't make any difference - as we expected,
because one of the following if statements is always true and tsfc gets
updated again.
So the question comes down to whether that line is still needed for the
coupled model run using binary landmask. Can this combination happen?
islmsk/={0,1}, flag_cice=.true. and wet=.false.. If so, then we need to
have this new line, otherwise tsfc will not get updated.
Given that the line doesn't hurt at all, I am inclined to leave it there
if in doubt.
@shansun6 <https://github.com/shansun6> @SMoorthi-emc
<https://github.com/SMoorthi-emc> @yangfanglin
<https://github.com/yangfanglin> @yunwang-noaa
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TME2BYVR2VBASFATI3SUGJ67ANCNFSM4UVSKU6A>
.
|
ShanSunNOAA
approved these changes
Dec 11, 2020
|
Exactly. That is why it is there!
…On Thu, Dec 10, 2020 at 11:56 PM shansun6 ***@***.***> wrote:
***@***.**** approved this pull request.
Nice job. I approve.
------------------------------
In physics/GFS_surface_composites.F90
<#531 (comment)>:
> @@ -571,6 +571,7 @@ subroutine GFS_surface_composites_post_run (
snowd(i) = snowd_ice(i)
!tprcp(i) = cice(i)*tprcp_ice(i) + (one-cice(i))*tprcp_wat(i)
qss(i) = qss_ice(i)
+ tsfc(i) = tsfc_ice(i)
If the coupled model uses non fractional landmask, at a point with 50% sea
ice, flag_cice=T and wet=T. tsfc will be (ice temp+water temp)/2.
I am still puzzled by this line made a difference - all the following if
must be false. I agree with Dom that it won't hurt for now.
------------------------------
In physics/GFS_surface_composites.F90
<#531 (comment)>:
> @@ -571,6 +571,7 @@ subroutine GFS_surface_composites_post_run (
snowd(i) = snowd_ice(i)
!tprcp(i) = cice(i)*tprcp_ice(i) + (one-cice(i))*tprcp_wat(i)
qss(i) = qss_ice(i)
+ tsfc(i) = tsfc_ice(i)
I got one scenario that Line 574 is crucial:
if flag_cice=T with 100% sea ice, which means wet=F, then neither Line 579
(if .not. flag_cice) nor Line 583 (elseif wet) is true. In this case tsfc
will not be updated without Line 574.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALLVRYUWGAURUK4ASW3WDS3SUGRBHANCNFSM4UVSKU6A>
.
--
Dr. Shrinivas Moorthi
Research Meteorologist
Modeling and Data Assimilation Branch
Environmental Modeling Center / National Centers for Environmental
Prediction
5830 University Research Court - (W/NP23), College Park MD 20740 USA
Tel: (301)683-3718
e-mail: [email protected]
Phone: (301) 683-3718 Fax: (301) 683-3718
|
|
Well, I see now it exactly causes confusion. Please see Dom's comments:
that line *doesn't *make any difference - as we expected, because one of
the following if statements is always true and tsfc gets updated again. So
the model works the same without that line. I am not sure if we finished
all RT yet, if we do, I still suggest removing it in next commit to avoid
confusion.
On Fri, Dec 11, 2020 at 7:32 AM SMoorthi-emc <[email protected]>
wrote:
… Exactly. That is why it is there!
On Thu, Dec 10, 2020 at 11:56 PM shansun6 ***@***.***>
wrote:
> ***@***.**** approved this pull request.
>
> Nice job. I approve.
> ------------------------------
>
> In physics/GFS_surface_composites.F90
> <#531 (comment)>:
>
> > @@ -571,6 +571,7 @@ subroutine GFS_surface_composites_post_run (
> snowd(i) = snowd_ice(i)
> !tprcp(i) = cice(i)*tprcp_ice(i) + (one-cice(i))*tprcp_wat(i)
> qss(i) = qss_ice(i)
> + tsfc(i) = tsfc_ice(i)
>
> If the coupled model uses non fractional landmask, at a point with 50%
sea
> ice, flag_cice=T and wet=T. tsfc will be (ice temp+water temp)/2.
>
> I am still puzzled by this line made a difference - all the following if
> must be false. I agree with Dom that it won't hurt for now.
> ------------------------------
>
> In physics/GFS_surface_composites.F90
> <#531 (comment)>:
>
> > @@ -571,6 +571,7 @@ subroutine GFS_surface_composites_post_run (
> snowd(i) = snowd_ice(i)
> !tprcp(i) = cice(i)*tprcp_ice(i) + (one-cice(i))*tprcp_wat(i)
> qss(i) = qss_ice(i)
> + tsfc(i) = tsfc_ice(i)
>
> I got one scenario that Line 574 is crucial:
> if flag_cice=T with 100% sea ice, which means wet=F, then neither Line
579
> (if .not. flag_cice) nor Line 583 (elseif wet) is true. In this case tsfc
> will not be updated without Line 574.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#531 (review)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ALLVRYUWGAURUK4ASW3WDS3SUGRBHANCNFSM4UVSKU6A
>
> .
>
--
Dr. Shrinivas Moorthi
Research Meteorologist
Modeling and Data Assimilation Branch
Environmental Modeling Center / National Centers for Environmental
Prediction
5830 University Research Court - (W/NP23), College Park MD 20740 USA
Tel: (301)683-3718
e-mail: ***@***.***
Phone: (301) 683-3718 Fax: (301) 683-3718
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TIXSZQ23EI62QGLZ73SUIGL7ANCNFSM4UVSKU6A>
.
|
Jun, I think Moorthi and Shan are correct. This is what Shan said and what Moorthi confirmed:
Therefore we this line or something equivalent is needed. I am suggesting the following instead of the newly added line, which does the same but is hopefully less confusing. See commit c7cae7d. This commit also removes a duplicate assignment (there were two identical lines, just three lines apart) |
|
Well, the logic in my new branch is
```
hflx(i) = hflx_ice(i)
qss(i) = qss_ice(i)
tisfc(i) = tice(i) ! over lake ice (and sea ice when
uncoupled)
tsfc(i) = tsfc_ice(i) ! over lake (and ocean when uncoupled)
!
if (flag_cice(i)) then
if (wet(i) .and. cice(i) >= min_seaice) then ! this was
already done for lake ice in sfc_sice
txi = cice(i)
txo = one - txi
evap(i) = txi * evap_ice(i) + txo * evap_wat(i)
hflx(i) = txi * hflx_ice(i) + txo * hflx_wat(i)
tsfc(i) = txi * tsfc_ice(i) + txo * tsfc_wat(i)
stress(i) = txi * stress_ice(i) + txo * stress_wat(i)
qss(i) = txi * qss_ice(i) + txo * qss_wat(i)
ep1d(i) = txi * ep1d_ice(i) + txo * ep1d_wat(i)
zorl(i) = txi * zorl_ice(i) + txo * zorl_wat(i)
snowd(i) = txi * snowd_ice(i)
endif
elseif (wet(i)) then ! return updated lake ice thickness &
concentration to global array
zorl(i) = cice(i)*zorl_ice(i) + (one-cice(i))*zorl_wat(i)
endif
!
if (wet(i)) then
tsfco(i) = tsfc_wat(i)
else
tsfco(i) = tsfc(i)
endif
tsfcl(i) = tsfc(i)
do k=1,kice ! store tiice in stc to reduce output in the
nonfrac grid case
stc(i,k) = tiice(i,k)
enddo
endif
zorll(i) = zorl_lnd(i)
zorlo(i) = zorl_wat(i)
zorli(i) = zorl_ice(i)
enddo
endif ! if (frac_grid)
```
which is how I am staying with.
Moorthi
On Fri, Dec 11, 2020 at 8:48 AM Dom Heinzeller <[email protected]>
wrote:
… Well, I see now it exactly causes confusion. Please see Dom's comments:
that line *doesn't *make any difference - as we expected, because one of
the following if statements is always true and tsfc gets updated again. So
the model works the same without that line. I am not sure if we finished
all RT yet, if we do, I still suggest removing it in next commit to avoid
confusion. On Fri, Dec 11, 2020 at 7:32 AM SMoorthi-emc
***@***.*** wrote:
… <#m_5809722388496818073_>
Jun, I think Moorthi and Shan are correct. This is what Shan said and what
Moorthi confirmed:
I got one scenario that Line 574 is crucial:
if flag_cice=T with 100% sea ice, which means wet=F, then neither Line 579
(if .not. flag_cice) nor Line 583 (elseif wet) is true. In this case tsfc
will not be updated without Line 574.
Therefore we this line or something equivalent is needed. I am suggesting
the following instead of the newly added line, which does the same but is
hopefully less confusing. See commit c7cae7d
<c7cae7d>.
This commit also removes a duplicate assignment
qss(i) = qss_ice(i)
(there were two identical lines, just three lines apart)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALLVRYSUWLPRWPO2ORWJFTTSUIPJ3ANCNFSM4UVSKU6A>
.
--
Dr. Shrinivas Moorthi
Research Meteorologist
Modeling and Data Assimilation Branch
Environmental Modeling Center / National Centers for Environmental
Prediction
5830 University Research Court - (W/NP23), College Park MD 20740 USA
Tel: (301)683-3718
e-mail: [email protected]
Phone: (301) 683-3718 Fax: (301) 683-3718
|
Moorthi, I am not sure what to do with this. We want to make sure that the logic that the additional line 574 (or the equivalent) produces goes into this PR to create the reference tag for the GFS v16 production code, so that we can move on to GFS v17 development without being held up by trying to find a version that reproduces GFS v16. Forgive me if I am getting this wrong. If you have additional changes in your logic, then it's great if we can get those in after we created the GFS v16 reference tag in my opinion. |
|
If I have to choose, 196603c
<196603c>
.
I prefer not making the one line change. If the condition of updating tsfc
for flag_cice=100% has to be done here, we should see the coupled model
results change. Also we should see the tsfc has never been updated on 100%
ice region in coupled model, my understanding is not the case, maybe I'm
wrong. So before we figure out all the details, I think we can take 196603c
for now.
…On Fri, Dec 11, 2020 at 9:00 AM Dom Heinzeller ***@***.***> wrote:
So, everyone, can I ask you to please choose between the version in commit
196603c
<196603c>
and in commit c7cae7d
<c7cae7d>
so that we can put this to bed? Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TKZG4ITZ2V7YBDCY5DSUIQXBANCNFSM4UVSKU6A>
.
|
|
I am abstaining from voting this time☺
…On Fri, Dec 11, 2020 at 9:14 AM Jun Wang ***@***.***> wrote:
If I have to choose, 196603c
<
196603c
>
.
I prefer not making the one line change. If the condition of updating tsfc
for flag_cice=100% has to be done here, we should see the coupled model
results change. Also we should see the tsfc has never been updated on 100%
ice region in coupled model, my understanding is not the case, maybe I'm
wrong. So before we figure out all the details, I think we can take 196603c
for now.
On Fri, Dec 11, 2020 at 9:00 AM Dom Heinzeller ***@***.***>
wrote:
> So, everyone, can I ask you to please choose between the version in
commit
> 196603c
> <
196603c
>
> and in commit c7cae7d
> <
c7cae7d
>
> so that we can put this to bed? Thank you.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#531 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AI7D6TKZG4ITZ2V7YBDCY5DSUIQXBANCNFSM4UVSKU6A
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALLVRYVGSZ2JVQA7DN4GUW3SUISL7ANCNFSM4UVSKU6A>
.
--
Dr. Shrinivas Moorthi
Research Meteorologist
Modeling and Data Assimilation Branch
Environmental Modeling Center / National Centers for Environmental
Prediction
5830 University Research Court - (W/NP23), College Park MD 20740 USA
Tel: (301)683-3718
e-mail: [email protected]
Phone: (301) 683-3718 Fax: (301) 683-3718
|
climbfuji
force-pushed
the
final_gfsv16_changes
branch
from
c7cae7d
to
0144a5f
Compare
|
Ok, agree with @junwang-noaa to use the version from 196603c. It's closer to what we want to move to (Moorthi's code) in the future anyway. |
|
Too late to vote? I'd go with c7cae7d, as the coupled model needs to update
tsfc in this particular scenario and the 8 35-day runs I did earlier have
flaws. I'd volunteer to repeat these 8 cases over the weekend with this new
code, and compare with the earlier "flawed" experiments. There will be
changes but for the right reason.
However, for Fanglin's case in the standalone FV3, since this line made a
difference, it indicates flag_cice must be true. Why is flag_cice true in
the standalone FV3? Am I missing something?
Shan
…On Fri, Dec 11, 2020 at 7:21 AM Dom Heinzeller ***@***.***> wrote:
Ok, agree with @junwang-noaa <https://github.com/junwang-noaa> to use the
version from 196603c
<196603c>.
It's closer to what we want to move to (Moorthi's code) in the future
anyway.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVULGZRLFQCX7WA4U4LSUITGNANCNFSM4UVSKU6A>
.
|
|
Shan, It's good if you can confirm if the tsfc has never been updated on
100% ice region in coupled 35 days run. Second, for standalone FV3, that
line does NOT make a difference.
…On Fri, Dec 11, 2020 at 10:44 AM shansun6 ***@***.***> wrote:
Too late to vote? I'd go with c7cae7d, as the coupled model needs to update
tsfc in this particular scenario and the 8 35-day runs I did earlier have
flaws. I'd volunteer to repeat these 8 cases over the weekend with this new
code, and compare with the earlier "flawed" experiments. There will be
changes but for the right reason.
However, for Fanglin's case in the standalone FV3, since this line made a
difference, it indicates flag_cice must be true. Why is flag_cice true in
the standalone FV3? Am I missing something?
Shan
On Fri, Dec 11, 2020 at 7:21 AM Dom Heinzeller ***@***.***>
wrote:
> Ok, agree with @junwang-noaa <https://github.com/junwang-noaa> to use
the
> version from 196603c
> <
196603c
>.
> It's closer to what we want to move to (Moorthi's code) in the future
> anyway.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#531 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ALORMVULGZRLFQCX7WA4U4LSUITGNANCNFSM4UVSKU6A
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TK7QMQCXKBCU3YKSYLSUI43XANCNFSM4UVSKU6A>
.
|
|
Thanks for your info. I will start the 8 cases of 35-day integration soon.
-Shan
…On Fri, Dec 11, 2020 at 9:52 AM Jun Wang ***@***.***> wrote:
Shan, It's good if you can confirm if the tsfc has never been updated on
100% ice region in coupled 35 days run. Second, for standalone FV3, that
line does NOT make a difference.
On Fri, Dec 11, 2020 at 10:44 AM shansun6 ***@***.***>
wrote:
> Too late to vote? I'd go with c7cae7d, as the coupled model needs to
update
> tsfc in this particular scenario and the 8 35-day runs I did earlier have
> flaws. I'd volunteer to repeat these 8 cases over the weekend with this
new
> code, and compare with the earlier "flawed" experiments. There will be
> changes but for the right reason.
>
> However, for Fanglin's case in the standalone FV3, since this line made a
> difference, it indicates flag_cice must be true. Why is flag_cice true in
> the standalone FV3? Am I missing something?
>
> Shan
>
> On Fri, Dec 11, 2020 at 7:21 AM Dom Heinzeller ***@***.***
>
> wrote:
>
> > Ok, agree with @junwang-noaa <https://github.com/junwang-noaa> to use
> the
> > version from 196603c
> > <
>
196603c
> >.
> > It's closer to what we want to move to (Moorthi's code) in the future
> > anyway.
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#531 (comment)
>,
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/ALORMVULGZRLFQCX7WA4U4LSUITGNANCNFSM4UVSKU6A
> >
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#531 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AI7D6TK7QMQCXKBCU3YKSYLSUI43XANCNFSM4UVSKU6A
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVWK5IAW7J7BTRYS55TSUJE5JANCNFSM4UVSKU6A>
.
|
|
I ran a test last night and also found, as Dom noted, that one line did not
make any differences in standard alone atmos case.
Fanglin
On Fri, Dec 11, 2020 at 11:52 AM Jun Wang ***@***.***> wrote:
Shan, It's good if you can confirm if the tsfc has never been updated on
100% ice region in coupled 35 days run. Second, for standalone FV3, that
line does NOT make a difference.
On Fri, Dec 11, 2020 at 10:44 AM shansun6 ***@***.***>
wrote:
> Too late to vote? I'd go with c7cae7d, as the coupled model needs to
update
> tsfc in this particular scenario and the 8 35-day runs I did earlier have
> flaws. I'd volunteer to repeat these 8 cases over the weekend with this
new
> code, and compare with the earlier "flawed" experiments. There will be
> changes but for the right reason.
>
> However, for Fanglin's case in the standalone FV3, since this line made a
> difference, it indicates flag_cice must be true. Why is flag_cice true in
> the standalone FV3? Am I missing something?
>
> Shan
>
> On Fri, Dec 11, 2020 at 7:21 AM Dom Heinzeller ***@***.***
>
> wrote:
>
> > Ok, agree with @junwang-noaa <https://github.com/junwang-noaa> to use
> the
> > version from 196603c
> > <
>
196603c
> >.
> > It's closer to what we want to move to (Moorthi's code) in the future
> > anyway.
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#531 (comment)
>,
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/ALORMVULGZRLFQCX7WA4U4LSUITGNANCNFSM4UVSKU6A
> >
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#531 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AI7D6TK7QMQCXKBCU3YKSYLSUI43XANCNFSM4UVSKU6A
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKY5N2PBW7RPCUJLA2HX67DSUJE5JANCNFSM4UVSKU6A>
.
--
*Fanglin Yang, Ph.D.*
*Chief, Model Physics Group*
*Modeling and Data Assimilation Branch*
*NOAA/NWS/NCEP Environmental Modeling Center*
*https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/
<https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*
|
|
Hi Fanglin,
Thanks for confirming that. I don't have more questions on this,
Shan
On Fri, Dec 11, 2020 at 10:00 AM Fanglin Yang <[email protected]>
wrote:
… I ran a test last night and also found, as Dom noted, that one line did not
make any differences in standard alone atmos case.
Fanglin
On Fri, Dec 11, 2020 at 11:52 AM Jun Wang ***@***.***>
wrote:
> Shan, It's good if you can confirm if the tsfc has never been updated on
> 100% ice region in coupled 35 days run. Second, for standalone FV3, that
> line does NOT make a difference.
>
> On Fri, Dec 11, 2020 at 10:44 AM shansun6 ***@***.***>
> wrote:
>
> > Too late to vote? I'd go with c7cae7d, as the coupled model needs to
> update
> > tsfc in this particular scenario and the 8 35-day runs I did earlier
have
> > flaws. I'd volunteer to repeat these 8 cases over the weekend with this
> new
> > code, and compare with the earlier "flawed" experiments. There will be
> > changes but for the right reason.
> >
> > However, for Fanglin's case in the standalone FV3, since this line
made a
> > difference, it indicates flag_cice must be true. Why is flag_cice true
in
> > the standalone FV3? Am I missing something?
> >
> > Shan
> >
> > On Fri, Dec 11, 2020 at 7:21 AM Dom Heinzeller <
***@***.***
> >
> > wrote:
> >
> > > Ok, agree with @junwang-noaa <https://github.com/junwang-noaa> to
use
> > the
> > > version from 196603c
> > > <
> >
>
196603c
> > >.
> > > It's closer to what we want to move to (Moorthi's code) in the future
> > > anyway.
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub
> > > <
#531 (comment)
> >,
> > > or unsubscribe
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ALORMVULGZRLFQCX7WA4U4LSUITGNANCNFSM4UVSKU6A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#531 (comment)
>,
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/AI7D6TK7QMQCXKBCU3YKSYLSUI43XANCNFSM4UVSKU6A
> >
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#531 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AKY5N2PBW7RPCUJLA2HX67DSUJE5JANCNFSM4UVSKU6A
>
> .
>
--
*Fanglin Yang, Ph.D.*
*Chief, Model Physics Group*
*Modeling and Data Assimilation Branch*
*NOAA/NWS/NCEP Environmental Modeling Center*
*https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/
<https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#531 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVVX33GBRRFE3QMXSZLSUJF3ZANCNFSM4UVSKU6A>
.
|
…nal_gfsv16_changes
HelinWei-NOAA
pushed a commit
to HelinWei-NOAA/ccpp-physics
that referenced
this pull request
Feb 26, 2023
The current logic in CCPP_driver does not allow for buckets to be emptied every time-step. This one-line modification fixes that.
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.
This PR:
adds a one-line change to
GFS_surface_composites.F90that allows us to reproduce the GFS v16 behavior so that the code can serve as reference for the GFS v17 development - contributed by @junwang-noaa and @yangfanglinfixes a small bug in
GFS_debug.F90(not used by any of the suites by default, but useful for debugging), becausezsis no longer inGFS_sfcpropbut inGFS_controlAssociated PRs:
#531
NOAA-EMC/fv3atm#212
ufs-community/ufs-weather-model#325
For regression testing, see ufs-community/ufs-weather-model#325