A4DVAR_TOY

[m.hadfield]

I want to know what all this 4DVAR fuss is about, so I build ROMS (SVN revision 44, updated today) with

Code: Select all

ROMS_APPLICATION := A4DVAR_TOY

and then run it with

Code: Select all

oceanS < ROMS/External/ocean_a4dvar_toy.in

It stops with

Code: Select all

READ_PHYPAR - could not find input file:  atoy_grd.nc

Well fair enough, as there is no such file. Where can I get one?

[arango]

The A4DVAR_TOY is a simple idealized test case for the weak constraint 4DVar algorithms (W4DPSAS, W4DVAR). It turns out that this is not a rigorous test for these algorithms. It always work even if there are problems with symmetry, conjugate gradient, and convergence. We are still fine tunning the weak constraint algorithms.

However, you point is a good one I will soon put a test case using the idealized double gyre but for incremental, strong constraint 4DVar IS4DVAR. It is better to start with strong constraint and get some experience.

Stay tunned

[m.hadfield]

However, your point is a good one I will soon put a test case using the idealized double gyre but for incremental, strong constraint 4DVar IS4DVAR. It is better to start with strong constraint and get some experience.

I just stumbled across this thread and decided to explore the double-gyre case. There's good news and bad news. The bad news is that I've run into a minor problem and the relevant Wiki page is empty. The good new is that, if someone helps me get it going, I promise to write some instructions on the Wiki page.

OK, so I went to the Datasets page, selected the double_gyre button, downloaded the 7 tar files there and unpacked them, giving me some 700 MiB of files, more or less, in various locations on the following directory tree

Code: Select all

./Correlation
./Correlation/Build
./Correlation/Runs
./Data
./Forward
./IS4DVAR
./IS4DVAR/Build
./IS4DVAR/Runs
./OBS
./OP
./OP/Build
./OP/Runs
./Sanity
./Sanity/Build
./Sanity/Runs

Running the Forward model seemed like a good thing to try first, so went there, adapted build.sh and built the model. All OK so far. Then I tried running the model with input from ocean_double_gyre_01.in. It failed with

Code: Select all

READ_PHYPAR - could not find input file:  gyre3d_ini.nc

...doubtless because the file in question does not, in fact, exist. There are a few initialisation files in the directory tree, namely

Code: Select all

./Data/gyre3d_ini_unsteady.nc
./Data/gyre3d_ini_zero.nc
./IS4DVAR/Runs/gyre3d_ini_01.nc

but it's unclear which, if any, would be suitable here (bearing in mind that I have very little idea what I'm doing or indeed what I'm trying to do).

Hints?

[arango]

Try gyre3d_ini_unsteady.nc. Maybe few things need to be changed. I prepared that tar before of the Grenoble Workshop last year. I gave an informal tutorial. I ran all those applications and an example of the resuls are in the Runs sub-directories.

The issure here is that the double gyre test case was run for 50 years to steady state with enough viscosity to supress eddies. All the statistics for the error covariances are based on the steady state. Then, the viscosity was reduced to get an unsteady solution for the 4DVAR twin assimilation experiments.

Notice that we always use the job_is4dvar.sh script to run since these algorithms are complex and we tend to forget all the steps needed. You need to update this script and s4dvar.in. These files have changed since them. See the distributed ROMS/Bin/job_is4dvar.sh script.

Good luck

[choboter]

I've also been trying to get experience running the double_gyre test case, but it has not been a straightforward setup.

The input files of the double_gyre demo cannot be used with the latest revision of ROMS 3.2 (which one gets from "svn update") because the IS4DVAR input files have a new naming convention. (See Big update due to IO parallelization and data assimilation)

But going to previous versions can be dangerous because the further back you go, the more bugs you introduce. Which revision of roms (e.g., obtained by "svn update -r 240", with 240 replaced by the revision number) is best to use with the double_gyre demo?

Or, even better, can I really use the very latest version of ROMS with some minor modifications of the double_gyre input files? For example, in s4dvar.in, can I simply set STDnameI to be what was previously called STDname, and ignore the values for STDnameM, STDnameB, and STDnameF?

Best of all, would it be possible for someone to update the double_gyre files on the Datasets page to be consistent with the new IS4DVAR input file conventions?

Many thanks!