Skip to content

Updating SGS cloud interstitial to add Chab-Becht cloud fraction and …#122

Merged
SamuelTrahanNOAA merged 4 commits into
NOAA-GSL:gsl/developfrom
joeolson42:sgsradpre
Feb 24, 2022
Merged

Updating SGS cloud interstitial to add Chab-Becht cloud fraction and …#122
SamuelTrahanNOAA merged 4 commits into
NOAA-GSL:gsl/developfrom
joeolson42:sgsradpre

Conversation

@joeolson42
Copy link
Copy Markdown
Collaborator

This modification adds:

  1. A new cloud fraction (Chaboureau and Bechtold 2005) for the GF convection scheme
  2. The capability to separate frozen subgrid clouds into both snow and ice (no longer just ice).

& clouds1,clouds2,clouds3,clouds4,clouds5
real(kind=kind_phys), dimension(:,:), intent(inout) :: qc_save, qi_save
real(kind=kind_phys), dimension(:,:), intent(inout) :: qci_conv
real(kind=kind_phys), dimension(:,:), intent(in) :: ud_mf
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On thing to be aware of: ud_mf is in the GFS_interstitial DDT and as far as I can see it gets set/reset in the physics group. Since it is intent(in) here, you probably get invalid data passed in (from a different block)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are wise to be concerned, but in this case, I think it's OK. Here is a brief printout of ud_mf, which has reasonable values of mass-flux (although sometime zero - maybe the convection isn't reaching that high at some i points):

k= 20 ud_mf= 0.121096490473802
k= 20 ud_mf= 0.000000000000000E+000
k= 20 ud_mf= 0.719252198946091
k= 20 ud_mf= 1.83385869435230
k= 20 ud_mf= 1.69616072660016
k= 32 ud_mf= 1.70287760640253
k= 32 ud_mf= 1.25508844531819
k= 32 ud_mf= 1.30862285882288
k= 32 ud_mf= 1.79306649029620
k= 32 ud_mf= 0.858321688490849
k= 32 ud_mf= 0.471099592930162
k= 32 ud_mf= 0.901912835814989
k= 32 ud_mf= 1.15600537456719
k= 20 ud_mf= 1.39565460657562
k= 20 ud_mf= 1.32165535435073
k= 21 ud_mf= 0.000000000000000E+000
k= 21 ud_mf= 0.000000000000000E+000
k= 21 ud_mf= 0.000000000000000E+000
k= 21 ud_mf= 0.000000000000000E+000
k= 21 ud_mf= 0.000000000000000E+000
k= 21 ud_mf= 0.689175993672929
k= 21 ud_mf= 0.388614361705108

And here is an example of the cloud fractions at the upper-levels produced by these modifications (right) compared to when leveraging the MYNN stratus cloud fraction (left):

Screen Shot 2022-02-16 at 9 04 08 AM

These results are within the bounds of expectations to me.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear, I agree with Dom that this shouldn't work. I am investigating why it may OR how I can make sure it works.

Copy link
Copy Markdown
Collaborator Author

@joeolson42 joeolson42 Feb 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK... I was puzzled as to how this code seems to work, so I:

  1. added a "ud_mf_gf" in the TBD block,
  2. set ud_mf_gf(i,k) = ud_mf(i,k) in the GF driver,
  3. piped ud_mf_gf into module_SGSCloud_RadPre.f90 instead of ud_mf.
  4. Ended up with almost identical results

I would happily attach an image for proof but this web interface is not allowing me to do so (error: "Something went really wrong, and we can't process that file).

So, even though either method produces basically the same answer (although not bit-4-bit identical), I suggest we go with this updated method just because we know the TBD block is saved in memory. Note that I failed in converting ud_mf into a TBD array. It failed at compile time and I don't know why. Apparently, it takes more than simply modifying GFS_typedefs.F90 and GFS_debug.F90...

Happy to hear any comments on this.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll have to move it in GFS_typedefs.F90, GFS_typedefs.meta, and in GFS_debug.F90. In the metadata file, the entry ud_mf must be moved into the metadata section for the tbd type.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Dom. I missed the ud_mf move in GFS_typedefs.meta. Now it compiles and runs and I don't need the additional array. As far as I can tell, this code is ready for the regression tests.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sam,
Perhaps we can ask Haiqin and Hannah to review this PR?
-joe

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious, did moving ud_mf into Tbd have an impact on results?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, by eye the cloud fractions looked identical, but it was not bit-4-bit identical.


Tc = T3D(i,k) - 273.15
!Partition the convective clouds into water & frozen species
liqfrac = min(1., max(0., (Tk-244.)/29.))
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that min(1., max(0., (T3D(i,k)-244.)/25.)) switched to min(1., max(0., (Tk-244.)/29.)). Is the switch from 25 to 29 in the dominator done purposely, or is it a typo?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was done on purpose, but I have plenty of doubt as to which is optimal. In reality, the partitioning of water vs frozen condensate is more than a function of temperature, so both values are wrong.

In this case, since most condensate between 0 and -4 C is in water phase, maybe we should change it back to 25. If you prefer it changed to 25, I 'll do it.

This tweak won't require new regression tests.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine with this change, just wanted to make sure something didn't slip through unknowingly

Copy link
Copy Markdown

@hannahcbarnes hannahcbarnes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. I am looking forward to testing it out on our GFS+GF runs.

Copy link
Copy Markdown
Collaborator

@haiqinli haiqinli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me. Thanks.

@SamuelTrahanNOAA SamuelTrahanNOAA merged commit 84b7646 into NOAA-GSL:gsl/develop Feb 24, 2022
zhanglikate referenced this pull request in zhanglikate/ccpp-physics Mar 1, 2024
Updates to C3 and SAS convection schemes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants