the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 10 Sep 2025
"Norkyst" version 3: the coastal ocean forecasting system for Norway
Abstract. We describe the operational forecasting system "Norkyst", now in version 3, which is used for predicting the ocean circulation along the coast of mainland Norway and in the fjords. The forecasting system is based on the Regional Ocean Modeling System (ROMS), and has sub-kilometric horisontal resolution to resolve mesoscale features. Here we describe the basic configuration and report verification statistics of unconstrained model runs. The main features of the circulation and hydrography, including seasonal variations, are well represented in Norkyst v.3, making the forecast system suitable for its intended use as an open service for users in public or private sectors such as aquaculture, fishery, shipping, research, consulting, environmental management, and others who needs detailed predictions of the physical state of the Norwegian coastal ocean.
- Preprint
(4217 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
- CC1: 'Comment on egusphere-2025-3986', Alexander Shchepetkin, 23 Oct 2025
-
RC1: 'Comment on egusphere-2025-3986', Isabel Garcia Hermosa, 07 Nov 2025
Dear authors, I am unsure of the tone of other articles in this journal. I find this article interesting, clear and pedagogical.
Specific comments
Regarding my comments below they are suggestions and questions.
I don’t ask to do any changes regarding to this point, I would like to comment about it. I don’t know if I understood correctly, but you say for the bathymetry you have a 10 m minimum depth criteria. With so many islands and channels isn’t this a bit risky? Maybe I didn’t understand clearly. I guess, as the other reviewer (Shchepetkin) mentions, it cold be due to the breach of the courant criteria. Perhaps there are other methods, but really dependent on the bathymetry available. Also if in general you get good results, it is ok. However coastal and shallow areas, with channels and shoals are very dependent on bathymetry.
I don’t know sufficiently the area but cold the issues present in some of the stations in Tables and figures be an artifact of this depth minimum?
A suggestion regarding Section 4. For clarity, I would reorganise it or add a sub section (observations used in evaluation) after an introductory sentence on what you are comparing. Introduce the section with a sentence to make it clear (as mentioned early in the introduction, as a reminder) that this section compares the hindcast that has such and such characteristics to in situ observations. Then put the rest of the information in line 166 (period available for the hindcast).
The following sentence (starting in line 166) looks out of place as it mixes things and the link is not clear to me. Perhaps add some text to clarify why it is there? I am assuming it is something like this below, I don’t know if I understood correctly.
“It should be noted that a continuous and internally consistent high resolution archive of atmospheric forcing data TO BE USED IN THIS HINDCAST has not been available for the entire period. PLEASE NOTE THAT BECAUSE OF XXX, IN THE HINDCAST a warm bias reaching up to 0.7-0.8 degrees IS PRESENT in the surface layer in summer, resulting from too high radiation forcing. THIS has been identified when using NORA3 data (period 2012-2020, see Gonzalez et al., 2025), which is discussed further below in Sec. 4.2”.
An additional question. You mention in the abstract that indeed the system you evaluate is the hindcast, but you want to use the system in forecast mode. There is no mention as to whether the forecasting system is expected to behave in the same way or not. Would it be worth clarifying?
In figures showing salinity values there’s no unit. Is this on purpose?
I appreciated the colour diagrams shown in Fig 3, 4, 5, 6.
Just a suggestion not compulsory. For the metrics results in table 1 and 2, as you are lucky to have all these many metrics for quite a few locations, it would be really good to see them graphically. This could be done in a Taylor diagram.
Technical corrections
I would advise to correct a couple of typos throughout the document. The terms ‘hydrographical’ to be replaced by hydrographic, and ‘horisontal’ by horizontal.
Citation: https://doi.org/10.5194/egusphere-2025-3986-RC1 -
RC2: 'Comment on egusphere-2025-3986', Stefania Angela Ciliberti, 10 Nov 2025
General comments: this paper presents a new implementation of the Norkyst v3 operational system in the very complex Norway coastal area. The system is based on ROMS whose model configuration and upstream data are described in Sections 2 and 3. The paper could benefit from a dedicated section that introduces the validation methodology before going to Section 4, which is about results. Some references seem to be missing - for instance, upstream data used for the validation are mentioned but not referred, and that could help in the reproducibility. Figures 7 and 8 might benefit from some additional work to improve readibility. Section 5 might need some improvement to better address the operational implementation of the system and the added value for users, including specific services at users' disposal for the access to forecast products and the associated product catalogue: the 2 subsections are quite short and I am sure the system is much more complex, so I would encourage the Authors to better balance this part of the paper, given its importance. In the Conclusions, some key messages from the assessment could be reported and emphasized. An additional suggestion: intercomparison against available operational products in the area might significantly help to demonstrate the added vaule of Norkyst v3.
Additional comments/suggestions are given in the supplement.
Data sets
Hindcast archive K. H. Christensen et al. https://thredds.met.no/thredds/catalog/romshindcast/norkyst_v3/catalog.html
Daily forecasts K. H. Christensen et al. https://thredds.met.no/thredds/fou-hi/norkystv3.html
Model code and software
Norkyst v. 3 input files K. H. Christensen et al. https://zenodo.org/records/16810677
Interactive computing environment
Analysis and plotting scripts K. H. Christensen et al. https://doi.org/10.5281/zenodo.17053759
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 1,296 | 95 | 12 | 1,403 | 14 | 16 |
- HTML: 1,296
- PDF: 95
- XML: 12
- Total: 1,403
- BibTeX: 14
- EndNote: 16
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
I am not writing a full review, but I have just a three comment to the issues which caught my attention.
Lines 60-71, Sec. 2.1 Model grid: "The horizontal resolution of Norkyst is approximately 800 m. ROMS uses C grid staggering, and the domain size is 2747 x 1148 horizontal grid points. .... About 42% of the grid is land....", also Figure 1:
This is, indeed, an inefficient way to set up a grid.
The goal of this project, as I understand it, is to make an operational model, which both ambitious and computationally challenging, as it involves a large, high-resolution grid, obviously very expensive to run, and even to handle the associated data. And is intended to be used operationally on daily basis.
It happened, that Norway has the most complicated coastline in the World, almost fractal, and going inside these fjords is what is desired, but the grid must be fine enough to even get crude idea about what is going on there. So the authors choose to setup a simple rectangular grid, covering the entire country, and, obviously, facing the need to make a compromise between grid resolution and how far offshore you can go. Cutting Lofoten basin in half also means that you are cutting eddies in half. Lofoten basin is famous for its eddies.
My suggestion: make it curvilinear:
http://91.225.115.25/norkyst/v6.1/roms_grid.pdf
The grid is designed to cover larger area, but in such a way that resolution contracts when approaching Norwegian coast - kind of alternative to 2-way nesting, except that it has no steps and is perfectly smooth.
In this variant the dimensions are 3844 x 802, which slightly less than the total number of points of your grid 2747 x 1148. Note that only one out of several grid lines is shown (it is not practical to plot them all), but the land mask is the actual land mask as it would be seen by ROMS code,
running using this grid.
Its grid resolution is shown here
http://91.225.115.25/norkyst/v6.1/roms_grid_res.pdf
By the design the grid has the same resolution in both directions, locally pm=pn at any point, even though bothh of them change by more than order of magnitude, depending on the location. 500 means 500 meters; 1k2 means 1.2km.
Topography looks like this:
http://91.225.115.25/norkyst/v6.1/roms_grid_topo.pdf
There are three variants of this grid, which differ only by resolution:
http://91.225.115.25/norkyst/v6.1/ xi_rho=3844 eta_rho=802
http://91.225.115.25/norkyst/v6.2/ xi_rho=4611 eta_rho=962
http://91.225.115.25/norkyst/v6.3/ xi_rho=3076 eta_rho=642
The content of these directories is as follow:
"roms_grid.nc" -- netCDF file for ROMS grid, which can be made runnable. This file already contains all finalized variables defining grid as geometric object (lon_rho,lat_rho, lon_psi,lat_psi, pm,pn,angle,f) and place-holders for land mask and topography (currently "mask_rho" is generated from USGS GSHHS data. Alternatively EMODNET Europe_coastline_2020_OSM.shp can be used. No effort was made thus far to do any manual editing of land mask, so some narrow passages should be inspected and opened as needed), and "hraw" interpolated/averaged from GEBCO_2024.nc.
All other files are precursors, configuration files, diagnostics, orthogonality check, etc...
Lines 73-76, "The main challenge with regards to stability is not associated with horizontal resolution, but with occasional large vertical velocities in regions of strong convergence (e.g. at the Kattegat-Skagerrak front), which in turn leads to violations of the CFL criterion in the vertical tracer equations, hence the minimum depth of 10 m"
This problem has been solved 10 years ago:
https://www.sciencedirect.com/science/article/pii/S1463500315000530
Indeed, once the horizontal resolution becomes finer and finer, at certain point vertical advection becomes the most restrictive factor. Investigation of where and how exactly model blows-up due to computational instability reveals that vertical Courant number is generally very small everywhere, except just in few places, "hot spots" - literally, a handful of grid points out of one million or so holds the simulation hostage. What is going on there is some physical process resulting in something highly non-equilibrium. It may be a front with strong vertical mixing next to no mixing. A supercritical flow (horizontal advection velocity exceeds internal wave speed) becoming subcritical, resulting in violent generation of internal waves (similar to . An internal wave has nowhere to go because of the bottom raise, resulting in growth of amplitude, and eventual shoaling and crashing. Back-and-forth tidal movements over a topographic ridge causing
generation of internal waves of supercritical (too steep topography) nature.
Whatever.
Lines 142-144, <<For the sea surface height and barotropic velocities, we use the "Chapman explicit" and "Shchepetkin" options, respectively...>> -- perhaps the proper way to call it "Riemann boundary conditions", or something of this sort, see Sec. 2.1.2 in
https://www.sciencedirect.com/science/article/pii/S146350031000082X
what is relatively new here, is that all Riemann solvers (or numerical methods relying on the idea of propagating something along characteristics) always use non-staggered grids: this makes sense, because Riemann invariants are linear combinations of prognostic variables, and it is natural to make them co-located on the grid. However, ROMS uses staggered grid, and there is no way around it. So this needs to be dealt with, and Sec. 2.1.2 is about this. Another point to make is that one cannot separate b.cs. for free surface and for barotropic velocities: they are part of the same algorithm - the only reason why the discrete value of free surface needs to be "radiated-out" is to end up at the same point in space and time as the normal velocity component, so the two can be added/subtracted to form Riemann invariant. Free surface value needs to travel only half-grid interval in space and one time step up in time, so if traced back to time step "n", the characteristic for free surface may be outside the grid interval (see Fig. 2 from Mason et al 2010). As the result, a naive (say "Chapman explicit") scheme causes more restrictive limitation on barotropic time step than the time stepping algorithm of barotropic mode.