the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 28 Jun 2022
Ocean Modeling with Adaptive REsolution (OMARE, version 1.0) – Refactoring NEMO model (version 4.0.1) with the parallel computing framework of JASMIN. Part 1: adaptive grid refinement in an idealized double-gyre case
Abstract. High-resolution models have become widely available to study ocean’s small-scale processes. Although these models simulates more turbulent ocean dynamics and reduces uncertainties of parameterizations, they are not practical for long-term simulations, especially for climate studies. Besides scientific research, there are also growing needs from key applications for multi-resolution, flexible modeling capabilities. In this study we introduce the Ocean Modeling with Adaptive REsolution (OMARE), which is based on refactoring NEMO with a parallel computing framework of JASMIN. OMARE supports adaptive mesh refinement (AMR) for the simulation of the multi-scale ocean processes with improved computability. We construct an idealized, double-gyre test case, which simulates a western-boundary current system with seasonally changing atmospheric forcings. This paper (part 1) focuses on the ocean physics simulated by OMARE at two refinement scenarios: (1) 0.5°–0.1° with static refinement and the transition from laminar to turbulent, eddy rich ocean, and (2) short-term 0.1°–0.02° AMR experiments which focus on submesoscale processes. Specifically, for the first scenario, we show that the ocean kinematics on the refined, 0.1° region is sensitive to the choice of refinement region within the low-res., 0.5° basin. Furthermore, for the refinement to 0.02°, we adopt refinement criteria for AMR based on surface velocity and vorticity. Results show that temporally changing features at the ocean’s mesoscale, as well as submesoscale process and its seasonality, are well captured through AMR. Related topics and future plans of OMARE, including overlaying in AMR, are further discussed for further oceanography studies and applications.
-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(79162 KB)
-
Supplement
(190892 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(79162 KB) - Metadata XML
-
Supplement
(190892 KB) - BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
CEC1: 'Comment on egusphere-2022-510', Juan Antonio Añel, 11 Aug 2022
Dear authors,
First of all, thanks for trying to solve the issues pointed out by Dr Farnetti about code and data availability. I have reviewed your manuscript and found some additional problems with the code in your manuscript. First, the webpage for JASMIN is in Chinese, and there is no option for a different language. This is the webpage to apply for the use of the software, however, the fact that it is not in English excludes most of our readership. It would be good if you could provide a translated option. However, this is not the major issue. You state that JASMIS is "closed source", which is not enough to comply with our policy: we need to know why it is closed, and we need evidence about what is limiting the authors of the paper from sharing it.
Please, reply to this comment as soon as possible with the relevant information, as the code should be available for the full Discussions stage to anyone.
Many thanks,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2022-510-CEC1 -
AC1: 'Reply on CEC1', Shiming Xu, 15 Aug 2022
We sincerely thank the Chief Editor's comment. The reply is provided in the attachment.
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 15 Aug 2022
Dear authors,
First, many thanks for your reply. I sincerely thank your thoughtful comment. We understand the situation. Providing the code can be considered to comply with our policy; however, the use of closed platforms or software for scientific research continues to violate scientific replicability. I understand that a company like NVIDIA is providing privative software (an unfortunate outcome of the current software business model); however, it is not clear to me at this point what prevents JASMIN developers from releasing their code. As you state in your reply, some of you are affiliated with IAPCM; therefore, I would like to know why these authors can not release JASMIN or why they can not ask the IAPCM to do it.
Beyond this, if there is a good reason that makes it impossible to publish JASMIN, please, indicate the exact JASMIN version used for this work. Also, we need to have evidence that you will store it internally (ideally with a DOI) to be sure that the future reproducibility of your work is not compromised.
As a personal comment, if JASMIN is not published finally, I recommend you avoid using such software for future research, as it does not comply with the principles of the scientific method.Best regards,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2022-510-CEC2 - AC2: 'Reply on CEC2', Shiming Xu, 21 Aug 2022
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 15 Aug 2022
-
AC1: 'Reply on CEC1', Shiming Xu, 15 Aug 2022
-
CEC3: 'Comment on egusphere-2022-510', Juan Antonio Añel, 22 Aug 2022
Dear authors,
Again, thanks for your reply. I understand what you expose; however, beyond a statement on who to contact to access JASMIN, you do not provide evidence of how it is stored internally by the IAPCM, nor a DOI for it. Does IAPCM maintain a dedicated internal repository for curated software? To be more clear, we need to be sure that this is not simply stored by somebody in their personal account, computer or server, but institutionally backed to avoid failing to contact a person makes it impossible to recover it. And we would like some kind of evidence or official statement about it. For example, this is information sometimes contained in the web portal to apply for the software. A DOI is easy to get, and the IAPCM should not have a problem getting one for the JASMIN version you use.
Also, in any potential reviewed version of your manuscript, please change the repository you cite for NEMO. NEMO is already stored in Zenodo: https://zenodo.org/record/3878122, and this is a better choice to cite, a permanent repository that complies with our policy. I should note that the Zenodo repository contains version 4.0; however, it does not include version 4.0.1 that you use. You could ask the maintainers of the NEMO repository to upload version 4.0.1, as it is necessary for your work, or maybe you can upload it to a new repository.
Regards,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2022-510-CEC3 -
RC1: 'Comment on egusphere-2022-510', Anonymous Referee #1, 24 Aug 2022
I find the approach proposed in the manuscript to be of interest for the journal. It follows the now discussed road of separation of concerns, whereby the code part dealing with numerical algorithms and the part dealing with the infrastructure (mesh, parallelization) are separated and treated in different ways. However, the manuscript in its present form misses the goal: one expects that the material of the manuscript describing a modeling approach will be sufficient for a reader to learn how to use the approach. I do not see that this goal is reached.
The text on lines 165 - 190 shortly describes how the JASMIN is involved, but I doubt a reader can get any understanding of what and why is done. Moreover, it is not at all clear how to use JASMIN in conjunction with the updated code. How the JASMIN environment can be installed, how code is compiled, etc. The description should be essentially extended and be such that those who are willing to follow author's approach can do it.
The manuscript devotes more than a half of its volume to the description of simple test configuration, going into too much detail, which is hardly optimal. The test case remains the test case, and one can only learn that the approach proposed by the authors is working, yet not without drawbacks related to one-way nesting (the development of errors on fine-coarse boundary). I do not think that this test case is well suited to demonstrate the need of adaptivity. Figure 11 shows clearly that small-scale turbulence occupies 3/4 domain on full mesh, and it occupies only pieces where the resolution is refined in b and c. It is different from the initial phases in Fig. 9 and 10, but 5 or 20 days is a too short time for turbulence to equilibrate, and this transient phase is of no interest (it depends on coarse initial conditions, and does not model any reality). So the conclusion here is that dynamic adaptivity is an interesting, but perhaps not very needed possibility as concerns eddying flows. Static refinement might be doing the work, and one will take a decision where to resolve based on one interest. I foresee, however, one direction, where dynamic refinement still might be of interest -- the simulations of seasonal course of variability. Submesoscale eddies might be suppressed in warm seasons, and a coarser mesh will be sufficient for mesoscale. My recommendation are to make the experimental part more compact. One can hardly learn anything from detailed description of particular eddy features or the comparison of transects (Fig. 13, 14), and there is very little sense in Fig. 9 and 10.
Please also check the text: there are numerous cases when plural/singular and some terms (e.g. kinematics) are used inappropriately.Citation: https://doi.org/10.5194/egusphere-2022-510-RC1 - AC4: 'Reply on RC1', Shiming Xu, 18 Dec 2022
-
RC2: 'Comment on egusphere-2022-510', Anonymous Referee #2, 02 Dec 2022
The manuscript by Zhang et al describes an implementation of a nested regional ocean modeling capability using the parallel computing framework “J Parallel Adaptive Structure Mesh Applications Infrastructure” (JASMIN). They demonstrate the application of the implementation with simulations in an idealized basin double gyre configuration. The presentation is generally clear and the authors provide a realistic assessment of the remaining challenges with this particular implementation as well as for nested ocean modeling generally. My only significant concern with the study is that the entire work is based on a proprietary software stack, making the reproducibility and accessibility of the effort to the broader community questionable.
I suggest below a few additional points and questions that I believe would be helpful to a reader. The grammatical construction (e.g. singular/plural usage) of the text is a little rough in places and could use some polishing by a technical editor. I have no substantial concerns with the manuscript as written and recommend publication after minor revision.
Line 31: “Other ensuing practice …” ?? Not right words here
Line 37: “In the following up part of the paper …” -> In this paper ….
Line 58: suite -> suit
Line 70 ASMIN -> JASMIN
Line 114-119: It would be helpful to actually state the man-months of effort required to complete the refactorization.
Line 128: 422 patches … Might be helpful to state where this number comes from .. (# of variables) * (# of grid hierarchy levels) * (???)
Line 131, 133, 175 : Figure 3 should be Figure 1 or Listing 1?
Line 180: does level here refer to depth level or grid hierarchy level?
Line 295, Figure 5. Label the figures with the case name or include identifiers in the caption.
Line 296: “Besides, L-M-I covering more area in the subtropical gyre “ This seems backwards from the figure. Poor sentence construction.
Section 3.3: A key conclusion of this section is that the mis-representation of APE->KE transfer in the eddy-parameterized parent-grid leads to boundary forcing biases in the child grid. Later in the paper, the authors allude to the need for a GM-type parameterizations in this regime. Does the implementation support different parameterization methods at different levels of the hierarchy (they show that different parameter values can be used)? An additional case with GM turned on in the 0.5 degree grid would be informative of the suitability of this approach with a scale aware parameterization strategy.
Line 346: “proxies” Not sure this is the correct word here. I believe you mean something more like “metrics of grid quality”
Line 398: bu -> by
Line 423: LaTex typo for circle symbol
Line 424 : “following up part” -> following partLine 442: We pick the a -> We pick a
Line 474: This is indicated by that both … -> This is indicated by the fact that both …
Line 505-514: Could alternatively provide an estimate of the man-months of effort here.
Line 529: (Section on refinement criteria) : Some description of how the current implenmexation aggregates points into individual patches would be helpful.
Line 597 ( Section on realistic cases): Some discussion of challenges expected with realistic topography and coastlines would be helpful. Would topography or the coastline be refined along with the grid? How would mismatches in land-ocean boundaries across hierarchy levels at the lateral boundary be handled?
Other: I presume some data on scalability and performance will be presented in the companion manuscript, but a very brief statement about this would be helpful to make the present manuscript self-contained.
Citation: https://doi.org/10.5194/egusphere-2022-510-RC2 - AC3: 'Reply on RC2', Shiming Xu, 17 Dec 2022
- AC5: 'Summary to the reply of comments on egusphere-2022-510', Shiming Xu, 18 Dec 2022
Interactive discussion
Status: closed
-
CEC1: 'Comment on egusphere-2022-510', Juan Antonio Añel, 11 Aug 2022
Dear authors,
First of all, thanks for trying to solve the issues pointed out by Dr Farnetti about code and data availability. I have reviewed your manuscript and found some additional problems with the code in your manuscript. First, the webpage for JASMIN is in Chinese, and there is no option for a different language. This is the webpage to apply for the use of the software, however, the fact that it is not in English excludes most of our readership. It would be good if you could provide a translated option. However, this is not the major issue. You state that JASMIS is "closed source", which is not enough to comply with our policy: we need to know why it is closed, and we need evidence about what is limiting the authors of the paper from sharing it.
Please, reply to this comment as soon as possible with the relevant information, as the code should be available for the full Discussions stage to anyone.
Many thanks,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2022-510-CEC1 -
AC1: 'Reply on CEC1', Shiming Xu, 15 Aug 2022
We sincerely thank the Chief Editor's comment. The reply is provided in the attachment.
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 15 Aug 2022
Dear authors,
First, many thanks for your reply. I sincerely thank your thoughtful comment. We understand the situation. Providing the code can be considered to comply with our policy; however, the use of closed platforms or software for scientific research continues to violate scientific replicability. I understand that a company like NVIDIA is providing privative software (an unfortunate outcome of the current software business model); however, it is not clear to me at this point what prevents JASMIN developers from releasing their code. As you state in your reply, some of you are affiliated with IAPCM; therefore, I would like to know why these authors can not release JASMIN or why they can not ask the IAPCM to do it.
Beyond this, if there is a good reason that makes it impossible to publish JASMIN, please, indicate the exact JASMIN version used for this work. Also, we need to have evidence that you will store it internally (ideally with a DOI) to be sure that the future reproducibility of your work is not compromised.
As a personal comment, if JASMIN is not published finally, I recommend you avoid using such software for future research, as it does not comply with the principles of the scientific method.Best regards,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2022-510-CEC2 - AC2: 'Reply on CEC2', Shiming Xu, 21 Aug 2022
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 15 Aug 2022
-
AC1: 'Reply on CEC1', Shiming Xu, 15 Aug 2022
-
CEC3: 'Comment on egusphere-2022-510', Juan Antonio Añel, 22 Aug 2022
Dear authors,
Again, thanks for your reply. I understand what you expose; however, beyond a statement on who to contact to access JASMIN, you do not provide evidence of how it is stored internally by the IAPCM, nor a DOI for it. Does IAPCM maintain a dedicated internal repository for curated software? To be more clear, we need to be sure that this is not simply stored by somebody in their personal account, computer or server, but institutionally backed to avoid failing to contact a person makes it impossible to recover it. And we would like some kind of evidence or official statement about it. For example, this is information sometimes contained in the web portal to apply for the software. A DOI is easy to get, and the IAPCM should not have a problem getting one for the JASMIN version you use.
Also, in any potential reviewed version of your manuscript, please change the repository you cite for NEMO. NEMO is already stored in Zenodo: https://zenodo.org/record/3878122, and this is a better choice to cite, a permanent repository that complies with our policy. I should note that the Zenodo repository contains version 4.0; however, it does not include version 4.0.1 that you use. You could ask the maintainers of the NEMO repository to upload version 4.0.1, as it is necessary for your work, or maybe you can upload it to a new repository.
Regards,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2022-510-CEC3 -
RC1: 'Comment on egusphere-2022-510', Anonymous Referee #1, 24 Aug 2022
I find the approach proposed in the manuscript to be of interest for the journal. It follows the now discussed road of separation of concerns, whereby the code part dealing with numerical algorithms and the part dealing with the infrastructure (mesh, parallelization) are separated and treated in different ways. However, the manuscript in its present form misses the goal: one expects that the material of the manuscript describing a modeling approach will be sufficient for a reader to learn how to use the approach. I do not see that this goal is reached.
The text on lines 165 - 190 shortly describes how the JASMIN is involved, but I doubt a reader can get any understanding of what and why is done. Moreover, it is not at all clear how to use JASMIN in conjunction with the updated code. How the JASMIN environment can be installed, how code is compiled, etc. The description should be essentially extended and be such that those who are willing to follow author's approach can do it.
The manuscript devotes more than a half of its volume to the description of simple test configuration, going into too much detail, which is hardly optimal. The test case remains the test case, and one can only learn that the approach proposed by the authors is working, yet not without drawbacks related to one-way nesting (the development of errors on fine-coarse boundary). I do not think that this test case is well suited to demonstrate the need of adaptivity. Figure 11 shows clearly that small-scale turbulence occupies 3/4 domain on full mesh, and it occupies only pieces where the resolution is refined in b and c. It is different from the initial phases in Fig. 9 and 10, but 5 or 20 days is a too short time for turbulence to equilibrate, and this transient phase is of no interest (it depends on coarse initial conditions, and does not model any reality). So the conclusion here is that dynamic adaptivity is an interesting, but perhaps not very needed possibility as concerns eddying flows. Static refinement might be doing the work, and one will take a decision where to resolve based on one interest. I foresee, however, one direction, where dynamic refinement still might be of interest -- the simulations of seasonal course of variability. Submesoscale eddies might be suppressed in warm seasons, and a coarser mesh will be sufficient for mesoscale. My recommendation are to make the experimental part more compact. One can hardly learn anything from detailed description of particular eddy features or the comparison of transects (Fig. 13, 14), and there is very little sense in Fig. 9 and 10.
Please also check the text: there are numerous cases when plural/singular and some terms (e.g. kinematics) are used inappropriately.Citation: https://doi.org/10.5194/egusphere-2022-510-RC1 - AC4: 'Reply on RC1', Shiming Xu, 18 Dec 2022
-
RC2: 'Comment on egusphere-2022-510', Anonymous Referee #2, 02 Dec 2022
The manuscript by Zhang et al describes an implementation of a nested regional ocean modeling capability using the parallel computing framework “J Parallel Adaptive Structure Mesh Applications Infrastructure” (JASMIN). They demonstrate the application of the implementation with simulations in an idealized basin double gyre configuration. The presentation is generally clear and the authors provide a realistic assessment of the remaining challenges with this particular implementation as well as for nested ocean modeling generally. My only significant concern with the study is that the entire work is based on a proprietary software stack, making the reproducibility and accessibility of the effort to the broader community questionable.
I suggest below a few additional points and questions that I believe would be helpful to a reader. The grammatical construction (e.g. singular/plural usage) of the text is a little rough in places and could use some polishing by a technical editor. I have no substantial concerns with the manuscript as written and recommend publication after minor revision.
Line 31: “Other ensuing practice …” ?? Not right words here
Line 37: “In the following up part of the paper …” -> In this paper ….
Line 58: suite -> suit
Line 70 ASMIN -> JASMIN
Line 114-119: It would be helpful to actually state the man-months of effort required to complete the refactorization.
Line 128: 422 patches … Might be helpful to state where this number comes from .. (# of variables) * (# of grid hierarchy levels) * (???)
Line 131, 133, 175 : Figure 3 should be Figure 1 or Listing 1?
Line 180: does level here refer to depth level or grid hierarchy level?
Line 295, Figure 5. Label the figures with the case name or include identifiers in the caption.
Line 296: “Besides, L-M-I covering more area in the subtropical gyre “ This seems backwards from the figure. Poor sentence construction.
Section 3.3: A key conclusion of this section is that the mis-representation of APE->KE transfer in the eddy-parameterized parent-grid leads to boundary forcing biases in the child grid. Later in the paper, the authors allude to the need for a GM-type parameterizations in this regime. Does the implementation support different parameterization methods at different levels of the hierarchy (they show that different parameter values can be used)? An additional case with GM turned on in the 0.5 degree grid would be informative of the suitability of this approach with a scale aware parameterization strategy.
Line 346: “proxies” Not sure this is the correct word here. I believe you mean something more like “metrics of grid quality”
Line 398: bu -> by
Line 423: LaTex typo for circle symbol
Line 424 : “following up part” -> following partLine 442: We pick the a -> We pick a
Line 474: This is indicated by that both … -> This is indicated by the fact that both …
Line 505-514: Could alternatively provide an estimate of the man-months of effort here.
Line 529: (Section on refinement criteria) : Some description of how the current implenmexation aggregates points into individual patches would be helpful.
Line 597 ( Section on realistic cases): Some discussion of challenges expected with realistic topography and coastlines would be helpful. Would topography or the coastline be refined along with the grid? How would mismatches in land-ocean boundaries across hierarchy levels at the lateral boundary be handled?
Other: I presume some data on scalability and performance will be presented in the companion manuscript, but a very brief statement about this would be helpful to make the present manuscript self-contained.
Citation: https://doi.org/10.5194/egusphere-2022-510-RC2 - AC3: 'Reply on RC2', Shiming Xu, 17 Dec 2022
- AC5: 'Summary to the reply of comments on egusphere-2022-510', Shiming Xu, 18 Dec 2022
Peer review completion
Journal article(s) based on this preprint
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 658 | 154 | 29 | 841 | 37 | 6 | 3 |
- HTML: 658
- PDF: 154
- XML: 29
- Total: 841
- Supplement: 37
- BibTeX: 6
- EndNote: 3
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Yan Zhang
Xuantong Wang
Yuhao Sun
Chenhui Ning
Dehong Tang
Hong Guo
Hao Yang
Ye Pu
Bin Wang
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(79162 KB) - Metadata XML
-
Supplement
(190892 KB) - BibTeX
- EndNote
- Final revised paper