Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommended Issues to Address from PR #22 #23

Open
laurenchilutti opened this issue Jun 6, 2023 · 2 comments
Open

Recommended Issues to Address from PR #22 #23

laurenchilutti opened this issue Jun 6, 2023 · 2 comments

Comments

@laurenchilutti
Copy link
Contributor

Describe the bug
I am opening this issue to document the recommended changes from Rusty's review of PR #22 after PR 22 is merged.

The following are comments copied from the PR:

! -- CHECK for ntke if using satmedmf
if (Model%satmedmf) then
if (Model%ntke < 1 .or. Model%ntke > Model%ntrac) then
write(*,*) ' FATAL GFS_typedefs: TKE PBL scheme enabled (satmedmf) but TKE tracer not found in field_table.'
write(*,*) ' Stopping execution.'
stop 999
endif
endif

From bensonr: Stop statements may not abort a program correctly when using MPI. Should either import and use mpp_error or make a call to MPI_Finalize to properly abort execution.

!--- dynamical core parameters
logical :: dycore_hydrostatic = .true. !< whether the dynamical core is hydrostatic

From bensonr: The designed way to get this information to the physics from outside is to use the GFS_init_type. This type is populated with dycore and other external to the physics information within the atmos_model.F90::atmos_model_init function and it is passed to GFS_Initialize, where it is passed to the Model%init procedure.

From bensonr: Since we no longer need compatibility with ufs as they've embraced CCPP, we
could start using FMS functions and change the write statements to
mpp_error statement. With the appropriate FATAL condition, mpi will be
properly terminated and any future coupled components running concurrently
will also get the termination signal.

To Reproduce
N/A

Expected behavior
N/A

System Environment
N/A

Additional context
N/A

@lharris4
Copy link
Contributor

lharris4 commented Jun 7, 2023

Hi, @laurenchilutti. I presume we can just do a 'use mpp_mod' within the SHiELD Physics routines so we can call mpp_error()? Or do we need to change how the SHiELD Physics routines are built to bring in the FMS libraries?

@bensonr
Copy link
Contributor

bensonr commented Jun 20, 2023

@lharris4 - yes, a simple use mpp_mod or even the more inclusive use FMS , which includes every public interface and parameter available from the FMS library.

Hi, @laurenchilutti. I presume we can just do a 'use mpp_mod' within the SHiELD Physics routines so we can call mpp_error()? Or do we need to change how the SHiELD Physics routines are built to bring in the FMS libraries?

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

No branches or pull requests

3 participants