Skip to content

UFS-dev PR#65#1020

Merged
grantfirl merged 13 commits into
NCAR:mainfrom
grantfirl:ufs-dev-PR65
Jul 7, 2023
Merged

UFS-dev PR#65#1020
grantfirl merged 13 commits into
NCAR:mainfrom
grantfirl:ufs-dev-PR65

Conversation

@grantfirl
Copy link
Copy Markdown
Collaborator

Identical to ufs-community#65

! The lake data must say there's a lake here (lakefrac) with a depth (lakedepth)
if (lakefrac(i) > lakefrac_threshold .and. lakedepth(i) > lakedepth_threshold ) then
! This is a lake point. Inform the other schemes to use a lake model, and possibly nsst (lkm)
use_lake_model(i) = lkm
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This section is recommended not to be part of the forecast model. This should be predefined in the ufs_util. For the temporary solution, just make sure the thresholds used here are consistent with those in ufs_util. Otherwise there may be some mismatches with coldstart.

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.

@HelinWei-NOAA This change was already merged into the ufs/dev branch: ufs-community#65. When this goes to the NCAR/main branch, it should be identical to the PR that went into the ufs/dev branch except for when something breaks a non-UFS model. If you think that this should be changed, I would suggest opening a new PR into the ufs/dev branch with your changes.

do i=1,im
if (islmsk(i) == 1) then

if (use_lake_model(i)>0) then
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is islmsk equal to 0 (water) for lake points (use_lake_model>0)?

Comment thread physics/samfshalcnv.f
enddo
enddo
c
c turn off shallow convection if cloud depth is larger than cthk or less than cthkmn
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I know this exists elsewhere in the scheme, but "c"- denoted comments are not compatible with the FORTRAN90 standard. Probably something we want to address in the future.

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.

Yes, although I think that the CCPP documentation/rules state that code should be at least "Fortran90 where possible", there is still a smattering of F77 code that was grandfathered in from GFS physics. It would be nice to clean this up some day, although if the authors of the schemes prefer F77 and they're still maintaining the GFS schemes, it's hard to push back too much.

@grantfirl grantfirl merged commit 9b77c4e into NCAR:main Jul 7, 2023
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.

4 participants