Dear everyone:
I just wanted to nudging weekly-averaged satellite sst and ssh in roms,I find that there are "nudging_ssh" and "nudging_sst"in cppdef. But ,it need Tobs( sst observation) and Eobs(observation error)which is used to caculate nudging coeff with Tcoef,but the satellite I download from aviso didn't provide me the observational errors, so whether it is aviliable for me to give the data a spatial and temporal constant parameter, for instance, the precision of satellite?
In addition, I read the "assimulation.in", I need to know how many variables in "oa_ssh.nc",and "sst_ass.nc" ,or I cannot make my own assimulation field.
I hope some one of you can provide me a copy of data example or your matlab script !
Best wishes for all of U!
how about nudging sst and ssh in ROMS
Re: how about nudging sst and ssh in ROMS
Nudging of Sea Surface Height (SSH) is a very bad idea and should not be used under any circumstances. The only way the model naturally accepts external SSH data is through lateral boundary conditions of the so-called Flather type.
The main point here is that the dynamical balance between SSH and the component of barotropic velocity normal to the boundary is very stiff so any forcing of one of them immediately results in response in the other. In practice it means that in ROMS the difference between model SSH and data SSH always goes into forcing of normal barotropic velocity component, and not SSH.
SSH field itself is the result of many balance in the model, including stratification, spatial structure of main thermocline, etc., and if you feel that your SSH is not what you want it to be, it means that something else is wrong: straightforward nudging of SSH toward observed value will not make it better: SSH field is very non-local by its nature, so if nudged in one place, the model almost instantly redistributes the outcome of this nudging.
Because ROMS is a finite-volume code, changing SSH while by-passing the horizontal divergence mechanism is equivalent to causing volumetric buoyancy forcing via effective changes of salinity and temperature throughout the entire water column (you effectively adding/removing water in each gridbox throughout the entire water column without changing tracer content, T,S, this is like cooling/heating and dilution. This type of forcing is non-physical, and you do not expect anything good out of it.
Surface temperature (SST) on the other hand is typically a part of atmospheric forcing, because there is always a hidden relaxation term buried inside the ocean-atmosphere interaction module. So this type of forcing is physical and it is already there.
The main point here is that the dynamical balance between SSH and the component of barotropic velocity normal to the boundary is very stiff so any forcing of one of them immediately results in response in the other. In practice it means that in ROMS the difference between model SSH and data SSH always goes into forcing of normal barotropic velocity component, and not SSH.
SSH field itself is the result of many balance in the model, including stratification, spatial structure of main thermocline, etc., and if you feel that your SSH is not what you want it to be, it means that something else is wrong: straightforward nudging of SSH toward observed value will not make it better: SSH field is very non-local by its nature, so if nudged in one place, the model almost instantly redistributes the outcome of this nudging.
Because ROMS is a finite-volume code, changing SSH while by-passing the horizontal divergence mechanism is equivalent to causing volumetric buoyancy forcing via effective changes of salinity and temperature throughout the entire water column (you effectively adding/removing water in each gridbox throughout the entire water column without changing tracer content, T,S, this is like cooling/heating and dilution. This type of forcing is non-physical, and you do not expect anything good out of it.
Surface temperature (SST) on the other hand is typically a part of atmospheric forcing, because there is always a hidden relaxation term buried inside the ocean-atmosphere interaction module. So this type of forcing is physical and it is already there.
- arango
- Site Admin
- Posts: 1360
- Joined: Wed Feb 26, 2003 4:41 pm
- Location: DMCS, Rutgers University
- Contact:
Re: how about nudging sst and ssh in ROMS
I concur with Sasha. The nudging of SSH is not a good idea. This used to be in the code and it was removed long time ago. We have discussed this issue before in this forum. As Sasha said, the only way to include SSH forcing is via the Flather boundary conditions for 2D momentum. The SST can be added using the heat flux correction QCORRECTION.
You are talking about the data assimilation that used to be in ROMS via nudging or optimal interpolation (OI). This is also deprecated and removed from the code. Nudging to tracer climatology is possible in sponge areas to help with open boundary conditions issues. ROMS nowadays have 4D variational (4D-Var) data assimilation in which you can assimilate SSH products from altimetry, satellite-derived SST, and a variety of observations. This is done to create an analysis that can be used as initial conditions to run the forward nonlinear model. In 4D-Var the linearized dynamics (TLM, RPM, ADM) are used to meld you first guess (a previous forecast, climatology, etc) with the observations taking into account the a priory error hypothesis. The resulting analysis is dynamically consistent. Check the following post for ROMS 4D-Var papers.
ROMS is one of the most advanced 4D-Var frameworks in the world... You need to use a much recent version of the code to take advantage of this.
You are talking about the data assimilation that used to be in ROMS via nudging or optimal interpolation (OI). This is also deprecated and removed from the code. Nudging to tracer climatology is possible in sponge areas to help with open boundary conditions issues. ROMS nowadays have 4D variational (4D-Var) data assimilation in which you can assimilate SSH products from altimetry, satellite-derived SST, and a variety of observations. This is done to create an analysis that can be used as initial conditions to run the forward nonlinear model. In 4D-Var the linearized dynamics (TLM, RPM, ADM) are used to meld you first guess (a previous forecast, climatology, etc) with the observations taking into account the a priory error hypothesis. The resulting analysis is dynamically consistent. Check the following post for ROMS 4D-Var papers.
ROMS is one of the most advanced 4D-Var frameworks in the world... You need to use a much recent version of the code to take advantage of this.
Re: how about nudging sst and ssh in ROMS
Thanks for Ur replies. I will try to nudging sst with QCORRECTION.