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

Ensure that NOAA-EMC dev/emc can be synchronized with NOAA-GFDL master #54

Open
climbfuji opened this issue Jan 13, 2021 · 6 comments
Open

Comments

@climbfuji
Copy link

We need to make sure that EMC's dycore dev/emc branch stays close enough to GFDL's master branch so that updates can be synchronized.

Specific challenges that were discussed in a telecon in 01/13/2021 between @junwang-noaa, @XiaqiongZhou-NOAA, @bensonr, @DusanJovic-NOAA and @climbfuji:

  • CCPP physics used in dev/emc for fast physics, but not in the GFDL branches
    • No short-term plans to include more processes in the fast physics than the existing saturation adjustment
    • No large structural changes around the fast physics calls expected in the near future
    • Updates the the saturation adjustment code will need to be copied over to ccpp-physics; this is relatively easy, because the code in CCPP is almost identical to to the current code in the dycore
    • GFDL is running its microphysics entirely inside the dycore in some experiments, not just the saturation adjustment. This is currently not required for EMC, but we should test that this works with CCPP.
  • IPD (or GFS) data types in selected routines (mostly for IAU or dycore-fv3atm interaction)
    • IAU: the information required from the DDTs is limited to IAU namelist parameters and a few dimensions; we should be able to either pass those fields in individually or get them from the dycore
    • dycore-fv3atm interaction: this is in file atmosphere.F90, which is host model specific (i.e. acts like a cap; GFDL has a different version of this file), thus the use of either IPD or GFS DDTs is no problem
    • Note: the GFS_restart.F90 DDT is also used in external_ic.F90, which we didn't discuss
  • nwat=4 used for Ferrier-Aligo in dev/emc, but used for Kessler in GFDL branches (with different condensate species)
    • In the dycore, nwat is currently hardcoded to match a specific set of condensate species
    • For nwat=2 and nwat=6, we were "lucky" because all microphysics options with the same nwat settings also had the same condensate species
    • Not the case for Kessler (warm rain) MP in the GFDL branch and Ferrier-Aligo MP in the EMC branch, both have nwat=4
    • Need a long-term solution, for example: code that depends on available species and not on values of nwat? Other options?
  • Synchronization of code:
    • GFDL tends to cherry-pick commits from dev/emc into master instead of merging branches, this should not be a problem
    • Updating dev/emc from master should happen via merging
    • EMC needs to update/synchronize with the dev/emc branch in the GFDL fork frequently, e.g. monthly, independent of how many changes were made

Short-term actions:

  • After the current PR for NOAA-EMC dev/emc is merged (Remove IPD steps 3 and 5, Remove IPD steps 3 and 5 (cleanup preprocessor directives) #50) and the next public release from NOAA-GFDL master is made, Rusty will do a test merge of master into dev/emc to see how many conflicts there are and if those can be resolved easily
XiaqiongZhou-NOAA pushed a commit to XiaqiongZhou-NOAA/GFDL_atmos_cubed_sphere that referenced this issue Jan 15, 2021
Modify the halo extents of u and vt in the regional_boundary_update call
@bensonr
Copy link
Collaborator

bensonr commented Mar 29, 2021

This was completed with NOAA-GFDL:PR #75. This issue can be closed.

@climbfuji
Copy link
Author

This is an old issue, according to the latest comment from Mar 29, 2021, this was completed at that time, but I think the two branches have deviated again?

@junwang-noaa
Copy link
Collaborator

@climbfuji There is an ongoing effort to merge GFDL master tp dev/emc.

@junwang-noaa
Copy link
Collaborator

@climbfuji the dev/emc in EMC repo is synced with the GFDL's dev/emc branch. Can this issue be closed? Thanks

@climbfuji
Copy link
Author

@junwang-noaa This issue is about syncing dev/emc with master or main to avoid divergence between the different FV3 dycore branches, so I'd say no, it can't be closed.

@bensonr
Copy link
Collaborator

bensonr commented Feb 26, 2024

@climbfuji - we are in the process of trying to update dev/emc. The main sticking point that keeps a simple merge from being cleanly accomplished is the whole atmosphere updates and how there were initially implemented within the dev/emc branch.

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

No branches or pull requests

3 participants