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

Clean up surface.F90 and simplify nst_land_fill with FieldBundle loop (this one will be correct, I swear) #519

Merged

Conversation

LarissaReames-NOAA
Copy link
Collaborator

This PR addresses Issue #516

I removed some old code that's no longer used and converted nst_land_fill to using a FieldBundle loop to cut down on code length. I also wrote a test for this subroutine that checks that land points in all of the various nst fields are being set properly. All tests pass as do the old system tests.

Third time's a charm

@GeorgeGayno-NOAA
Copy link
Collaborator

@LarissaReames-NOAA Why create the field bundle in 'nst_land_fill'? Why not do that earlier in say 'create_nst_esmf_fields'. That way the bundle can be used in other places. For example, in routine 'interp' a bundle regrid could be done to shorten the code by eliminating all those individual regrids.

@LarissaReames-NOAA
Copy link
Collaborator Author

@LarissaReames-NOAA Why create the field bundle in 'nst_land_fill'? Why not do that earlier in say 'create_nst_esmf_fields'. That way the bundle can be used in other places. For example, in routine 'interp' a bundle regrid could be done to shorten the code by eliminating all those individual regrids.

The fieldbundle used here actually doesn't include all of the nst fields as there are two (tref and xz) which need to be set to different values then the others which get set to 0. It was either that, or include those two in the bundle write up an if statement that checked for the name of the field and did different things based on that. I figure it's probably close to a wash in code length difference between those two approaches.

I actually have the latter coded up in a different branch, but I'm waiting for the soiltype fix to be merged in before submitting that PR. In that branch, I use bundles for each type of masked regridding and also use those same bundles to loop over for the search function as well. In the water regrid section, I include nst fields with the bundle if the nst flag is set, not in a separate bundle. I was able to cut out close to 1000 lines of code by using these bundles throughout the interp routine, even with the addition of the two subroutines I wrote to regrid and search over the bundles.

In total, I'm not sure creating a bundle with only nst fields and reusing this field bundle in two places would save that much code since there aren't any other places where only nst fields are looped over. Since the water regrid includes other fields, I'd have to create a bundle with only those non-nst fields and call the regrid and search routines twice in that case.

Does any of this makes sense? If you want you can look at my other branch (feature/sfc_regrid_many, no PR yet) to see what my code looks like.

farrayPtr=data_ptr, rc=rc)
if(ESMF_logFoundError(rcToCheck=rc,msg=ESMF_LOGERR_PASSTHRU,line=__LINE__,file=__FILE__)) &
call error_handler("IN FieldGet", rc)
do i = 1,16
Copy link
Collaborator

Choose a reason for hiding this comment

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

There is an ESMF routine that will return the number of fields (fieldCount) within a bundle:
http://earthsystemmodeling.org/docs/release/ESMF_8_1_1/ESMF_refdoc/node5.html#SECTION050251000000000000000

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, I use that functionality in the new *****_many routines in the sfc_regrid_many branch, but in this case I know the field number exactly so I didn't really see the benefit to calling another ESMF routine in this case.

Copy link
Collaborator

Choose a reason for hiding this comment

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

In that case please define a parameter NUM_ESMF_FIELDS or something of that sort. You should not use bare constants in production code (it's OK to do so in test code).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done. I also converted the other bare constants that had been used in the code prior to my changes to parameters as well.

@GeorgeGayno-NOAA
Copy link
Collaborator

Did you run the consistency tests? I can do so on the machines you can't access.

@LarissaReames-NOAA
Copy link
Collaborator Author

@GeorgeGayno-NOAA They passed on Hera.

@GeorgeGayno-NOAA
Copy link
Collaborator

@GeorgeGayno-NOAA They passed on Hera.

Merge the latest updates from 'develop'. Then I can run them today and, hopefully, merge.

@LarissaReames-NOAA
Copy link
Collaborator Author

The branch has been updated and passes tests.

@LarissaReames-NOAA
Copy link
Collaborator Author

So it looks like. while the consistency tests currently in the develop branch all pass, the tests I'd written for the regional capabilities (PR #252) are now broken. It appears this was caused by the implementation of the new tracers in PR #388 as these tests passed before I merged in the most recent develop branch changes

@GeorgeGayno-NOAA
Copy link
Collaborator

@GeorgeGayno-NOAA They passed on Hera.

Merge the latest updates from 'develop'. Then I can run them today and, hopefully, merge.

Tests passed on Hera, Orion, Jet, WCOSS-Cray and WCOSS-Dell

@LarissaReames-NOAA
Copy link
Collaborator Author

All develop branch and regional grib2 system/consistency tests now pass on Hera after implementing a few fixes for the new num_tracers_input usage. Unit tests also pass.

@GeorgeGayno-NOAA
Copy link
Collaborator

All develop branch and regional grib2 system/consistency tests now pass on Hera after implementing a few fixes for the new num_tracers_input usage. Unit tests also pass.

I had no problems running the consistency tests for this PR. Which tests failed for you?

@LarissaReames-NOAA
Copy link
Collaborator Author

All develop branch and regional grib2 system/consistency tests now pass on Hera after implementing a few fixes for the new num_tracers_input usage. Unit tests also pass.

I had no problems running the consistency tests for this PR. Which tests failed for you?

The consistency tests that have been in a PR to the release branch for months and are just as suitable for the develop branch. They test a much wider range of capabilities that the code has for grib2 files, including reading in the Thompson aerosol variables. I've been using them to test as I develop for the develop branch. I'm going to submit a PR later today to the develop branch so we can get those in.

@GeorgeGayno-NOAA
Copy link
Collaborator

@LarissaReames-NOAA Is this ready to merge?

@LarissaReames-NOAA
Copy link
Collaborator Author

@GeorgeGayno-NOAA Yes, the tracer issues were fixed and I updated the test for reading the variable mapping table to check for the new num_tracers_input variable.

@GeorgeGayno-NOAA GeorgeGayno-NOAA merged commit daf2a9d into ufs-community:develop May 26, 2021
@LarissaReames-NOAA LarissaReames-NOAA deleted the feature/sfc_cleanup branch May 26, 2021 14:30
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.

3 participants