Nudge dye to NaN BC

[rduran]

Hi,

I would like for my dyes to get nudged to NaN values with incoming flow. I tried nudging with boundary dye values set to 1e37 but they get read as 0 (zero).

I also tried reducing boundary conditions to only radiation with no nudging, but that was not good enough, I need incoming water parcels to be identified and ignored in my dye calculations.

How can I set incoming parcels to have NaN dye values?

Could NaN values create spurious oscillations? I would want to avoid the incoming parcels mixing with parcels in the domain as much as possible. Physical diffusion coefficients for dye are set to zero and that works fine but numerical mixing is not possible to control.

thanks,

Rodrigo.

[arango]

This does not make any physical sense to me Notice that the nudging time scales are 1/time. If you multiply the nudging scale by a concentration (NaN, infinity, etc) you get overflow/underflow and your computation is stopped by any Fortran compiler during execution. There is not a way in ROMS to have computations with NaNs or large values (infinity) for that matter. These values will be propagated by the physical and numerical kernels. ROMS is not Matlab. In matlab, the internal algorithms use NaN as a numerical computational mask. As soon as you start incorporating large value into ROMS computations, the model will stop because of time-step violations and/or numerical overflows. This type of computations do not exist in Fortran. You need to think more about this and come up with a viable strategy that accomplishes what you want.

[rduran]

This does not make any physical sense to me

That might be because these are relatively unusual dyes, really they are Lagrangian Labels giving the initial position of all water parcels in the domain defined and advected as passive tracers.

There is not a way in ROMS to have computations with NaNs or large values (infinity) for that matter.

This is what I wanted to confirm, thanks.

The computation I need to do with the Lagrangian Labels could be accomplished by nesting in a bigger domain (considerable amount of work). Another option is (for this computation) use Lagrangian floats instead which is what I am working on.

Lagrangian Labels offer amazing benefits but ... as all methods it isn't perfect.

anyway thanks, I now know what I needed to know.

[arango]

There seems to be a misunderstanding here. The dyes, like any other passive tracer, are time-stepped by ROMS 3D physical and numerical kernels. That is, we have the following terms: time-rate of change, horizontal and vertical advection, horizontal and vertical diffusion, and any other right-hand-side forcing (source and sinks) terms. Just think on those terms. If you have large discontinuities of values in the passive tracer (your labels), you will get into a lot of problems with the horizontal and vertical operators. By the way, we called them passive tracers because there are not contributing to the density of the fluid via an equation of state. I really don't know what the advection of your labels means... Well, all depends on the semantics... What do you mean by labels? I may think about labels as a particular (continuous) concentration of stuff (properties) in the fluid. But I don't think that this is what are you taking about....

This is not just a problem in ROMS but in any other model written in Fortran that operates on spatial operators with NaNs.

In biology, sediment, stratigraphy, and so on, we think about the passive tracer as classes or fractions of a system that evolves with a particular transport equation (advection - diffusion). There are several tricks that can be done with the passive tracer equations to compute, for example, the age of a particular water mass or dye. There are various papers in the literature. Still we are working with the continuous properties of the fluid.

[rduran]

Dr. Arango,

Thank you for your answer.

I understand the discontinuity problem you mention, that is why the solution ended involving either keeping the Lagrangian Labels continuous by nesting in bigger domain or by using an alternative method (regular floats in this case).

Regarding the meaning of Lagrangian Label, well the beauty of math is that there is no room for ill-defined semantics when you have well-defined equations, please see equation 6 and 7 of the paper:

Kuebel Cervantes, B. T., J. S. Allen, and R. M. Samelson, 2004. Lagrangian characteristics of continental shelf flows forced by periodic wind stress. Nonlin. Proc. Geophys., 11, 3-16.

which can be found here:
http://people.oregonstate.edu/~kuebelb/ ... es_NPG.pdf

The behavior of these labels can be seen in figure 9 and 10

[arango]

Well, I kind of have an idea of what do you want to compute. You need a cross-section of Eulerian, Lagrangian, and Stokes velocities for your application. I will never get that from your initial posting above Still, I don't understand the role of passive tracers and much less the need to NaN lateral boundary conditions. In my opinion, your approach has lot of holes. If you publish this and describe your approach, you will get into a lot of troubles with the reviewers.

The velocities that you seek involve wave-induced circulation using a formulation of the radiation stress tensor. The Eulerian, Lagrangian, and Stokes velocities have a lot of physics that are just missing by computing Lagrangian trajectories and whatever labels mean. So you need to model the radiation stress properly. There are several methodologies for this. One approach was proposed by Mellor (2005, 2008, ...). He has several sequential papers about this with corrections to his methodology. There is a lot of criticism in the literature about his approach. Another approach is the vortex-force formalism (Uchiyama, 2010, Ocean Modelling, ROMS-UCLA). Also Fabrice Ardhuin has several papers for radiation stress formulations.

John Warner has been working on this for several years. Our version of ROMS has the Mellor (2005, 2008) formulation. See CPP NEARSHORE_MELLOR**. Notice that ROMS already output the velocities that you seek when this is activated. However, as I mentioned above, there is criticism with the Mellor's formulation.

If this is the main part of your dissertation, you need to experiment with these methodologies instead. I am not an expert on this but I know others that may help you. Perhaps, John Warner can advise you about this and comment on his experiences with these algorithms.

[rduran]

Thank you very much, all of this is good to know. My dissertation's first two parts are 1) a kinematic description of the Eulerian and Lagrangian flow for a poleward undercurrent off the US West coast (41 to 48 N) as seen through a ROMS simulation and 2) a follow up dynamical description.

Mean lagrangian velocities can be calculated from the final and initial positions of water parcels by using the lagrangian labels. Preliminary results seem to show that the lagrangian label technique works nicely inside the domain but when a parcel comes from outside the domain (for example when water enters through a northward flow at the southern boundary -the undercurrent as seen through NCOM which is used for boundary conditions) then you can't know the exact initial position anymore (unless using nested grids would work for this purpose, but I do not intend to do at this time). The problem is that any parcel that entered the domain gives an unreliable Lagrangian velocity.


You are probably right in that the paper I gave as a reference could be well suited for NEARSHORE_MELLOR, but for the undercurrent region (say between 150 and 600m deep west of the 200m isobath), I don't think we would be considering the appropriate kind of waves and their physics unless nearshore has an unexpected meaning here. I will look up the papers for future reference.

Im thinking rather computing the Stokes velocities directly from the mean Lagrangian (say through using floats) and mean Eulerian velocities. Stokes velocities can (possibly) also be computed directly from the Eulerian field (see for example eq. 4 of Longuet-Higgins 1969 - on the transport of mass by time-varying ocean currents). It seems like the Stokes velocities will turn out to be relatively small for the undercurrent in this simulation but I might want further verification through using floats.


Any and all suggestions are more than welcome!

Rodrigo