Skip to content

cam6_3_008: Fixes for PIO2 plus nudging I/O update#310

Merged
gold2718 merged 4 commits intoESCOMP:cam_developmentfrom
gold2718:pio2_fixes
Jan 10, 2021
Merged

cam6_3_008: Fixes for PIO2 plus nudging I/O update#310
gold2718 merged 4 commits intoESCOMP:cam_developmentfrom
gold2718:pio2_fixes

Conversation

@gold2718
Copy link
Collaborator

@gold2718 gold2718 commented Jan 8, 2021

Fixes to allow CAM to operate with PIO2
Unread buffer locations properly initialized after read for SE dycore.
Fixes to nudging code to work with new weak-scaling infrastructure
Fixes #237
Fixes #248
Fixes #263
Fixes #282
Closes #241
Closes #247

@gold2718 gold2718 added the bug-fix This PR was created to fix a specific bug. label Jan 8, 2021
@gold2718 gold2718 added this to the CESM2.3 milestone Jan 8, 2021
@gold2718 gold2718 self-assigned this Jan 8, 2021
@gold2718
Copy link
Collaborator Author

gold2718 commented Jan 8, 2021

@patcal, For some reason, I cannot request you as a reviewer. Please have a look at nudging.F90 which I hope has all of your changes plus some cleanup from me.

Copy link
Collaborator

@fvitt fvitt left a comment

Choose a reason for hiding this comment

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

Please explain how issue #282 "ambiguous dof when writing FV zonal mean values" is addressed. Thanks.


end function cam_pio_fileexists

integer function cam_pio_set_fill(File, fillmode, old_mode) result(ierr)
Copy link
Collaborator

Choose a reason for hiding this comment

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

It looks like the return value of ierr is not set if PIO2 is not defined.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nice catch, thanks!

@gold2718
Copy link
Collaborator Author

gold2718 commented Jan 8, 2021

Please explain how issue #282 "ambiguous dof when writing FV zonal mean values" is addressed.

Look at the change to dyn_grid.F90 starting at line 1116. When FV is in a 2-D decomposition, there is more than one task containing a particular latitude band (zonal mean value) and I was trying to write to that slot on the file from each of those tasks. The change makes sure that only one of those tasks will try to write.

This bug does not occur in a 1-D decomposition and PIO1 was perfectly happy to do the multiple writes from a 2-D decomposition but it seems like a really bad idea and PIO2 agrees :-)

@cacraigucar cacraigucar requested a review from patcal January 8, 2021 16:37
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.

Generally looks good, but I do have a few questions/concerns.

Purpose of changes (include the issue number and title text for each
relevant GitHub issue):
#248: scam tests don't work with pio2
#263: attempt to initialize variable prior to calling intent(out) subroutine
Copy link
Collaborator

Choose a reason for hiding this comment

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

It looks like there are no keywords in the main PR message for Issue #263. I assume there should be?

Also, Issue #237 isn't listed here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

On the #263 issue, that issue was not important for PIO1 usage and has been properly addressed as part of the PIO2 fixes. I added a line in the PR description.

Thanks for noticing the missing #237 line.

restartvars(i)%ifill)
else if(restartvars(i)%type == PIO_REAL) then
ierr = pio_put_att(File, restartvars(i)%vdesc, "_FillValue", &
restartvars(i)%rfill)
Copy link
Collaborator

Choose a reason for hiding this comment

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

It doesn't look like rfill is initialized above. Is that ok?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

My understanding is that this would be initialized if any variable were actually using that kind. As an example, dfill for fillvalue is initialized on line 1144 so it will be initialized when written out on line 1304.
@jedwards4b, do I understand that correctly?

Choose a reason for hiding this comment

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

no, I think that it should be - good catch.

Choose a reason for hiding this comment

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

Sorry, you are correct. This variable will not ever be written as PIO_REAL so this branch is never used.

restartvars(rvindex)%dims(1) = maxnflds_dim_ind
restartvars(rvindex)%dims(2) = ptapes_dim_ind
restartvars(rvindex)%fillset = .true.
restartvars(rvindex)%ifill = 0
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am probably misunderstanding the code, but is zero the best choice for a fill value? It seems like there could be situations where the variable really would have a value of zero. Should we just use the default PIO fill values for each type (e.g. PIO_FILL_INT) instead?

Choose a reason for hiding this comment

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

@nusbaume previously the code used an implied fill value of 0. This is just continuing the previous behavior with pio2, the reason this needs to be done for pio2 and not pio1 is that pio1 wrote values for the entire array even out of bounds points but pio2 only writes the values it needs to write and sets the rest to _FillValue. I agree that 0 is not the best fill value to consider, but any other value would require more changes in cam.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In this case, it is a good fill value because it is an invalid value for that item (decomp_type). The same goes for the other integer restart values.

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.

@jedwards4b @gold2718 Thanks for the explanations! I am happy with this PR now.

@gold2718 gold2718 changed the title Fixes for PIO2 plus nudging I/O update cam6_3_008: Fixes for PIO2 plus nudging I/O update Jan 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug-fix This PR was created to fix a specific bug.

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

6 participants