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

cam6_3_086: Introduce PUMAS DDT #632

Merged
merged 43 commits into from
Dec 9, 2022

Conversation

cacraigucar
Copy link
Collaborator

@cacraigucar cacraigucar commented Aug 3, 2022

Brings in the PUMAS DDT (proc_rates) plus a few other minor PRs

closes #589
closes #703
closes #706
closes #707
closes #711

Partially address #708

@cacraigucar cacraigucar added enhancement New feature or request BFB bit for bit tag labels Aug 3, 2022
@cacraigucar cacraigucar added this to the CESM2.3 milestone Aug 3, 2022
@cacraigucar cacraigucar self-assigned this Aug 3, 2022
@cacraigucar cacraigucar marked this pull request as draft August 3, 2022 23:13
@cacraigucar
Copy link
Collaborator Author

@andrewgettelman and @Katetc - This is the full implementation of the DDT based on the list of variables that @andrewgettelman provided in issue #589. Please review this and let me know if there are any issues or if additional fields should be added.

Also, the variable "prodsnow" is not used in cam_dev/micro_pumas_cam.F90 once it is returned. I just wanted to point this out

Copy link
Collaborator

@andrewgettelman andrewgettelman left a comment

Choose a reason for hiding this comment

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

  1. Why are some variables 'trop_cld_lev' and some just 'lev'? It doesn't seem to be logical? E.g. UMR, UMS = lev, but UMG = trop_cld_lev?

  2. So now everything is in 'proc_rates'. I think this looks pretty readable to me and don't see an issue.

Thanks!

Andrew

@cacraigucar
Copy link
Collaborator Author

  1. Why are some variables 'trop_cld_lev' and some just 'lev'? It doesn't seem to be logical? E.g. UMR, UMS = lev, but UMG = trop_cld_lev?
  2. So now everything is in 'proc_rates'. I think this looks pretty readable to me and don't see an issue.

Thanks!

Andrew

  1. Why are some variables 'trop_cld_lev' and some just 'lev'? It doesn't seem to be logical? E.g. UMR, UMS = lev, but UMG = trop_cld_lev?
  2. So now everything is in 'proc_rates'. I think this looks pretty readable to me and don't see an issue.

Thanks!

Andrew

The answer to #1 is that you found a bug! I have added trop_cld_lev to these variables and will push it soon.

#2 Yes, the new DDT is called proc_rates. The name can be anything, so if you have a better name, let me know.

@sjsprecious
Copy link
Collaborator

A naive question: can we pass all the columns and levels to PUMAS in the future so that we do not need to worry about 'ncol' vs. 'pcol' and 'trop_cld_lev' vs. 'lev'? By doing this, we will compute some additional columns and levels, but I guess we won't use them anywhere else and it should hurt nothing. Or will these additional columns/levels crash PUMAS later?

@cacraigucar
Copy link
Collaborator Author

A naive question: can we pass all the columns and levels to PUMAS in the future so that we do not need to worry about 'ncol' vs. 'pcol' and 'trop_cld_lev' vs. 'lev'? By doing this, we will compute some additional columns and levels, but I guess we won't use them anywhere else and it should hurt nothing. Or will these additional columns/levels crash PUMAS later?

@andrewgettelman and/or @Katetc - @sjsprecious question will need to be answered by one of you. I don't know the answer.

@andrewgettelman
Copy link
Collaborator

We decided for various reasons to have a smaller number of levels in the diagnostic output fields since they would just be extra memory to carry around. I still think it is a bit asymmetric, but for efficiency we decided to do this (less memory used).

pcols v. ncols has to do with potential uneven allocations by chunks I believe. I'm not sure why it goes all the way into the microphysics, I thought that was all interface level.

@Katetc
Copy link
Collaborator

Katetc commented Aug 9, 2022

@sjsprecious So columns that are >ncol but <pcol are typically not initialized or used anywhere in the model, and that could cause a crash. Levels above trop_cld_lev should, in theory, be ok but I don't think other parts of the model expect the physics to look at those, so they could have bad values. Also, the very high-top model, WACCMX, has many levels of atmosphere above the cloud top that should not have any microphysics working on, and we could slow down that model if we have to look at all of those levels in microphysics.

@sjsprecious
Copy link
Collaborator

