search

NOAA-EMC / CMEPS

NUOPC Community Mediator for Earth Prediction Systems
https://escomp.github.io/CMEPS/
0 stars 18 forks source link

Update CMEPS for HAFS-MOM6 coupling #90

Closed binli2337 closed 6 months ago

binli2337 commented 1 year ago

Description of changes

The CMEPS will be updated to add the following features:

  1. Capable of coupling both FV3ATM and CDEPS datm to MOM6 at the same time. In the overlapped regions (where FV3ATM domain and MOM6 domain overlap), the MOM6 model receives flux fields from FV3ATM. In the non-overlapped regions, the MOM6 model receives flux fields from GFS forcing through CDEPS datm.
  2. Capable of coupling both FV3ATM and CDEPS datm to WW3 at the same time. In the overlapped regions (where FV3ATM domain and WW3 domain overlap), the WW3 model receives 10m wind fields from FV3ATM. In the non-overlapped regions, the WW3 model receives the 10m wind fields from GFS forcing through CDEPS datm.

Specific notes

Contributors other than yourself, if any:

CMEPS Issues Fixed #89

Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial) No

Any User Interface Changes (namelist or namelist defaults changes)? No

Testing performed

Testing performed if application target is CESM:

Testing performed if application target is UFS-coupled:

Testing performed if application target is UFS-HAFS:

DeniseWorthen commented 1 year ago

@binli2337 I wanted to ask if you've made any progress on implementing the ability to use in-line CDEPS in the MOM6 and WW3 NUOPC caps? The relevant section of the CDEPS documentation is here

As we discussed, the current implementation in this PR is very problematic. On the UFS side, it fragments the use of CMEPs in UFS even more so than it already is. We should not have configuration specific coupling w/in the UFS part of CMEPS. CMEPS should not need to know about "apps", only components. And the more we carve out one-off configuration specific code, the more fragile and hard to maintain the code becomes. As the CMEPS code manager I think this PR takes us in the opposite direction that we need to go.

At the broader scale, this change also breaks the CMEPS design philosophy, which means we will not be able to push back to ESCOMP. The way you've implemented it essentially replicates a functionality that was specifically added to CDEPS to address the need for obtaining "outside" information. Adding the capability to the MOM6/WW3 caps is the direction we need to move with this.

DeniseWorthen commented 1 year ago

@BinLiu-NOAA @junwang-noaa I was able to tag-up w/ @mvertens briefly this morning regarding some of the ideas raised yesterday in our conversation. Many of the features you named as being desired in the future (nested coupling, moving nests etc) would require fairly substantial design work in order to be incorporated into CMEPS and probably need to include help from the ESMF core team.

As I understand it though, putting a "merge_import" functionality into the MOM6 and WW3 cap (the ww3 cap already has this capability for a binary data source file) by making use of the in-line CDEPs data-stream API would work in your current use case. It would also benefit the broader community by adding regional capabilities to these components. And, finally, it would not break our ability to push back to ESCOMP.

Discussions about future capabilities that might be required for HAFS coupling could then begin. I don't really think it is possible at this stage to say we actually know the best approach to bringing some of these more complex features into CMEPS. There are certainly some interesting problems to solve.

jedwards4b commented 1 year ago

I am confused that you are continuing to work on this PR instead of the taking the preferred approach that we discussed and that was outlined by @DeniseWorthen

mvertens commented 1 year ago

@binli2337 - I agree with @jedwards4b. I do not see this PR as something we would want to bring into ESCOMP CMEPS given the other approach we all discussed previously.

BinLiu-NOAA commented 1 year ago

@DeniseWorthen, @jedwards4b, @mvertens, @uturuncoglu, @junwang-noaa, @binli2337, This is just a note.

