Possibility to insert initial clouds into cold-start

[gthompsnWRF]

TYPE: new feature

KEYWORDS: cloud fraction, cloud initialization

SOURCE: Greg Thompson (JCSDA)

DESCRIPTION OF CHANGES:
Problem:
Cold start simulations without microphysics species take significant time to 'spin-up' the clouds causing the radiation
to be way off balance at the start of most model simulations. This greatly affects the first few hours up to 12 hours
or more.

Solution:
The setting of initial cloud fraction and associated cloud water/ice mixing ratio gives a big advantage to 'spin up'
the clouds by assuming that clouds can be created from conditions of very high relative humidity. The cloud fraction
scheme of icloud=3 is a viable solution to making initial clouds along with the setting of the water vapor mixing ratio
to the point of saturation at initialization in association with the inserted cloud fields.

LIST OF MODIFIED FILES:
M Registry/Registry.EM_COMMON
M dyn_em/module_initialize_real.F
M dyn_em/depend.dyn_em
M run/README.namelist

TESTS CONDUCTED:

1. Numerous simulations in case studies plus real-time simulations with 3km spacing (nearly HRRR-CONUS) in
   support of FAA's ICICLE field project (2019Jan28-2019Mar08).
2. Simulations by P. Jimenez in testing WRF-Solar-V2
3. Jenkins is pass.

RELEASE NOTE: In combination with updates to the cloud fraction scheme (icloud=3), a new feature permits the usage of the cloud fraction scheme as part of real.exe, specifically designed to use with "cold start" simulations to reduce the spin-up problem of clouds and associated radiation.

[gthompsnWRF]

This PR is a replacement for #1323 which I decided to close because it had the complexity of being based from an earlier code version. I already reported that it had negligible additional run time in real.exe compared to skipping the option. I am just trying to get this approval moving forward with a clean starting point of v4.2.2 as the base in the develop branch. Contact me for any questions. I am trying to dis-entangle multiple PRs into more tiny chunks from here onwards.

[davegill]

jenkins:

Please find result of the WRF regression test cases in the attachment. This build is for Commit ID: 19790ec3e234ebb296e6992a8f5f4a19ea5061a4, requested by: gthompsnWRF for PR: https://github.com/wrf-model/WRF/pull/1388. For any query please send e-mail to David Gill.

    Test Type              | Expected  | Received |  Failed
    = = = = = = = = = = = = = = = = = = = = = = = =  = = = =
    Number of Tests        : 19           18
    Number of Builds       : 48           46
    Number of Simulations  : 163           161        0
    Number of Comparisons  : 103           102        0

    Failed Simulations are: 
    None
    Which comparisons are not bit-for-bit: 
    None

[davegill]

@gthompsnWRF
Greg,
Could you fix your affiliation for me please?

[davegill]

@gthompsnWRF

I am trying to dis-entangle multiple PRs into more tiny chunks from here onwards.

[davegill]

jenkins

Please find result of the WRF regression test cases in the attachment. This build is for Commit ID: 0b491619162d9d4a338712196809a7c65da55f83, requested by: gthompsnWRF for PR: https://github.com/wrf-model/WRF/pull/1388. For any query please send e-mail to David Gill.

    Test Type              | Expected  | Received |  Failed
    = = = = = = = = = = = = = = = = = = = = = = = =  = = = =
    Number of Tests        : 19           18
    Number of Builds       : 48           46
    Number of Simulations  : 163           161        0
    Number of Comparisons  : 103           102        0

    Failed Simulations are: 
    None
    Which comparisons are not bit-for-bit: 
    None

[gthompsnWRF]

@gthompsnWRF
Greg,
Could you fix your affiliation for me please?

Got it.

[weiwangncar]

I'm ok with this PR.

[davegill]

@gthompsnWRF @dudhia @weiwangncar
Folks,
Does an initialized CLDFRA from real actually get used?

The first time cldfra is used in the first rk step part 1 is in the radiation driver. In the radiation driver, the first time that the CLDFRA field is used is an initialization.

! Choose how to compute cloud fraction (since 3.6)
! Initialize to zero
     DO j=jts,jte
     DO k=kts,kte
     DO i=its,ite
        CLDFRA(i,k,j) = 0.
     END DO
     END DO
     END DO

[dudhia]

It only works in conjunction with initial cloud and humidity adjustments that go with it, so that cldfra recomputed in radiation should be the same as the input one in the first time step.

[gthompsnWRF]

@gthompsnWRF @dudhia @weiwangncar
Folks,
Does an initialized CLDFRA from real actually get used?

The first time cldfra is used in the first rk step part 1 is in the radiation driver. In the radiation driver, the first time that the CLDFRA field is used is an initialization.

! Choose how to compute cloud fraction (since 3.6)
! Initialize to zero
     DO j=jts,jte
     DO k=kts,kte
     DO i=its,ite
        CLDFRA(i,k,j) = 0.
     END DO
     END DO
     END DO

