-
Notifications
You must be signed in to change notification settings - Fork 27
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
Dev/jcsda #35
Dev/jcsda #35
Conversation
@junwang-noaa could you assign some reviewers please? I don't have permission to do so. |
Thanks @junwang-noaa! @bensonr, @XiaqiongZhou-NOAA thanks in advance for looking over and testing the changes. Let me and @CoryMartin-NOAA know if you have any questions about what we're hoping to achieve. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks fine to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the variables/routines you've exposed as public aren't being used within the dycore. Are these elements being used outside of the dycore?
real :: deg2rad | ||
character (len = 80) :: source ! This tells what the input source was for the data | ||
real, parameter :: deg2rad = pi/180. | ||
character (len = 80), public :: source ! This tells what the input source was for the data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've made source public, but I don't see any other code using that information.
character(len=27), parameter :: source_fv3gfs = 'FV3GFS GAUSSIAN NEMSIO FILE' | ||
public get_external_ic, get_cubed_sphere_terrain | ||
public remap_scalar, remap_dwinds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've made remap_scalar and remap_dwinds public, but none of your other code changes use these routines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bensonr yes these are being used outside of the dycore, in the JEDI data assimilation system. We have cases where we need to read cold starts in the data assimilation but cannot use the full dycore initialization routines. So we read the cold starts using our own routines that access FMS directly and then call the remapping methods. We may also have cases in the future where we want to remap a state, for example after adding the increment and these routines could be useful there.
…da, dycore PR NOAA-EMC#35 Co-authored-by: Dan Holdaway <[email protected]>
* add GFSv16 dzmin change * Add code changes in external_ic.F90 and fv_grid_tools.F90 for dev/jcsda, dycore PR #35 Co-authored-by: Jun Wang <[email protected]> Co-authored-by: Dan Holdaway <[email protected]>
Committed in PR#44, close PR. |
* updates for double-periodic initialization * fix GNU compiler out-of-bounds issue in GFDL/atmosphere.F90
* add GFSv16 dzmin change * Add code changes in external_ic.F90 and fv_grid_tools.F90 for dev/jcsda, dycore PR NOAA-EMC#35 Co-authored-by: Jun Wang <[email protected]> Co-authored-by: Dan Holdaway <[email protected]>
pull latest master updates (PR #35) into dev/gfdl
Two pieces of development that are needed on the JCSDA side.
To make the remapping methods used in the cold start reader public and usable from outside. This is so that we can read cold starts in the fv3-jedi interface and access remapping where we need it.
To address the issue described in Make grid_spec.nc file path in namelist more generic #32.
closes: #32