NCAR
Feature request: How to prevent 3D TEMPERATURE observations from influencing the surface layer when assimilating with EAKF?
Hello DART team,
I am using the EAKF in DART to assimilate two types of ocean observations simultaneously:
3D TEMPERATURE (vertical profiles)
SATELLITE_BLENDED_SST (surface temperature)
In my application, these two observation types have very different spatial characteristics. I would like to preserve the vertical structure of 3D TEMPERATURE below the second model layer, while letting SATELLITE_BLENDED_SST dominate the correction in the surface layer.
However, when assimilating both types together, the 3D TEMPERATURE observations still influence the surface layer through vertical covariance. This degrades the SST analysis, because the subsurface temperature increments propagate upward and affect the surface.
I would like TEMPERATURE observations to have zero impact on the surface layer, but still update the model below level 2.
What is the recommended way to completely remove the influence of TEMPERATURE observations on the surface model layer while still allowing them to update deeper layers? Is type-dependent vertical localization or layer-specific masking supported in DART?
Thank you very much for your time and guidance.
Hello DART team,
I am currently considering a possible solution to prevent 3D TEMPERATURE observations from influencing the surface layer during assimilation.
In the POP model interface, inside models/POP/model_mod.f90, there is a function called get_close_state, which is used to determine which state variables are within the localization radius of a given observation.
My idea is the following:
When the observation is of type 3D TEMPERATURE,
And the state variable being tested belongs to the surface layer,
Then I would modify get_close_state to exclude these surface-layer state variables from the list of “close” state values.
In other words, I am thinking about adding a condition that effectively removes surface-layer state variables from the localization stencil when the observation is a 3D temperature profile.
My question is:
Would this modification correctly force the impact of 3D TEMPERATURE observations on the surface layer to be exactly zero in the EAKF update?
That is, by excluding the surface-layer state variables in get_close_state, will EAKF perform no update on them (i.e., no ensemble mean or spread adjustment), effectively blocking the vertical covariance influence from deep temperature observations?
Or would this approach create unintended side effects or violate assumptions in how DART handles localization and state vector updates?
Any guidance or suggestions on whether this is an appropriate method—or if there is a better recommended approach—would be greatly appreciated.
Thank you very much for your help.
You'll want to use the obs_impact_tool before your assimilation, which enables you to specify that some observation types should not affect some state variables. It creates a table which filter can read. This is a specialized form of localization.
You'll want to use the obs_impact_tool before your assimilation, which enables you to specify that some observation types should not affect some state variables. It creates a table which filter can read. This is a specialized form of localization.
Thank you very much for your helpful reply. I am already trying to use obs_impact_tool, but I encountered a question while checking the state variables in obs_kind_mod. I can only find the ocean temperature variable QTY_POTENTIAL_TEMPERATURE, and I do not see any dedicated variable that represents sea surface temperature (SST) specifically.
Given this, I am unsure how I should properly set up the input file for obs_impact_tool. Should SST observations be mapped directly to QTY_POTENTIAL_TEMPERATURE in the impact table, or is there another recommended way to distinguish surface temperature from subsurface temperature in DART?
Any guidance would be greatly appreciated.
Hi yxyyyyyy, it would be helpful to know more about you and your research goals, so that we can see how it might fit in with other DART research and development work. If you're doing innovative work that should be added to DART, we may want to set up a collaboration instead of just answering questions through github issues.
I don't have extensive background in POP applications, but I'd say that POP already uses QTY_POTENTIAL_TEMPERATURE for 3-D temperature, so it would be clear and correct to use QTY_TEMPERATURE for the SST.
Hi yxyyyyyy, it would be helpful to know more about you and your research goals, so that we can see how it might fit in with other DART research and development work. If you're doing innovative work that should be added to DART, we may want to set up a collaboration instead of just answering questions through github issues.
I don't have extensive background in POP applications, but I'd say that POP already uses QTY_POTENTIAL_TEMPERATURE for 3-D temperature, so it would be clear and correct to use QTY_TEMPERATURE for the SST.
Thank you very much for your previous reply — I really appreciate your time and guidance.
I’m currently facing a technical issue in my DART–POP application. I am assimilating two types of ocean observations simultaneously:
3D temperature profile observations, and
OISST sea surface temperature observations.
When these two types are assimilated together, the 3D temperature observations strongly influence the surface layer through vertical covariance, which unfortunately degrades the SST analysis. What I would like to achieve is:
Allow 3D temperature observations to update deeper layers, but have zero impact on the surface layer, so that the SST analysis is dominated by the OISST observations.
I have been trying to solve this for quite a long time, but so far I haven’t found a clean or recommended way to completely remove the influence of profile temperature observations on the surface layer.
If it’s convenient for you, would it be possible to ask you more details by email? I would be very grateful for any additional guidance or suggestions.
Thank you again for your help.
I learned from my supervisor today that we won't be able to answer any more of your questions without knowing where you work and what your research projects and goals are. It's best to handle these conversations in github because that makes an archive which the whole DART community can use, and reduces redundant answers to questions.
