Release FV3 solver updates

[laurenchilutti]

Description

Releasing some updates on behalf of Lucas Harris including:
Revision to semi-implicit solver to linearize vertical sound wave propagation about the hydrostatic state. This has been extensively tested by GFDL and EMC in SHiELD, GFS, and RRFS.

Fixes # (issue)

How Has This Been Tested?

Changes have been tested with Intel compiler using tests in SHiELD_build/RTS
This changes answers - The CI on this will not pass initially, then I will update reference answers and it will pass.

Checklist:

Please check all whether they apply or not

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[lharris4]

Looks good to me. Thanks for getting this approved so quickly.

Lucas

[XiaqiongZhou-NOAA]

Great. We have tested the revision for SIM in RRFS and GFS. It works great.
Noticed that tau_w is used in SIM solver for Rayleigh damping. This variable is also used in explicit Rayleigh damping. Not sure if there are conflicts. I will check out this version to have a test in UFS.

[bensonr]

Looks like there are a few spacing changes from the old to the new code. Can you look through them and reset as needed.

[bensonr]

In some places here we are forcing constants to double precision, others are single, and one has no designation. I think we need to ensure consistency.

[laurenchilutti]

Do you have a recommendation of either all double precision or all single?

[KevinViner-NOAA]

#229

Great minds...

[lharris4]

Hi, Rusty, Lauren. The forced double precision is from the Rayleigh damping in fv_dynamics.F90. Since lower down (just above rf_cutoff) damping timescales can get very long this is to avoid the damping coefficient from getting rounded to 0. We can compute rff as double-precision too in the previous line for consistency: this calculation is only done once and then saved so efficiency isn't a concern. Thanks, Lucas

…

On Wed, Apr 19, 2023 at 1:07 PM laurenchilutti ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In model/nh_utils.F90 <#261 (comment)> : > + !Set up rayleigh damping + if (tau_w > 1.e-5 .and. .not. RFw_initialized) then + allocate(rff(km)) + RFw_initialized = .true. + do k=1,km + if (pfull(k) > rf_cutoff) exit + k_rf = k + rff(k) = dt/tau_w * sin(0.5*pi*log(rf_cutoff/pfull(k))/log(rf_cutoff/ptop))**2 + rff(k) = 1.0d0 / ( 1.0d0+rff(k) ) + enddo + endif + + Do you have a recommendation of either all double precision or all single? — Reply to this email directly, view it on GitHub <#261 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVHH3CEOJCHZ6AWRRK3XCALUDANCNFSM6AAAAAAXEB562U> . You are receiving this because your review was requested.Message ID: ***@***.***>

[lharris4]

Hi, Kate. With the separated variables tau_w and fast_tau_w_sec there shouldn't be any conflicts, and the Rayleigh damping is completely separate from the sound-wave change in SIM_solver(). Thanks, Lucas On Wed, Apr 19, 2023 at 1:26 PM Lucas Harris - NOAA Federal < ***@***.***> wrote:

…

Hi, Rusty, Lauren. The forced double precision is from the Rayleigh damping in fv_dynamics.F90. Since lower down (just above rf_cutoff) damping timescales can get very long this is to avoid the damping coefficient from getting rounded to 0. We can compute rff as double-precision too in the previous line for consistency: this calculation is only done once and then saved so efficiency isn't a concern. Thanks, Lucas On Wed, Apr 19, 2023 at 1:07 PM laurenchilutti ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In model/nh_utils.F90 > <#261 (comment)> > : > > > + !Set up rayleigh damping > + if (tau_w > 1.e-5 .and. .not. RFw_initialized) then > + allocate(rff(km)) > + RFw_initialized = .true. > + do k=1,km > + if (pfull(k) > rf_cutoff) exit > + k_rf = k > + rff(k) = dt/tau_w * sin(0.5*pi*log(rf_cutoff/pfull(k))/log(rf_cutoff/ptop))**2 > + rff(k) = 1.0d0 / ( 1.0d0+rff(k) ) > + enddo > + endif > + > + > > Do you have a recommendation of either all double precision or all single? > > — > Reply to this email directly, view it on GitHub > <#261 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AMUQRVHH3CEOJCHZ6AWRRK3XCALUDANCNFSM6AAAAAAXEB562U> > . > You are receiving this because your review was requested.Message ID: > ***@***.***> >

[laurenchilutti]

@bensonr your comments have been addressed - if you approve I will cherry-pick these final changes to the dev/emc PR

[lharris4]

Looks fine to me. Thanks.

[lharris4]

Thanks for making this name change too.