ROMS I4DVAR first cycle fwd0 looks very different to first cycle VERIFICATION, with seemingly identical inputs

Discussion about tangent linear and adjoint models, variational data assimilation, and other related issues.

Moderators: arango, robertson

Post Reply
Message
Author
ckerry
Posts: 20
Joined: Wed Sep 15, 2010 1:59 pm
Location: UNSW Australia

ROMS I4DVAR first cycle fwd0 looks very different to first cycle VERIFICATION, with seemingly identical inputs

#1 Unread post by ckerry »

Hello,

I have been having various issues with a ROMS I4DVAR configuration. The configuration is for a recent 5 month period, but is based on previous configurations that worked well.

I have run a 5-month VERIFICATION run and all looks good and as expected.

When I run the very first cycle of the I4DVAR run (I am running 7 day cycles), the fwd0 run looks quite different to the very first cycle of the VERIFICATION run (with identical initial conditions, boundary and surface forcing).

The only difference in cppdefs.h is that I
#undef VERIFICATION
and
#define I4DVAR

and have
#if defined I4DVAR
# define BGQC
# define VCONVOLUTION
# define IMPLICIT_VCONV
# define FULL_GRID
# define ADJUST_STFLUX
# define ADJUST_WSTRESS
# define ADJUST_BOUNDARY
# define FORWARD_FLUXES
# define PRIOR_BULK_FLUXES
# define AVERAGES
# define FORWARD_WRITE
# define FORWARD_READ
# define FORWARD_MIXING
# define OUT_DOUBLE
#endif

Examples of the differences are shown below for velocity at the surface for the verification run (left) and the fwd0 of i4dvar run (right).
Screenshot 2024-04-01 at 8.20.58 PM.png
Screenshot 2024-04-01 at 8.41.59 PM.png

I think that these instabilities in the velocity field are what are causing my problems with the data assimilation (I will not get into that until I resolve this initial issue).

In the roms.in I have the following for the NLM lateral boundary conditions:

LBC(isFsur) == Clo Che Che Che ! free-surface
LBC(isUbar) == Clo Fla Fla Fla ! 2D U-momentum
LBC(isVbar) == Clo Fla Fla Fla ! 2D V-momentum
LBC(isUvel) == Clo Cla RadNud RadNud ! 3D U-momentum
LBC(isVvel) == Clo Cla RadNud RadNud ! 3D V-momentum
LBC(isMtke) == Clo Cla RadNud RadNud ! mixing TKE

LBC(isTvar) == Clo Cla RadNud RadNud \ ! temperature
Clo Cla RadNud RadNud ! salinity

and the following fro the adjoint:

! Adjoint-based algorithms can have different lateral boundary
! conditions keywords.

ad_LBC(isFsur) == Clo Che Che Che ! free-surface
ad_LBC(isUbar) == Clo Fla Fla Fla ! 2D U-momentum
ad_LBC(isVbar) == Clo Fla Fla Fla ! 2D U-momentum
ad_LBC(isUvel) == Clo Cla Cla Cla ! 3D U-momentum
ad_LBC(isVvel) == Clo Cla Cla Cla ! 3D V-momentum
ad_LBC(isMtke) == Clo Cla Cla Cla ! mixing TKE

ad_LBC(isTvar) == Clo Cla Cla Cla \ ! temperature
Clo Cla Cla Cla ! salinity

I also tried the VERIFICATION run with clamped boundaries for the 3D variables and it still looks nice without the instabilities that I get in the fwd0 run.

I'm failing to understand how the two 7-day free runs with seemingly identical configurations can look different. Are there any parameters specific to the adj fwd0 run that I may be missing, or reasons why the velocities looks so odd?

Thanks in advance,
Colette

ckerry
Posts: 20
Joined: Wed Sep 15, 2010 1:59 pm
Location: UNSW Australia

Re: ROMS I4DVAR first cycle fwd0 looks very different to first cycle VERIFICATION, with seemingly identical inputs

#2 Unread post by ckerry »

Hernan et al.,

I have been applying a sponge layer via the recommended approach of writing the nondimentional spatial distribution arrays "visc_factor(i,j)" and "diff_factor(i,j)" into the grid NetCDF file.
This works fine for the NLM_DRIVER and VERIFICATION runs, however I have found that for the fwd0 run of the I4DVAR driver, the sponge is not applied if I apply it in this way.
I have the factors written to the grid file and I have the below in the .in file
LuvSponge == T ! horizontal momentum
LtracerSponge == T T ! temperature, salinity, inert

For the VERIFICATION run the sponge works, but for the fwd0 run it is not applied (hence the unsightly velocity field from the previous post).

I now define ANA_SPONGE and have edited ana_sponge.h for my domain (following the WC13 analytical sponge but edited for my domain - my western boundary is closed, while Andy's closed boundary is to the east) and I get great reasonable results for the fwd0 run.

I also noted that in the WC13 I4DVAR tutorial Andy uses ANA_SPONGE.

Is it known that the recommended sponge method (that is reading the factors from the grid file) does not work for I4DVAR, and ANA_SPONGE is the method to be used, or am I missing something?

Either way I'm happy as I now have a working system I hope, but it would be good to document for other users.

Cheers,
Colette

Left is the fwd0 velocities with ANA_SPONGE, and right is the fwd0 velocities where I was assuming they were read from the grid file (but it wasn't). Identical run otherwise.
Screenshot 2024-04-05 at 1.24.05 PM.png

Post Reply