TKE as initial field

[andreykoch]

Hello ROMS family!

First of all, many thanks to ROMS creation group for building ROMS-code, to admins and moderators of this site for their thoroughly carried work, and to all who has been participating in ROMS forum so far for their helpful comments and advises!

Now, let me explain my problem. I am running ROMS_3.0 (svn trunk_79) for a realistic application "Oregon CTZ" which is based on a standard idealized application "Upwelling". I got a solution for some months in the domain of my interest attached to Oregon coast. Then, I started to analyze 3D jet structure and its evolution in time. A complicated structure of the jet drove me to look at X,Y, and Z coordinate labels to track water particle's origin. I made a new run just for a couple of weeks (somewhere close to the end of my original run's period) and defined these labels as inactive passive tracers in initial and boundary files of the new run. I got another solution which satisfied me at once, but... then I noticed the significant difference between both my solutions, the second one was of lower energy, the speed of the jet was lower and its structure was different. I was told that probably my inconsistence was due to differences in turbulent kinetic energy (TKE) field, which is set for a zero at initial time step. I dove in ROMS FAQ and under "How to generate initial ROMS file" found that there are no initial variables besides zeta, 2D, 3D momentum and tracers.
So, my question is: how can I define an initial TKE field (fields, if ROMS requires it with time extension) in the source code? Or may be I am out of date and now there is an option in the latest release of ROMS_3.0 which allows to define a desired variable in initial/boundary files?

Thank you in advance for your comments and concerns!

Andrey

[kate]

Good question! Somewhere along the 3.0 line, writing the fields for GLS and MY2.5 got added to the restart file, plus using them on restart. I suggest you update your code. That leaves the question of providing those fields in the initial file and having ROMS read it then. It should be an easy fix if it doesn't. Are you wanting to provide initial conditions for them?

[andreykoch]

Kate,

Thank you for responding me. Probably, I should update my code with latest release, but I am afraid that wouldn't be critical for my particular need. As far as I understand the restart procedure as it is, it doesn't require a new initial file to make a restart, and the restart file contains only those variables that were defined in initial file. My task is to make a new run with three new variables (coordinate labels) added to the processing. And I want to make it not from the same date as my original run, but close to the end of it, when the jet I am looking at is well developed, that's why I need the information from my old run at the time when I want to start my new run with coordinate labels added, and that's why I need to create new initial and boundary files which would contain these new variables. So, I guess the restart procedure woudn't work for me, and I am wondering if there is a posiibility to have a real magnitude of TKE, not zero, at the beginning of my new run.
Thanks again for your concern.

Andrey

[kate]

Whether you choose to update your specific code or not, you should look at a current version of get_state.F. It has code for reading tke, gls, and Lscale if Perfect3D. Just cut and paste from it and edit the logic so that it will read it from the initial file too.

[andreykoch]

Well, at least I chose do not modify the code, and try to solve my problem by another way - thanks to Alexander Kurapov for giving me that idea. His idea was to make a run from the very beginning of my original run with labels added and stop it on the date, from which I want to track water particles, than change the restart file by providing the original values for coordinate labels in it and run it again from restart_file. For first try I made a run for just 4 days with PERFECT_RESTART enabled and without any additional variables, then I reran the task from restart_file and got a solution for other 4 days. I compared the solution from first 4 days of my experiment with original solution and was ensured that they were identical, but the comparison of solution from following 4 days with original one has showed significant mutual differences. In ROMS forum I found a discussion related to PERFECT_RESTART issue (around February 2008), and finally decided to update my source code - thanks to Kate Hedstrom and Hernan Arango for their instructions - I successfully did it.
Then I repeated all steps described above, using updated source code, but the differences between solutions were still there! I checked several times if I did the restart incorrectly, but I didn't: NRREC == -1 ; LDEFOUT == F ; ININAME == ocean_rst.nc ; timing was appropriate, too. The bright side is that now I am aware the problem was not in the old code. But I am still in doubt - how to get an identical to the original solution, using PERFECT_RESTART. Any comments and concerns would be desirable!

Andrey

[jcwarner]

Many months ago i ran several simulations and was able to create perfect restarts. However, I was not able to compute a perfect restart with the MY25 option. Perhaps there are also other options that may not be fully compatible yet. Can you give a list of your cpp options?
Also, it woudl be nice for you to quantify "significant mutual differences."

[andreykoch]

J.C. Warner,

Thanks for your reply. Here is my cpp list. I have not yet figured out how to insert pictures in this forum messages, but I can quantify mentioned differences: they reach up to 0.05 m/s for u, wich is about 30% of maximum value in observed section.