As @DeniseWorthen mentioned, after our June 20th's telecom discussion, @junwang-noaa, @DeniseWorthen, and myself had a short/brief conversation/discussion on June 11th before @DeniseWorthen and @junwang-noaa left for their leaves. We did discuss/brainstorm the different approaches of supporting regional earth-system coupled modeling, for which the special challenges include how to better deal with the situation of the component models (atm, ocn, wav, etc.) having non-overlapped model domains, and how to enable the support of both atmospheric parent and nest domains direct coupling with other components (ocn, wav, etc.). Besides, we will also need consider the capability of restarting/warm-starting the regional coupled system in the ufs-weather-model. And all of these could be related to other coupling capability related developments (e.g., exchange grid, flux calculation within CMEPS) as well. Currently, there are both pros and cons for the different approaches we discussed/brainstormed so far. Unfortunately, we have not yet reached a consensus on which might be an easy/practical/optimized method to move forward with. With that, we agreed and would like to have some follow-up discussions once @junwang-noaa is back in early August.

Meanwhile, since we will need to use @binli2337's current development of regional FV3ATM-MOM6 coupling capability in our 2023 HFIP HAFS real-time parallel experiment starting August 1st, @binli2337 is currently doing some cleanup, unification, and enabling the capabilities needed for this year HAFS real-time parallel experiments based on his current implementation/approach of the CMEPS/CDEPS based HAFS FV3ATM-MOM6 coupling.

Again, after the upcoming discussions, once we agree, choose, or figure out a plan/approach to better support ufs-weather-model's regional/nesting coupling capabilities, we can then discuss the roadmap and technical details of implementing the approach for the corresponding ufs-weather-model components.

Thanks a lot for your comments/suggestions!

P.S., @binli2337, given that we have not yet reached a consensus on how to implement these regional coupling capabilities, I think you probably can consider converting this open PR into a draft PR. Thanks!

DeniseWorthen commented 1 year ago

@BinLiu-NOAA @binli2337 It is extremely unfortunate that this development work was done w/o creating an issue or discussing w/ the broader CMEPS community how to best implement this type of feature. The Issue describing this feature was opened the same day as the PR. That is not how community development works.

My concern is that if you continue down this path, you will invest more and more time in the current implementation, which gets us no closer to being able to push back to ESCOMP. There is consensus on that.

If in-line CDEPS will work for the current needs of development work, that is where the development effort should be focussed (with issues created in both WW3 and MOM6 repos). Delaying getting started on that work will simply compound the problem.

uturuncoglu commented 1 year ago

@BinLiu-NOAA @DeniseWorthen Just for heads up, there is a project (Advancing the Lake-Coupling Techniques for the Unified Forecast System (UFS) - NOAA/OAR) that aims to provide FVCOM generated lake temperature and sea ice information (over Great Lakes region) to FV3. As a part of the discussion, this might require bring inline CDEPS capability to FV3 that will also help for the FV3ATM-MOM6 coupling case. So, it think it is worth to discuss it since this capability could help to multiple applications and rather than supporting single special application, it would be nice to have more generic approach. Anyway, I just want to let you know about that project that I'll probably help to them.

BinLiu-NOAA commented 1 year ago

Thanks @DeniseWorthen and @uturuncoglu for the comments and information!

And I agree, this is basically for regional coupling capability in general (not necessarily for HAFS only, it could apply to any UFS regional applications or other CMEPS-based regional coupling applications). Let's have some more discussions/brainstorming on the strategy/design/planning for this kind of regional coupling capabilities.

Thanks!

DeniseWorthen commented 1 year ago

@uturuncoglu Just to be clear, this is in-line CDEPs capability added to the FV3-cap?

uturuncoglu commented 1 year ago

@DeniseWorthen Yes. That is the idea. We discussed it with @mvertens too and it seems it is better to go with this idea to make it as generic. I'll have a meeting today with the Christiane Jablonowski (PI of the project) to discuss more. It will require extra development in FV3 side but I think it worths to it. We could have more discussion as a group if you want.

DeniseWorthen commented 6 months ago

Closing; replaced by PR #109 containing capability in inline-cdeps