I have been using ACCESS rAM3 with OSTIA enabled, as well as BARRA2 land/surface data replacement (NCI_HRES_ECCB="barra"). I have a nested configuration with three resolutions (rs01, rs02 and rs03, with rs01 being the outer domain driven by ERA5/BARRA2).
My issue is that, from what I can tell, the OSTIA ancillaries created through the OAS are used as surface temperature initial conditions over the ocean for rs02 and rs03, but not in rs01. Instead, the OSTIA surface temperatures over the ocean in rs01 seem to be replaced with the BARRA2 temperatures in the nci_hres_ic task.
Is this behaviour expected/intended? That is, can OSTIA only be used as surface temperature initial conditions over the ocean for inner domains only? This would result in different SST forcing for different domains, which I guess is not ideal. I can retain OSTIA surface temperatures over the ocean in rs01 by settingNCI_HRES_ECCB="none", disabling the nci_hres_ic task, but this is also not ideal.
Actually the skin temperature should be from ERA5-land or BARRA across the entire grid when being replaced.
This data is then used and passed on to each layer in the nest.
The issue is that that OSTIA data is being regridded in each layer of the nest then pushed into the data.
The ordering of jobs in the top-layer may need to be looked into OR a fix made for if USE_OSTIA = .true. then don’t replace the sea-points but there is the danger of creating artificial boundaries.
Scientifically speaking what would the scientists prefer as the standing solution???
Thanks for the reply Chermelle. In my opinion, restricting the surface temperature replacement to land points makes sense, and is what I thought was happening anyway. But I’m not sure I know enough about the architecture to say how it should be done. Happy to hear from others.
there is the danger of creating artificial boundaries.
Do you mean between the OSTIA data and high res land/surface data?
No I haven’t come across this before. @andrewb1 you mention rs01, rs02 and rs03. But one key point to clarify is if that first rs01 is the one that is at the same resolution as rs02? In that case, my understanding is that rs01 is needed to regrid ERA5 forcing data from ~25km → ~12 km, but IS NOT USED OTHERWISE by the model, i.e. the data in the skin surface temperature is not important for rs01, as rs02 is the first domain for which the model runs a fcst task.
If that’s so and confirmed by @cbengel, then I don’t think it matters that rs01 has different SSTs than rs02.
Just to clarify, the OSTIA replacement happens daily, therefore for the r01 (using the RNS numbering as opposed to the RAS numbering) the OSTIA initial conditions would be re-updated later in the run AND not replaced by BARRA. So r01 would be OSTIA daily varying apart from the initialisation).
Why?
The ERA5-land/BARRA replacement only happens on the first step.
Secondly, r01 in the Lismore example is 0.11 with the BARRA replacement. OSTIA is at 0.05 degrees. The OSTIA data would have been upscaled from 0.05 to 0.11. BARRA SSTs are likely related to OSTIA (@Scott@cnf ?) as ERA5 which drives BARRA uses an OSTIA-based product. This is why we may not have noticed the discrepancy initially.
I will discuss this further with the scientific community to find what preference suits the majority as I am still concerned about creating an artificial boundary (we may need to introduce a different replacement method for the skin temperature involving a data assimilation like methodology).
@andrewb1 Thank you for finding the issue though, it is good to be aware of and on top of.
Thanks Andrew for claryfying that rs01 is the first fcst domain, not the ERA5 driving domain, sorry for my bad info.
Would it be possible to plot out the skin temps so you can see when the SSTs in r01 go from the initial BARRA-derived to the true resolution OSTIA SST? It might be as early as the second model timestep, or perhaps at the next 00UTC.
Just posting some quick plots I made to answer this question myself here.
For the Lismore example, the OSTIA data is reset each 00Z in the recon_cyclen job.
It is confusing because the surface temperature is available twice at 00Z 27/02/2022 (across all the umnsaa_pvera000 and umnsaa_pvera012 files). The first time in the 1st cycle (20220226T0000Z directory) the umnsaa_pvera012 (last timestep) holds the +24 hours surface temperature difference before the surface temperature has been updated (below, plot on the left). The second time in the 2nd cycle (20220227T0000Z directory) the umnsaa_pvera000 (first timestep) holds the +24 hours surface temperature difference after the surface temperature has been updated (below, plot on the right). The plots below show the surface temperature minus the surface temperature at the beginning of the run. There are small difference but after the recon_cyclen the surface temperature (SST) is different in the Lismore rs01 (d1100) level.
No worries at all Mat, it’s good to check all these types of details
I have only been doing tests on a single cycle of 1 hour. But I can post some plots below showing the difference between the OSTIA SST ancil on the rs01 grid (left) and:
So yes, if using BARRA or ERA5-land land surface then the skin temperature field in the first step of the model (and hence until the next recon_cyclen) will be from that dataset, with both datasets also based on OSTIA. The differences in OSTIA may be due to upscaling and downscaling of the 0.05 OSTIA information.
ERA5 is at 0.25, so BARRA may be starting from a 0.25 degree ERA5 SST interpolated to the 0.11 BARRA grid. ERA5-land may be using the data at 0.1 from the native 0.05 degree OSTIA dataset (rather than starting from the ERA5 dataset).
The differences are small may also be attributable to the surface data assimilation scheme used to regrid the OSTIA data in the RNS.
Please note the difference in my plots should be much more different (on a scale of -2.5 to 2.5) because it is a shift from BARRA to OSTIA but also a shift of one-day.
i.e. the OSTIA dataset varies day to day.
clairecarouge
(Claire Carouge, ACCESS-NRI Land Modelling Team Lead)
15
@andrewb1 , we’ve discussed this with @cbengel . There is no quick technical fix for this. There are several options, and our choice depends on whether some options are better for additional functionality or not. It will take some time to investigate the options and understand pros and cons especially with current competing priorities.
Considering the timeframe, we will follow this up via a GitHub issue. This repository is private, I am happy to give you access @andrewb1 if you want to. You would need to give me your GitHub username (you can fill it in your profile so it’s available later).
Thanks Claire, I’ve just added my GitHub username to my profile, so feel free to add me to the repo.
Regarding the issue, I’ve implemented a temporary fix by manually holding the first fcst task of the outer domain, then using mule to undo the replacement of SSTs with the high resolution land data (by re-replacing surface temperatures over the ocean with the ancillaries based on the native 0.05-degree OSTIA).
@cbengel I haven’t run with and without, so I couldn’t say. My guess would be that it would not make a difference to the inner domain of interest. So in my opinion this is a very low priority issue.
I only actually noticed this behaviour because I have set up some experiments with SST modifications applied to the OSTIA directory (e.g., a uniform spatial SST pattern). Obviously in this case the differences are very noticeable and might matter.
One of the main reasons I raised the initial question is so I can accurately describe the SST input data in any resulting articles/publications. This is important as we are interested in small-scale SST impacts. As long as I know exactly what is used, it’s enough of a solution for me.
Thanks @andrewb1, if someone has time it would be interesting to have a with/without comparison. But as you said it is not necessarily time critical. Thanks for raising.
clairecarouge
(Claire Carouge, ACCESS-NRI Land Modelling Team Lead)
20
I’ll mark this as solved here in the forum, as it helps with triaging issues. It does not mean we won’t look at it, simply that we will track it on GitHub.