Andrey

#define NL_MODEL

#define UV_ADV
#define DJ_GRADPS /* Splines density Jacobian (Shchepetkin, 2000) */
#define UV_COR
#define UV_QDRAG
#define UV_VIS2
#define MIX_S_UV
#define MIX_ISO_TS
#define TS_DIF2
#define TS_U3HADVECTION
#define TS_C4VADVECTION

#define SOLVE3D
#define SALINITY
#define NONLIN_EOS
#define CURVGRID
#define SPLINES
#define MASKING

/* Select only one vertical turbulence closure option */
#define MY25_MIXING
#ifdef MY25_MIXING
# undef N2S2_HORAVG
# undef KANTHA_CLAYSON
#endif

/* Surface boundary condition settings */
/* I have Uwind, Vwind, Tair, Pair, Qair, */
/* short wave radition flux and rain */
#define BULK_FLUXES
#ifdef BULK_FLUXES
# define LONGWAVE /* undef to read net longwave, define to use Berliand */
# undef LONGWAVE_OUT /* define to read downward longwave, compute outgoing */
# define DIURNAL_SRFLUX /* impose shortwave radiation local diurnal cycle */
# undef ANA_SRFLUX /* analytical surface shortwave radiation flux */
# undef ALBEDO /* use albedo equation for shortwave radiation */
# define ANA_CLOUD /* analytical cloud fraction => zero cloud */
# define SOLAR_SOURCE /* solar shortwave distributed over water column */
# undef EMINUSP /* turn ON internal calculation of E-P */
# define ANA_RAIN /* zero rain, with eminusp option can use ncep rain data */
# define ANA_SSFLUX /* analytical surface salinity flux */
#endif

/* Bottom boundary condition settings */
#define ANA_BSFLUX
#define ANA_BTFLUX

/* Lateral boundaries */
/* Begin open boundary condition settings */

#define EASTERN_WALL

#define NORTH_M2FLATHER
#define SOUTH_M2FLATHER
#define WEST_M2FLATHER
#define NORTH_FSCHAPMAN
#define SOUTH_FSCHAPMAN
#define WEST_FSCHAPMAN

#define RADIATION_2D /* Tangential phase speed in radiation conditions */

#define NORTH_M3RADIATION /* Western edge, 3D momentum, radiation condition */
#define SOUTH_M3RADIATION /* Western edge, 3D momentum, radiation condition */
#define WEST_M3RADIATION /* Western edge, 3D momentum, radiation condition */

#define NORTH_M3NUDGING /* Western edge, 3D momentum, passive/active term */
#define SOUTH_M3NUDGING /* Western edge, 3D momentum, passive/active term */
#define WEST_M3NUDGING /* Western edge, 3D momentum, passive/active term */

#define NORTH_TRADIATION /* Western edge, tracers, radiation condition */
#define SOUTH_TRADIATION /* Western edge, tracers, radiation condition */
#define WEST_TRADIATION /* Western edge, tracers, radiation condition */

#define NORTH_TNUDGING /* Western edge, tracers, passive/active term */
#define SOUTH_TNUDGING /* Western edge, tracers, passive/active term */
#define WEST_TNUDGING /* Western edge, tracers, passive/active term */

#define SPONGE

#define ASSUMED_SHAPE
#define DOUBLE_PRECISION
#define POWER_LAW
#define PROFILE
#define K_GSCHEME
#define UV_U3HADVECTION
#define VAR_RHO_2D
#undef T_PASSIVE
#define PERFECT_RESTART

[arango]

Yes, the Mellor-Yamada parameterization (MY25_MIXING) doesn't pass the perfect restart test. We don't know why. It is weird because the GLS_MIXING configured as k-kl (MY25) does pass the test. Notice that this trac ticket is still open. As John mentioned above maybe there are other options that require additional work for perfect restart like sediment, biology, and other complex algorithms. The basic ROMS kernel has a working perfect restart.

[andreykoch]

Thanks for your clarification on MY25_MIXING option.

[jcwarner]

is it a big deal for you to try your 8 day test with GLS instead of MY25?
So, as you did before,
Test A = just an 8 day continuous run.
Test B has 2 parts. Run for 4 days, perfect restart, run for day 5-8.

Maybe you could help see which of all those high end options cold be giving the trouble? The ones that look like suspicious would include the vis2 stuff, mix_ts stuff, my25, and maybe sponge (?).

[andreykoch]

I've made that experiment with GLS instead of MY_25, but run B part 2 (days 5-8) differs from same days of run A. I have not made experiments without other optionts you mentioned.