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

JCSDA development without the adjoint changes #807

Merged
merged 8 commits into from
Sep 21, 2021

Conversation

danholdaway
Copy link
Contributor

Description

This a series of changes implemented by the JCSDA to enable data assimilation applications (without the adjoint part).

The main changes are to allow for paths to the namelist files, field_table, and the INPUT directory. The solution used follows the one suggested provided to @aerorahul by @bensonr.

Other change include allowing more tracers for EMC's CMAQ assimilation and changes to MPP adjoint for data assimilation with MOM6

How Has This Been Tested?
We have run the the unit tests of the JEDI system

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules
  • New check tests, if applicable, are included
  • make distcheck passes

@danholdaway
Copy link
Contributor Author

@bensonr hoping we can get this merged more quickly without the adjoint changes. Since it seems GMAO can't even build with the latest FMS it will be a long time before they can test those adjoint changes.

@danholdaway danholdaway changed the title JCSDA development without the adjoint JCSDA development without the adjoint changes Sep 2, 2021
@bensonr
Copy link
Contributor

bensonr commented Sep 2, 2021

@danholdaway - with this new PR, do we still need #787 to remain open?

fms/fms_io.F90 Show resolved Hide resolved
fms/fms_io.F90 Outdated Show resolved Hide resolved
@danholdaway
Copy link
Contributor Author

@danholdaway - with this new PR, do we still need #787 to remain open?

I would suggest closing that PR. The conversation involving GMAO folks could move to an issue perhaps.

@danholdaway danholdaway mentioned this pull request Sep 2, 2021
8 tasks
@sanAkel
Copy link

sanAkel commented Sep 3, 2021

@danholdaway (and others involved), I would like to say a few things:

  1. I was mentioned in the now closed PR because building GEOSgcm includes building the coupled model, which in turn includes MOM5 and MOM6 ocean models.
  2. Reg. MOM6 in GEOS, as this and others above it should indicate, we have been able to build GEOSgcm, and also run it.

Therefore,

Since it seems GMAO can't even build with the latest FMS

Is incorrect. I would appreciate if would please:
Since it seems GMAO can't even build with the latest FMS

Also note that:

  • MOM6 in GEOS is up to date with dev/gfdl so you can't ask for a more recent version!
  • As for FV3, it is up to @wmputman.

Thanks!

@danholdaway
Copy link
Contributor Author

@sanAkel I was referring to the issues Matt was reporting. But it seems he got it building so that's great. In any case it would be a while before the adjoint could be tested with the branch we were trying to merge so we closed that and took out the change.

@sanAkel
Copy link

sanAkel commented Sep 3, 2021

@sanAkel I was referring to the issues Matt was reporting. But it seems he got it building so that's great. In any case it would be a while before the adjoint could be tested with the branch we were trying to merge so we closed that and took out the change.

@danholdaway Thanks for the reply. I have nothing to do/say with the

adjoint could be tested with the branch

Whatever floats your boat and makes it go fast! 😉
When you want it to be going in MOM6 modeled fluid, let me know. Thanks again!

@rem1776 rem1776 merged commit 212efb5 into NOAA-GFDL:main Sep 21, 2021
Copy link
Member

@thomas-robinson thomas-robinson left a comment

Choose a reason for hiding this comment

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

This just needs a doxygen comment for the description of the new variable custom_path

character(len=*), intent(out) :: grid_file
character(len=*), intent(in) :: mosaic_file
type(domain2D), intent(in) :: domain
integer, intent(in), optional :: tile_count
character(len=*), intent(in), optional :: custom_path
Copy link
Member

Choose a reason for hiding this comment

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

Please add a doxygen description of this new variable per the style guide functions section

"Inline doxygen descriptions for all arguments, except the result variable."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do. We'll have another PR coming up so will add it then.

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.

6 participants