You are here: Home / News & Events / DKRZ Tech Talks / DKRZ Tech Talk: The Coupling Library YAC

DKRZ Tech Talk: The Coupling Library YAC

Moritz Hanke (DKRZ) and René Redler (MPI-M) will give an overview on the functionality of YAC and some details on how to use it. Additionally, the talk will include information on how YAC is used within the Icosahedral Nonhydrostatic (ICON) general circulation model, which is YAC's main user.
  • DKRZ Tech Talk: The Coupling Library YAC
  • 2021-01-19T15:15:00+01:00
  • 2021-01-19T16:15:00+01:00
  • Moritz Hanke (DKRZ) and René Redler (MPI-M) will give an overview on the functionality of YAC and some details on how to use it. Additionally, the talk will include information on how YAC is used within the Icosahedral Nonhydrostatic (ICON) general circulation model, which is YAC's main user.
When
Jan 19, 2021 from 03:15 PM to 04:15 PM (Europe/Berlin / UTC100)
Add event to calendar
iCal

YAC (Yet Another Coupler) is a lightweight software library, which has been developed to realise the coupling of Earth system model components. The software provides parallelised two-dimensional neighbourhood search, interpolation, and communication for the coupling between any two model components. The software offers flexible coupling of physical fields defined on regular and irregular grids on the sphere without a priori assumptions about grid structure or grid element types. All supported grids can be combined with any of the various supported interpolations.
The tech talk will give an overview on the available functionality and some details on how to use it. Additionally, the talk will include information on how YAC is used within the Icosahedral Nonhydrostatic (ICON) general circulation model, which is YAC's main user.

Please find the recording of this talk at https://youtu.be/Vu00CkoEt_c.

Find more information at https://www.dkrz.de/services/software-development

Questions and Answers:

  • has the performance been tested on any other architecture than Mistral, in particular on vector processors?

    • Moritz: No. It is not specifically optimised for other architectures.

    • There is an SX test system at DKRZ, afaik.

      • Moritz: I have not yet tested on that one.

  • Can YAC be (and has it been) used in a hybrid coupled environment, i.e. one that uses OASIS or ESMF together with YAC?

    • Moritz: None of the couplers can communicate between each other. I do not know of any setup where two couplers are used at the same time.

    • Moritz: We (Ralf Müller(DKRZ) and myself) are planning to work on a NEMO-ICON-YAC setup as a proof of concept.

      • So is this hybrid OASIS/YAC?

      • Moritz: No, at that start of the run you have to select one of them, the other will not be used….Well depends on what you call hybrid.

      • Talking to people at OASIS and ESMF, it seems that it is in principle possible with MPI_COMM_SPLIT and each operating in its own MPI environment. It just hasn't been done.

        • Moritz: Yes, that would be possible, this way they can work alongside each other...does it make sense?

  • Would it be possible to make YAC look like OASIS from outside to be able to couple also other models than NEMO which are currently coupled via OASIS? And If so, can you roughly estimate how much PMs would be necessary?

    • Moritz: Yes, it would be possible to make it look similar. I do not like to do this. However, within ICON the calls to YAC are for example already within its own module, which should be similar to other models. This is already somewhat of an abstraction layer.

    • Moritz: Within the ESM-Tool this was already done. -> Ask Nadine Wieters.

  • Did I hear it correctly that “patch recovery” is not going to be included in version 2.0? If so, is there an alternative? Or is there no need to “patch recovery” sort of tool for version 2.0?

    • Moritz: Yes, there are currently no plans to include it in YAC2. It is being replaced with HCSBB, which is from our perspective better. The results from the CERFACS analysis should underline this.

    • What does HCSBB stand for?

    • Moritz: If really necessary, it would be no problem to include patch recovery.

  • As a biogeochemical modeler, I would typically exchange O(30) fields between components. It seems tedious to configure each field individually in the .xml. Is there some templating or autogeneration of the coupling details for fields? Better yet, is there a facility for online-generation of the list of fields to be exchanged (e.g. for the FABM framework that does environmental/external dependency resolution at runtime)?

    • Moritz: There is no tool for auto-generation of the configuration file. But the respective C-code is really not that complicated. You could also write a simple script.

    • Moritz: If the respective fields are all exchanged at the same time with the same interpolation stack, you can exchange them within a bundle of fields at the same time using the same interpolation.

    • Moritz: “facility for online-generation of the list of fields” is not available, but it is no problem to generate the XML online before the initialisation of YAC.

      • So it's a hen and egg problem, since I need to initialize YAC before any components :=(

      • Moritz: You could define in the configuration file more couplings than you actually use in the end. YAC does not mind.

  • What interfaces/APIs do you provide beyond Fortran. Is there a C/C++ interface, how about python and Java?

    • Moritz: YAC is written in C. Therefore, we have a C interface. Additionally, we have a Fortran interface. Currently, no other interfaces are planned.

  • What license is this project under? And is it openly accessible (do I need a DKRZ account)?

    • Rene: BSD

    • Moritz: Contact us in case it does not work

Document Actions