Dave: The advantage of seeing it done by real.exe is that initial values can be seen in both wrfinput and the very first history file. By waiting until radiation_driver is called, neither happens. The history file is written ahead of the first radiation time step if I recall. I think my own copy of radiation_driver had disabled the zero setting in radiation_driver. I suppose Jimy is right that it just gets made again on first time step - although, this time, if modifying the water vapor, then it will be more cloudy by default.

[davegill]

@dudhia @gthompsnWRF

The advantage of seeing it done by real.exe is that initial values can be seen in both wrfinput and the very first history file.

I think I see. This is basically diagnostically providing an initial value for CLDFRA that could be available for plotting purposes. Since this has no real impact on the model solution, I am even less concerned.

[gthompsnWRF]

@dudhia @gthompsnWRF

The advantage of seeing it done by real.exe is that initial values can be seen in both wrfinput and the very first history file.

I think I see. This is basically diagnostically providing an initial value for CLDFRA that could be available for plotting purposes. Since this has no real impact on the model solution, I am even less concerned.

Actually, the statement of 'no real impact' is not correct. Since it is being done in real.exe, the fields of cloud water and ice are initialized by cal_cldfra3 as well as a change to the water vapor field (to ensure saturation). So cloud evolution is whoppingly different - that is the point. In cold starts without clouds, it can take 3-15 hours to get clouds forming. With these changes, I get clouds immediately. It is true that some still deteriorate due to downward motions or mixing and dilution. But the change to the first 3 hours is dramatic - giving real-looking clouds at onset that stick around a while as the dynamics of WRF build other (or add onto existing) clouds.

[davegill]

@gthompsnWRF @weiwangncar @dudhia

But the change to the first 3 hours is dramatic - giving real-looking clouds at onset that stick around a while as the dynamics of WRF build other (or add onto existing) clouds.

Folks,
This is a namelist option. Do we want it on by default in the Registry? Most everyone runs 5 microphysics species (or more), so we would have an improved cloud state during the early simulation for most users.

[gthompsnWRF]

@gthompsnWRF @weiwangncar @dudhia

But the change to the first 3 hours is dramatic - giving real-looking clouds at onset that stick around a while as the dynamics of WRF build other (or add onto existing) clouds.

Folks,
This is a namelist option. Do we want it on by default in the Registry? Most everyone runs 5 microphysics species (or more), so we would have an improved cloud state during the early simulation for most users.

Dave: I am pretty sure users will not want this enabled by default, since it will be a big new change they may not have expected. In the past, I have seen a lot of hesitancy to enable something new when it makes big changes to users' regular testing simulations.

[weiwangncar]

I agree with Greg. Let's not make it default for now. We can revisit this in the future.

[davegill]

@gthompsnWRF @dudhia @weiwangncar
Folks,
Is this part of the modification that is interwoven with a proposal about MAD WRF?
Is this able to be merged?
Where is the input for this option from? Is this is a standard field from a GRIB file?

[dudhia]

Yes, this is one we want to resolve after the V4.3 branch since Pedro now has a renamed clfra3 for madwrf routine that we view as temporary.

…

On Tue, Feb 9, 2021 at 9:58 AM Dave Gill ***@***.***> wrote: @gthompsnWRF <https://github.com/gthompsnWRF> @dudhia <https://github.com/dudhia> @weiwangncar <https://github.com/weiwangncar> Folks, Is this part of the modification that is interwoven with a proposal about MAD WRF? Is this able to be merged? Where is the input for this option from? Is this is a standard field from a GRIB file? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77FEMJCM62MTWH4RILTS6FSS5ANCNFSM4WWKMFFA> .

[gthompsnWRF]

@gthompsnWRF @dudhia @weiwangncar
Folks,
Is this part of the modification that is interwoven with a proposal about MAD WRF?
Is this able to be merged?
Where is the input for this option from? Is this is a standard field from a GRIB file?

Hang on everyone. Let me ask for clarification. My proposal for inserting initial clouds does not "rely" on anything in MADWRF and I want my code to progress asap, earliest branch possible. Did I misinterpret Dave's question or Jimy's reply?

[dudhia]

The idea is to commit both yours before we create the V4.3 branch.

…

On Tue, Feb 9, 2021 at 10:05 AM gthompsnWRF ***@***.***> wrote: @gthompsnWRF <https://github.com/gthompsnWRF> @dudhia <https://github.com/dudhia> @weiwangncar <https://github.com/weiwangncar> Folks, Is this part of the modification that is interwoven with a proposal about MAD WRF? Is this able to be merged? Where is the input for this option from? Is this is a standard field from a GRIB file? Hang on everyone. Let me ask for clarification. My proposal for inserting initial clouds does not "rely" on anything in MADWRF and I want my code to progress asap, not in v4.3 branch. Did I misinterpret Dave's question or Jimy's reply? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77FKFHZIJ526HXBEO23S6FTN3ANCNFSM4WWKMFFA> .

[gthompsnWRF]

The idea is to commit both yours before we create the V4.3 branch.

OK, thanks for clarifying. I read your comment as having to wait until a future time when we unify codes in a new module_cloud_fraction (or similar). Just being sure that is not what you meant, thanks.

[dudhia]

I am going ahead and merging this one so that the MADWRF code can be compared for clashes. I see at least one area where they overlap in the Registry changes.