the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 05 Sep 2024
A non-intrusive, multi-scale, and flexible coupling interface in WRF
Abstract. The Weather Research and Forecasting (WRF) model has been widely used for various applications, especially for solving mesoscale atmospheric dynamics. Its high-order numerical schemes and nesting capability enable high spatial resolution. However, a growing number of applications are demanding more realistic simulations through the incorporation of coupling with new model compartments and an increase in the complexity of the processes considered in the model. (e.g., ocean, surface gravity wave, land-surface, chemistry...). The present paper details the development and the functionalities of the coupling interface we implemented in WRF. It uses the Ocean-Atmosphere-Sea-Ice-Soil – Model Coupling Toolkit (OASIS3-MCT) coupler, which has the advantage of being non-intrusive, efficient, and very flexible to use. OASIS3-MCT has already been implemented in many climate and regional models. This coupling interface is designed with the following baselines: (1) it is structured with a 2-level design through 2 modules: a general coupling module, and a coupler-specific module, allowing to easily add other couplers if required, (2) variables exchange, coupling frequency, and any potential time and grid transformations are controlled through an external text file, offering great flexibility, (3) the concepts of “external domains” and “coupling mask” are introduced to facilitate the exchange of fields to/from multiple sources (different models, fields from different models/grids/zooms...). Finally, two examples of applications of ocean-atmosphere coupling are proposed. The first is related to the impact of ocean surface current feedback to the atmospheric boundary layer, and the second concerns the coupling of surface gravity waves with the atmospheric surface layer.
- Preprint
(1649 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
RC1: 'Comment on gmd-2024-140', Anonymous Referee #1, 28 Sep 2024
This paper is a summary of the implemented OASIS3-MCT coupling interface implemented in WRF. The design of the interface is introduced in detail with two examples demonstrating the implemented framework. This work is very useful for modelers to develop coupled models. It is also important for scientists to understand the ocean-atmosphere interactions. I did not read or test all the code provided by the authors, but the code is written and documented in a good manner. The code is very clear and self-explanatory. The paper is also very well written. I only have a few minor concerns before publishing this work:
- For the implementations described in Section 2, the implemented interface is specifically developed for WRF v4.6.0. If so, are there any plans to maintain this interface for higher or lower versions of WRF? Would it be easy to implement this interface for other WRF versions?
- Line 155 is confusing to me. Do the authors separate the WRF code into three subroutines (init, run, finalize)? Or do the authors put functions in“frame/module_cpl_oasis3.F” used in these processes?
- Are the authors using the existing WRF I/O streams (auxinput or auxhist) when getting the input or output? Why don’t use the existing ones?
- Line 236, when in the coupled experiment. I feel it is challenging to use WRF IO quilting when using the same processors for both Ocean and Atmosphere models. How should the ocean model set these processors for IO quilting? Have the authors tested this?
- Section 3.3. Are the users free to add more variables for the coupling processes?
- Section 4.1.3 is a very interesting example. Has anyone tested the nested domains in a realistic application? In addition, in Fig. 19 the filled color and the color of the boxes are very close. It would be better if the author could use a different colormap for the masks.
- In Appendix 2, there is a typo in https://github.com/massonseb/WRF/blob/GMD_wrf_coupling/run/namecouple_example. It should be https://github.com/massonseb/WRF/blob/GMD_wrf_coupling/run/namcouple_example.
Citation: https://doi.org/10.5194/gmd-2024-140-RC1 -
RC2: 'Comment on gmd-2024-140', Anonymous Referee #2, 11 Oct 2024
This technical paper describes the interface between WRF and the OASIS coupler (although the interface is conceived for use with any other coupler). It is clear, well-written, and interesting for the WRF and regional climate modeling community. I recommend it for publication after a few very minor issues are addressed.
- The mention of the “most popular model” regarding WRF appears subjective (Short summary, and beginning); unless this is proven, suggest rephrasing L38: “among the most popular…” in both occurrences.
- L38: not convinced that “numerical performances” are among the main reasons for the success of WRF. Unless the latest versions have changed this, WRF is known for limited scalability.
- L61 please introduce the acronym C-Coupler used later
- L83 the sentence “The de facto” needs to be rephrased for clarity
- Section 2.3 refers to the standard OASIS functionalities. This needs to be stated clearly; also, the associated schemes (fig3) and text do not consider any delay (LAG) in the time-stepping to exchange fields and avoid deadlock communication. I recommend adding a discussion on that, which could be useful for many users.
- L200 decision -> strategy
- In Table 2, every interpolation method is given also with the “F” (BICUBIC and BICUBICF) without explaining the meaning
- L281 as shown in Figure 9.
- It is not clear why the use of relative wind is implemented only in two PBL schemes, and not in all; is there a specific reason? Can the authors at least say how to do it for the other schemes?
- The same applies to the Charnock coefficient in the Revised MM5 Monin-Obukhov surface scheme, which could be discussed in more detail. What about other schemes?
- L631 “other kinds”
- In general, the technical paper will be very useful if associated with realistic examples collected by the authors and the community (in terms of masks, grids, namelists). The example provided in the github is quite limited (exchanges of only SST and TAUX); having at least two complete configuration examples (e.g., one with no nested domains and one with), complete as in realistic applications of all domain and grid files, the scripts to generate them and the associated namelists to run, could be very useful to guide users in their implementations.
Citation: https://doi.org/10.5194/gmd-2024-140-RC2 -
CEC1: 'Comment on gmd-2024-140', Astrid Kerkweg, 18 Oct 2024
Dear authors,
in my role as Executive editor of GMD, I would like to bring to your attention our Editorial version 1.2: https://www.geosci-model-dev.net/12/2215/2019/
This highlights some requirements of papers published in GMD, which is also available on the GMD website in the ‘Manuscript Types’ section: http://www.geoscientific-model-development.net/submission/manuscript_types.html
In particular, please note that for your paper, the following requirement has not been met in the Discussions paper:
- "The main paper must give the model name and version number (or other unique identifier) in the title."
Please add a version number for WRF in the title upon your revised submission to GMD.
Finally note, that according to our new Editorial (v1.2) all data and analysis / plotting scripts should be made available.
Yours,
Astrid Kerkweg
Citation: https://doi.org/10.5194/gmd-2024-140-CEC1
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 267 | 62 | 89 | 418 | 2 | 3 |
- HTML: 267
- PDF: 62
- XML: 89
- Total: 418
- BibTeX: 2
- EndNote: 3
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1