Thanks @andrewgettelman and @Katetc for your clarifications. The reason I asked this question is that I have observed a GPU performance hit with the unpacked interface for PUMAS. This is due to the fact that GPU is accessing partial slices of an array here and GPU may have to generate an underlying temporary array first (@johnmauff could comment more on this issue). It won't be a problem if we could simply pass all the columns and levels to GPU, but the answers above make sense to me.

@andrewgettelman
Copy link
Collaborator

We need to assess whether the extra memory or the GPU efficiency is more important. How can we do that?

@cacraigucar
Copy link
Collaborator Author

I would suggest that this discussion of memory/GPU efficiency should become its own issue. A few months from now, this discussion may be hard to find as it is buried in the DDT PR.

@sjsprecious
Copy link
Collaborator

Thanks @andrewgettelman and @cacraigucar for your comments. I agree that my question should be a separate discussion and I apologize for bringing it up here. We can definitely discuss more in another GitHub issue.

One quick question about this PR: Is using proc_rates part of the efforts of SIMA or CCPP work? Or is it only to make the argument list shorter?

@andrewgettelman
Copy link
Collaborator

The derived type for process rates is just to make the argument list shorter. It eliminates some steps in adding diagnostics to PUMAS down the road.

@fvitt fvitt removed their request for review December 1, 2022 18:11
Copy link
Collaborator

@Katetc Katetc left a comment

Choose a reason for hiding this comment

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

My only issue is that I don't understand what is up with bergso_grid. Other than that, it all looks great!!

src/physics/cam_dev/micro_pumas_cam.F90 Show resolved Hide resolved
src/physics/cam_dev/micro_pumas_cam.F90 Show resolved Hide resolved
src/physics/cam_dev/micro_pumas_cam.F90 Show resolved Hide resolved
src/physics/cam_dev/micro_pumas_cam.F90 Show resolved Hide resolved
src/physics/cam_dev/micro_pumas_cam.F90 Show resolved Hide resolved
Copy link
Collaborator

@nusbaume nusbaume left a comment

Choose a reason for hiding this comment

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

Looks good to me! Just a couple final requests to add some test descriptions, and one question related to a cam-dev change. Thanks!

@@ -1516,7 +1516,7 @@
<option name="wallclock">00:20:00</option>
</options>
</test>
<test compset="FCnudged" grid="ne0CONUSne30x8_ne0CONUSne30x8_mt12" name="SMS_D_Ln9_Vnuopc" testmods="cam/outfrq9s_refined_camchem">
<test compset="FCnudged" grid="ne0CONUSne30x8_ne0CONUSne30x8_mt12" name="SMS_D_Ln9_Vnuopc_P720x1" testmods="cam/outfrq9s">
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we add a new <option name="comment" > entry for this test that describes in words what this is testing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@nusbaume - I just changed the processor count and changed the testmods as @fvitt suggested in #708. I do not know what this is testing exactly as I did not introduce the test. I would suggest that test descriptions be added when the testing list is updated?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@fvitt can you provide a short one sentence description of what model configuration this is testing?

@cacraigucar Although I imagine we will certainly try to add in test descriptions when we do the test list update, adding descriptions in when we can beforehand will make that (big) job a little easier, and will save us from pinging Francis and other people a bunch of times when that development is ongoing.

Copy link

Choose a reason for hiding this comment

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

Nudged CAM-Chem on a regionally refined grid

@@ -1622,7 +1622,7 @@
<machine name="cheyenne" compiler="intel" category="camchem"/>
</machines>
</test>
<test compset="FCHIST" grid="ne0CONUSne30x8_ne0CONUSne30x8_mt12" name="SMS_D_Ln9_Vnuopc" testmods="cam/outfrq9s_refined_camchem">
<test compset="FCHIST" grid="ne0CONUSne30x8_ne0CONUSne30x8_mt12" name="SMS_D_Ln9_Vnuopc_P720x1" testmods="cam/outfrq9s">
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we add a new <option name="comment" > entry for this test that describes in words what this is testing?

Copy link

Choose a reason for hiding this comment

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

Free running CAM-Chem on a regionally refined grid

src/physics/cam/micro_pumas_cam.F90 Show resolved Hide resolved
src/physics/cam_dev/micro_pumas_cam.F90 Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BFB bit for bit tag enhancement New feature or request
Projects
Status: Tag
Development

Successfully merging this pull request may close these issues.