the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 02 Jan 2024
StraitFlux – Precise computations of Water Strait fluxes on various Modelling Grids
Abstract. Oceanic transports shape the global climate, but the evaluation and validation of this key quantity based on reanalysis and model data is complicated by the distortion of the used curvilinear ocean model grids towards their displaced north poles. Combined with the large number of different grid types, this has made the exact calculation of oceanic transports a challenging and time-consuming task. Use of data on standard latitude/longitude grids is not an option since transports computed from those are not mass consistent. We present two methods for transport calculations on grids with variously shifted north poles, different orientations, and different Arakawa partitions. The first method calculates net transports through arbitrary sections using line integrals, while the second method generates cross-sections of the vertical-horizontal planes of these sections using vector projection algorithms. Apart from the input data on the original model grids the user only needs to specify the start and end points of the required section to get the net transports (with both methods) and their integrand (for the second method). This allows to calculate oceanic fluxes through almost arbitrary sections, to compare them with observed oceanic volume and energy transports at available sections such as the RAPID array or at Fram strait and other Arctic gateways, or to compare them amongst reanalyses and to model integrations from the Coupled Model Intercomparison Projects (CMIP).
We implemented our methods in a Python package called StraitFlux. This paper represents its scienfic documentation and demonstrates its application on outputs of multiple CMIP6 models and several ocean reanalyses. We also analyse the robustness and computational performance of the tools as well as the uncertainties of the results. The package is available on github and zenodo and can be installed using pypi.
- Preprint
(8057 KB) - Metadata XML
- BibTeX
- EndNote
Status: closed
-
RC1: 'Comment on egusphere-2023-2883', Anonymous Referee #1, 14 Feb 2024
This paper presents the python package StraitFlux, and demonstrates how it can be used to calculate ocean strait transports for various ocean model grids. It seems like a valuable and easy to use tool, and I appreciate the effort put into making this a public tool that can save other users a lot of time. I recommend that this manuscript is published after some clarifications are made:
L4-5: A bit unclear what you mean by this sentence. Are you referring to the complications from the singularity at the true North Pole? Or errors in fields that are interpolated to standard lat/lon grid?
L9: What exactly do you mean by the integrand for the second method? This word is not used for anything elsewhere in the manuscript.
Eq. (4) ice is mentioned here, but not any further. Would be good to discuss further, e.g. by including an example of ice transport in the paper if mentioning it here.
L86: Maybe briefly explain why closed volume transport is not generally the case?
Vector Projection Method: Is it using the same method for Arakawa A, B and C grids?
Fig 2b. One of the cells is not in contact with the red line. From the text I understand that only cells in contact with the line is used.
L124-126: Why do you convert velocities to transports and then after interpolation divide by the respective cell thicknesses to obtain velocities again, instead of just interpolating the velocities?
L155: How is a straight reference line drawn between the endpoints? Is it following the shortest/great-circle distance along a sphere? Or can it be defined to e.g. follow a specific latitude?
Write also somewhere how the example straits used in the paper are defined, e.g. specify the start and endpoints used. Or a latitude for the Fram Strait.
L167: How are the points i on the refline defined?
L230-231: I don’t understand why the difference between velocity components is taken? Has it something to do with correcting the positions on the Arakawa grid?
Fig 7: I cannot fully understand this figure, and how the angle alpha is defined. Intuitively, I would think u was defined negative if the absolute value of the angle between r and u_dir was more than 90 degrees.
L241-243: I don’t understand this sentence, and why the u and v components are scaled.
L293: What is ESMFgrid? Do you mean xesmf’s Regridder?
Fig 12. Maybe add in figure title or text that this is the Transports for the Fram Strait.
L339: ITF: please define abbreviation
If possible, can you sketch an example showing why interpolation methods make such large errors? Or cite eventual other papers who discuss why? I find it a little hard to imagine how interpolation errors can give such large errors in the net Arctic volume transport.
Typos:
L268: radiant - should be radians
L313: VPN – should be VPM
L360: Gitlab – maybe you mean github instead, since the urls provided go to github?
L373 i.a. – should be i.e. (?)
L383: northern most – cut space between words
L397: downlaoded – should be downloaded
Citation: https://doi.org/10.5194/egusphere-2023-2883-RC1 -
AC2: 'Reply on RC1', Susanna Winkelbauer, 19 Mar 2024
Thank you very much for your positive comments and constructive feedback, you addressed some important points. Your clarifications helped to make the manuscript clearer for the reader. Our responses are provided in the attached PDF.
We really appreciate your time and insight in reviewing our manuscript!Kind regards,
Susanna (on behalf of all co-authors)
-
AC2: 'Reply on RC1', Susanna Winkelbauer, 19 Mar 2024
-
RC2: 'Comment on egusphere-2023-2883', Shizhu Wang, 05 Mar 2024
Given the important roles of ocean circulation in shaping the climate system, correctly diagnosing the volume/salinity/heat transport in the ocean models is always important but complicated by different model grid configurations. Winkelbauer et al. present two new methods in calculating ocean transport, with one sticking to the original model grid lines and the other following strict vector projection and interpolation. Both methods work well with different Arakawa grids, and the results given by these two methods are very similar to assumed analytical results. And I would say the code is versatile in that users can define strait sections in different ways (to my understanding, 3 ways in defining the straits). What makes me more satisfied is that the code is organized into a Python package and maintained in GitHub, which facilitates its future upgrade and public use. Both the paper and the code are well written and I think the paper should be published after considering/answering my following suggestions/questions.
Major concerns:
I know that this is a scientific rather than a technical documentation, but some technical details are still needed to help the readers understand the calculation process.
- Line123-125: I have difficulty in understanding the processes given here. Are the transports or projection vectors “interpolated bilinearly onto the closest points on the reference line? Put it another way, after the projection vectors of all touched cells are calculated, what is the next? Do we (1) calculate transports using these projection vectors of the touched cells (which might need the length of the reference line that falls into each grid cell), then interpolate the transport value onto the closest points on the reference line, or (2) interpolate the projection vectors onto the reference line. Also, the transports are “divided by the respective cell thicknesses on the reference line”. What do you mean “thickness” here? Vertical thickness or the length of the horizontally overlapped part? I suggest the authors to rewrite these 3-4 sentences and give it in a more clear way.
- Line190: Section2.2.3 talks about the halo grids (some people call these halos or halo grids. E.g., https://github.com/pangeo-data/xESMF/issues/109). This section deserves more sentences because the authors only said “these conditions have to be handled with care” but how? A detailed discussion on the halos might go beyond the scope of the current manuscript, but I would like to see more discussion on how to overcome the halos in order to a smooth use of StraitFlux. An example on dealing with the halo grid problem would be even better.
Minor concerns:
- Line5: transports computed from those are not mass/volume
- Line45: it’s not just the artificial meridional velocity. The artificial zonal velocity does not point to the true east either.
- Line46: “angle of the grid-lines” is always 90 degree since we are using general orthogonal curvilinear coordinates. I think you mean the angle between gridlines and regular lon-lat lines.
- Line81: Do xe and xw have to be land points in the code? Is possible to calculate transports between water points using the current version?
- In Figure 2b, four grid cells with blue, green and yellow arrows are shown. The one on the upper-left corner is misleading because the red reference line does not touch it.
- Line155: The authors said “the section can be kinked”. Here does “kinked” mean a zigzag line? If it does, then this is good because we do need zigzag sections from time to time. According to the definition of def_indicies() function, this is only possible if set_latlon = True and lon_p and lat_p are provided. Maybe you can put it more clear in the paper or in the code documentation.
- Line157: a reference line “consisting of equally spaced latitude-longitude pairs”. What is the interval between points on the reference line? (about 0.1deg according to def_indices(), but why?)
- Line165: when I read the manuscript, I thought that if the interval between two neighboring points on the reference line is very small, then there should be duplicates in the indices found by select_points(). And when I read the code of check_availability_indices(), I realized that duplicates will be removed by the code automatically. But I still think it will be better if the authors explicitly write out that “there might exist duplicates in the indices found by select_points(), but the code will later on remove the duplicates automatically”. This helps reader like me to release the puzzles.
- Line170: the first and last point should be land grid points. Again, is it possible to calculate transports between two ocean grid points?
- Line175-176: left/right/above/below
It is straightforward to use these words to depict the directions of the grid line, but cautions need to be taken where grid lines are distorted greatly in the Arctic Ocean. For example, in a tripolar grid, if we draw a section following a meridional grid line in the Arctic Ocean (e.g., along the Lomonosov ridge), is the cell coming from left/right or above/below to its next one?
- Line227: similar to Line165: Are duplicates found by the code removed automatically?
- Line313: typo “VPN”.
- Line339: ITF needs to be clarified.
- Line373: what is “i.a.”?
- Line392: I can see that on github, there is an instruction on how to install StraitFlux. My own experience, however, is that I can shoot myself in the foot if I mix the use of conda and pip. In consideration of the future update of StraitFlux (e.g., Line128-129), I strongly encourage the authors to upload this tool to conda-forge.
- Line397: typo “downlaoded”.
Code bugs:
I test the code by myself and I do encounter some errors which turn out to be caused by bug in the code. When I ran the Examples.ipynb script, I got the following error.
TypeError: check_Arakawa() takes 4 positional arguments but 5 were given.
Then I found that check_Arakawa() only accepts 4 rather than 5 positional arguments. So in line113 and line131 of mastersciprt_line.py, there should be no the product parameter.
Citation: https://doi.org/10.5194/egusphere-2023-2883-RC2 -
AC1: 'Reply on RC2', Susanna Winkelbauer, 06 Mar 2024
Dear Dr. Shizhu Wang,
thank you very much for your constructive comments and positive feedback.
We are not entirely sure whether we understand the 1st minor comment correctly:
1. Line5: transports computed from those are not mass/volume
Do you mean that those transports are not necessarily mass/volume consistent, as models can already be defined on regular lat/lon grids? If so, would the following modification be satisfactory?
Use of data interpolated to standard latitude/longitude grids is not an option since transports computed from interpolated velocities are not mass consistent.Thank you.
Kind regards,
Susanna WinkelbauerCitation: https://doi.org/10.5194/egusphere-2023-2883-AC1 -
RC3: 'Reply on AC1', Shizhu Wang, 07 Mar 2024
Yes, exactly. Sorry for the confusion.
Citation: https://doi.org/10.5194/egusphere-2023-2883-RC3
-
RC3: 'Reply on AC1', Shizhu Wang, 07 Mar 2024
-
AC3: 'Reply on RC2', Susanna Winkelbauer, 19 Mar 2024
Thank you very much for your positive comments and constructive feedback, you addressed some important points. Your clarifications helped to make the manuscript clearer for the reader. Our responses are provided in the attached PDF.
We really appreciate your time and insight in reviewing our manuscript!Kind regards,
Susanna (on behalf of all co-authors)
Status: closed
-
RC1: 'Comment on egusphere-2023-2883', Anonymous Referee #1, 14 Feb 2024
This paper presents the python package StraitFlux, and demonstrates how it can be used to calculate ocean strait transports for various ocean model grids. It seems like a valuable and easy to use tool, and I appreciate the effort put into making this a public tool that can save other users a lot of time. I recommend that this manuscript is published after some clarifications are made:
L4-5: A bit unclear what you mean by this sentence. Are you referring to the complications from the singularity at the true North Pole? Or errors in fields that are interpolated to standard lat/lon grid?
L9: What exactly do you mean by the integrand for the second method? This word is not used for anything elsewhere in the manuscript.
Eq. (4) ice is mentioned here, but not any further. Would be good to discuss further, e.g. by including an example of ice transport in the paper if mentioning it here.
L86: Maybe briefly explain why closed volume transport is not generally the case?
Vector Projection Method: Is it using the same method for Arakawa A, B and C grids?
Fig 2b. One of the cells is not in contact with the red line. From the text I understand that only cells in contact with the line is used.
L124-126: Why do you convert velocities to transports and then after interpolation divide by the respective cell thicknesses to obtain velocities again, instead of just interpolating the velocities?
L155: How is a straight reference line drawn between the endpoints? Is it following the shortest/great-circle distance along a sphere? Or can it be defined to e.g. follow a specific latitude?
Write also somewhere how the example straits used in the paper are defined, e.g. specify the start and endpoints used. Or a latitude for the Fram Strait.
L167: How are the points i on the refline defined?
L230-231: I don’t understand why the difference between velocity components is taken? Has it something to do with correcting the positions on the Arakawa grid?
Fig 7: I cannot fully understand this figure, and how the angle alpha is defined. Intuitively, I would think u was defined negative if the absolute value of the angle between r and u_dir was more than 90 degrees.
L241-243: I don’t understand this sentence, and why the u and v components are scaled.
L293: What is ESMFgrid? Do you mean xesmf’s Regridder?
Fig 12. Maybe add in figure title or text that this is the Transports for the Fram Strait.
L339: ITF: please define abbreviation
If possible, can you sketch an example showing why interpolation methods make such large errors? Or cite eventual other papers who discuss why? I find it a little hard to imagine how interpolation errors can give such large errors in the net Arctic volume transport.
Typos:
L268: radiant - should be radians
L313: VPN – should be VPM
L360: Gitlab – maybe you mean github instead, since the urls provided go to github?
L373 i.a. – should be i.e. (?)
L383: northern most – cut space between words
L397: downlaoded – should be downloaded
Citation: https://doi.org/10.5194/egusphere-2023-2883-RC1 -
AC2: 'Reply on RC1', Susanna Winkelbauer, 19 Mar 2024
Thank you very much for your positive comments and constructive feedback, you addressed some important points. Your clarifications helped to make the manuscript clearer for the reader. Our responses are provided in the attached PDF.
We really appreciate your time and insight in reviewing our manuscript!Kind regards,
Susanna (on behalf of all co-authors)
-
AC2: 'Reply on RC1', Susanna Winkelbauer, 19 Mar 2024
-
RC2: 'Comment on egusphere-2023-2883', Shizhu Wang, 05 Mar 2024
Given the important roles of ocean circulation in shaping the climate system, correctly diagnosing the volume/salinity/heat transport in the ocean models is always important but complicated by different model grid configurations. Winkelbauer et al. present two new methods in calculating ocean transport, with one sticking to the original model grid lines and the other following strict vector projection and interpolation. Both methods work well with different Arakawa grids, and the results given by these two methods are very similar to assumed analytical results. And I would say the code is versatile in that users can define strait sections in different ways (to my understanding, 3 ways in defining the straits). What makes me more satisfied is that the code is organized into a Python package and maintained in GitHub, which facilitates its future upgrade and public use. Both the paper and the code are well written and I think the paper should be published after considering/answering my following suggestions/questions.
Major concerns:
I know that this is a scientific rather than a technical documentation, but some technical details are still needed to help the readers understand the calculation process.
- Line123-125: I have difficulty in understanding the processes given here. Are the transports or projection vectors “interpolated bilinearly onto the closest points on the reference line? Put it another way, after the projection vectors of all touched cells are calculated, what is the next? Do we (1) calculate transports using these projection vectors of the touched cells (which might need the length of the reference line that falls into each grid cell), then interpolate the transport value onto the closest points on the reference line, or (2) interpolate the projection vectors onto the reference line. Also, the transports are “divided by the respective cell thicknesses on the reference line”. What do you mean “thickness” here? Vertical thickness or the length of the horizontally overlapped part? I suggest the authors to rewrite these 3-4 sentences and give it in a more clear way.
- Line190: Section2.2.3 talks about the halo grids (some people call these halos or halo grids. E.g., https://github.com/pangeo-data/xESMF/issues/109). This section deserves more sentences because the authors only said “these conditions have to be handled with care” but how? A detailed discussion on the halos might go beyond the scope of the current manuscript, but I would like to see more discussion on how to overcome the halos in order to a smooth use of StraitFlux. An example on dealing with the halo grid problem would be even better.
Minor concerns:
- Line5: transports computed from those are not mass/volume
- Line45: it’s not just the artificial meridional velocity. The artificial zonal velocity does not point to the true east either.
- Line46: “angle of the grid-lines” is always 90 degree since we are using general orthogonal curvilinear coordinates. I think you mean the angle between gridlines and regular lon-lat lines.
- Line81: Do xe and xw have to be land points in the code? Is possible to calculate transports between water points using the current version?
- In Figure 2b, four grid cells with blue, green and yellow arrows are shown. The one on the upper-left corner is misleading because the red reference line does not touch it.
- Line155: The authors said “the section can be kinked”. Here does “kinked” mean a zigzag line? If it does, then this is good because we do need zigzag sections from time to time. According to the definition of def_indicies() function, this is only possible if set_latlon = True and lon_p and lat_p are provided. Maybe you can put it more clear in the paper or in the code documentation.
- Line157: a reference line “consisting of equally spaced latitude-longitude pairs”. What is the interval between points on the reference line? (about 0.1deg according to def_indices(), but why?)
- Line165: when I read the manuscript, I thought that if the interval between two neighboring points on the reference line is very small, then there should be duplicates in the indices found by select_points(). And when I read the code of check_availability_indices(), I realized that duplicates will be removed by the code automatically. But I still think it will be better if the authors explicitly write out that “there might exist duplicates in the indices found by select_points(), but the code will later on remove the duplicates automatically”. This helps reader like me to release the puzzles.
- Line170: the first and last point should be land grid points. Again, is it possible to calculate transports between two ocean grid points?
- Line175-176: left/right/above/below
It is straightforward to use these words to depict the directions of the grid line, but cautions need to be taken where grid lines are distorted greatly in the Arctic Ocean. For example, in a tripolar grid, if we draw a section following a meridional grid line in the Arctic Ocean (e.g., along the Lomonosov ridge), is the cell coming from left/right or above/below to its next one?
- Line227: similar to Line165: Are duplicates found by the code removed automatically?
- Line313: typo “VPN”.
- Line339: ITF needs to be clarified.
- Line373: what is “i.a.”?
- Line392: I can see that on github, there is an instruction on how to install StraitFlux. My own experience, however, is that I can shoot myself in the foot if I mix the use of conda and pip. In consideration of the future update of StraitFlux (e.g., Line128-129), I strongly encourage the authors to upload this tool to conda-forge.
- Line397: typo “downlaoded”.
Code bugs:
I test the code by myself and I do encounter some errors which turn out to be caused by bug in the code. When I ran the Examples.ipynb script, I got the following error.
TypeError: check_Arakawa() takes 4 positional arguments but 5 were given.
Then I found that check_Arakawa() only accepts 4 rather than 5 positional arguments. So in line113 and line131 of mastersciprt_line.py, there should be no the product parameter.
Citation: https://doi.org/10.5194/egusphere-2023-2883-RC2 -
AC1: 'Reply on RC2', Susanna Winkelbauer, 06 Mar 2024
Dear Dr. Shizhu Wang,
thank you very much for your constructive comments and positive feedback.
We are not entirely sure whether we understand the 1st minor comment correctly:
1. Line5: transports computed from those are not mass/volume
Do you mean that those transports are not necessarily mass/volume consistent, as models can already be defined on regular lat/lon grids? If so, would the following modification be satisfactory?
Use of data interpolated to standard latitude/longitude grids is not an option since transports computed from interpolated velocities are not mass consistent.Thank you.
Kind regards,
Susanna WinkelbauerCitation: https://doi.org/10.5194/egusphere-2023-2883-AC1 -
RC3: 'Reply on AC1', Shizhu Wang, 07 Mar 2024
Yes, exactly. Sorry for the confusion.
Citation: https://doi.org/10.5194/egusphere-2023-2883-RC3
-
RC3: 'Reply on AC1', Shizhu Wang, 07 Mar 2024
-
AC3: 'Reply on RC2', Susanna Winkelbauer, 19 Mar 2024
Thank you very much for your positive comments and constructive feedback, you addressed some important points. Your clarifications helped to make the manuscript clearer for the reader. Our responses are provided in the attached PDF.
We really appreciate your time and insight in reviewing our manuscript!Kind regards,
Susanna (on behalf of all co-authors)
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 294 | 91 | 19 | 404 | 14 | 11 |
- HTML: 294
- PDF: 91
- XML: 19
- Total: 404
- BibTeX: 14
- EndNote: 11
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
