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

On branch jm-pr-multiple-instances-of-ccpp-physics #1000

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

michalakes
Copy link
Contributor

Changes to add an instance index to CCPP physics

Changes to be committed:
modified: physics/GFS_phys_time_vary.fv3.F90
modified: physics/GFS_phys_time_vary.fv3.meta
modified: physics/h2ointerp.f90
modified: physics/mp_thompson.F90
modified: physics/mp_thompson.meta
modified: physics/ozinterp.f90

michalakes added 2 commits February 28, 2023 14:41
	Changes to add an instance index to CCPP physics
 Changes to be committed:
	modified:   physics/GFS_phys_time_vary.fv3.F90
	modified:   physics/GFS_phys_time_vary.fv3.meta
	modified:   physics/h2ointerp.f90
	modified:   physics/mp_thompson.F90
	modified:   physics/mp_thompson.meta
	modified:   physics/ozinterp.f90
	Bump up dimension of is_initialized array to match other instances and add comment
 Changes to be committed:
	modified:   physics/mp_thompson.F90
@@ -48,7 +48,7 @@ module GFS_phys_time_vary

public GFS_phys_time_vary_init, GFS_phys_time_vary_timestep_init, GFS_phys_time_vary_timestep_finalize, GFS_phys_time_vary_finalize

logical :: is_initialized = .false.
logical, dimension(200) :: is_initialized = .false. ! why 200?
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe another option would be to define "is_initialized" as an interstitial variable? Then each instance would have its own copy. This also keeps the instance business out of the physics schemes, but does come with the burden of adding more interstitials. Either way, changes to the schemes are needed, but we may need to discuss this more.

@@ -54,7 +54,12 @@ subroutine read_h2odata (h2o_phys, me, master)
!--- h2o_pres - vertical pressure level (mb)
!--- h2o_time - time coordinate (days)
!---
allocate (h2o_lat(latsh2o), h2o_pres(levh2o),h2o_time(timeh2o+1))
! NOTE: If there are multiple instances of CCPP physics, only the first instance
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm surprised that this works. Only one instance is allocating space, but all instances are reading and writing to the same memory?

@climbfuji
Copy link
Collaborator

@dustinswales @grantfirl We'll need to revive this PR and make sure it finds its way into the authoritative codebase. I'll work on updating it to the latest NCAR main code (a few conflicts to resolve).

@climbfuji
Copy link
Collaborator

@dustinswales @grantfirl I am going to revive this PR. How do you want me to proceed, since these changes are for NCAR main? Should I simply update the PR from NCAR main and resolve the conflicts? Are you going to bring this down to the ufs fork for testing? Thanks ...

@grantfirl
Copy link
Collaborator

@dustinswales I thought these changes were already incorporated into ufs/dev? Or was it just partial?

@grantfirl
Copy link
Collaborator

@dustinswales I thought these changes were already incorporated into ufs/dev? Or was it just partial?

OK, it looks like ufs-community#75 and the followup ufs-community#150 partially contained some of these changes, at least for ozone physics.

Since those were targeted at ufs-community, I'm thinking that it might be best to rebase this off of ufs/dev and target a PR there.

@dustinswales
Copy link
Collaborator

@grantfirl Correct. Only the ozone physics were updated to address Johns issues.
To wrap this up we should to refactor the h2o photochemistry scheme identically to the ozone. Then the changes to mp_thompson and the GFS interstitials are trivial, we just need to move some things from module memory to interstitials OR define them with the instance dimension (I vote for the former).
If this sounds good I can do the h2o changes, but probably not for a week at least.

@climbfuji
Copy link
Collaborator

Sounds great, thank you both. I can help with the remaining changes after Dustin is done with h2o.

@climbfuji
Copy link
Collaborator

@dustinswales and @grantfirl any updates on the multiple instance changes from @michalakes ? As I said above, I can help with the remaining changes after Dustin is done with H2O. Thanks!

@dustinswales
Copy link
Collaborator

@climbfuji After ufs/dev #223, all that remains is to create a new interstitial for is_initialized in GFS_phys_time_vary.fv3.F90.

@climbfuji
Copy link
Collaborator

@climbfuji After ufs/dev #223, all that remains is to create a new interstitial for is_initialized in GFS_phys_time_vary.fv3.F90.

Thanks Dustin. I had some thoughts about this. I don't think you can use an interstitial variable for this. It ought to be a scheme module variable, otherwise it needs to be allocated by the host and saved there. Interstitials don't have any memory whatsoever.

@dustinswales
Copy link
Collaborator

@climbfuji Sorry, I meant a host interstitial that persists (GFS_control_type).
That's where I put all of the module variables that were causing problems with multiples instances.

@climbfuji
Copy link
Collaborator

@climbfuji Sorry, I meant a host interstitial that persists (GFS_control_type). That's where I put all of the module variables that were causing problems with multiples instances.

Ok, that makes sense. Different terminology ;-)

@dustinswales
Copy link
Collaborator

@climbfuji Sorry, I have this (bad) habit of calling everything that comes into the physics an Interstitial, even though Interstitials are a diverse group.

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