[production/RRFS.v1]saSAS sigmab initialization modification during the first timestep

[JiliDong-NOAA]

This PR follows Jongil's suggestion and aims to reduce the large convective reflectivity caused by saSAS adjustment in the first timestep during a warm start. The issue is likely related to the inconsistency when DA updates the moisture at t but not the moisture from the previous timestep (t-36s). The moisture from the previous timestep is needed for initializing sigmab (updraft area fraction) when calculating qadv (q advection or tendency term).

The PR forces qadv to zero in the first timestep when a namelist parameter sigmab_coldstart is set to .true. It also reduces the lower limit of sigmab from 0.01 to 0.0 in the first timestep.

sigmab_modification.pptx

[JiliDong-NOAA]

Could we add @JongilHan66 as the reviewer? Thanks!

[lisa-bengtsson]

@JiliDong-NOAA I think these changes look good - do you plan on setting sigmab_coldstart to true only if you cycle with DA? If you restart from restart files, then q is updated at the previous timestep and read in to be used in physics for the current time-step. I would propose including this change in the ufs-weather-model and also alert the HAFS, GFS and GEFS teams to set this flag to true in cycled configurations.

[JiliDong-NOAA]

@JiliDong-NOAA I think these changes look good - do you plan on setting sigmab_coldstart to true only if you cycle with DA? If you restart from restart files, then q is updated at the previous timestep and read in to be used in physics for the current time-step. I would propose including this change in the ufs-weather-model and also alert the HAFS, GFS and GEFS teams to set this flag to true in cycled configurations.

You are right, Lisa. The idea is to set sigmab_coldstart to false by default and switch it to true only for cycled DA warm start. This should ensure the result remains unchanged for restart. I will submit a PR to FV3 later.

Thanks for reviewing this PR!

[grantfirl]

There are no issues from a CCPP perspective, but how much more development should be expected in this branch? Plus, how much of this development needs to go to ufs/dev?

[JiliDong-NOAA]

There are no issues from a CCPP perspective, but how much more development should be expected in this branch? Plus, how much of this development needs to go to ufs/dev?

My understanding is that this branch will be updated when necessary, particularly for bug/issue fix. I will leave this to @yangfanglin @MatthewPyle-NOAA and @ericaligo-NOAA for their comments.

[yangfanglin]

There are no issues from a CCPP perspective, but how much more development should be expected in this branch? Plus, how much of this development needs to go to ufs/dev?

My understanding is that this branch will be updated when necessary, particularly for bug/issue fix. I will leave this to @yangfanglin @MatthewPyle-NOAA and @ericaligo-NOAA for their comments.

I agree this branch should be updated for bug fixes. For this particular fix, tests had been done for RRFSv1 and HAFS. @JongilHan66 and @lisa-bengtsson should this fix be merged back to the develop branch ? Do you have concerns about its impact on global model applications (GFS, GEFS and SFS etc) ?

[JongilHan66]

There are no issues from a CCPP perspective, but how much more development should be expected in this branch? Plus, how much of this development needs to go to ufs/dev?

My understanding is that this branch will be updated when necessary, particularly for bug/issue fix. I will leave this to @yangfanglin @MatthewPyle-NOAA and @ericaligo-NOAA for their comments.

I agree this branch should be updated for bug fixes. For this particular fix, tests had been done for RRFSv1 and HAFS. @JongilHan66 and @lisa-bengtsson should this fix be merged back to the develop branch ? Do you have concerns about its impact on global model applications (GFS, GEFS and SFS etc) ?

I agree this fix to be merged back to the develop branch. I think this fix has only minor impacts on global model applications (maybe only butterfly impact) and have no concerns.

[lisa-bengtsson]

I also agree that it could be merged back in. We are working on some other updates for this closure for potential use at coarse resolution, so we could combine all updates to one PR?

[yangfanglin]

Sounds good. Then we should proceed with merging this back to the develop branch. Combining with another PR is a good idea.

[JiliDong-NOAA]

I also agree that it could be merged back in. We are working on some other updates for this closure for potential use at coarse resolution, so we could combine all updates to one PR?

@lisa-bengtsson that sounds good to me. would you like me to open a PR to develop branch, so you can combine it later?

[grantfirl]

I also agree that it could be merged back in. We are working on some other updates for this closure for potential use at coarse resolution, so we could combine all updates to one PR?

@lisa-bengtsson that sounds good to me. would you like me to open a PR to develop branch, so you can combine it later?

We'll add it to the list of PRs that need to go back to ufs/dev. Please don't make an additional PR at this time.

[JiliDong-NOAA]

I also agree that it could be merged back in. We are working on some other updates for this closure for potential use at coarse resolution, so we could combine all updates to one PR?

@lisa-bengtsson that sounds good to me. would you like me to open a PR to develop branch, so you can combine it later?

We'll add it to the list of PRs that need to go back to ufs/dev. Please don't make an additional PR at this time.

I see. Thanks @grantfirl