Tracer timestepping question

[kate]

Ken Coyle and I are trying to solve an issue in the tracer timestepping. I posted about it on the ROMS blog, but still haven't figured it out. Apparently, the t(nnew) value at the point in the timestepping in which the biology is computed has a value that's temperature*Hz. However, when the water gets shallow, there's got to be more to it than that:

t(nnew) = 0.2405811213519759
Hz = 6.26551716187506713E-3
t(nnew)/Hz = 38.397647813636787 (Temperature as seen by biology)

The other timelevel of t is 0.48, more reasonable for a Bristol Bay wintertime temperature. Ken is searching for temperatures that get above 35 (rather than simply clamping as some biology options do). The surface elevation is -11.216 and h is 11.479, making for very shallow water, but the wet/dry mask is still showing wet.

Can someone explain what is going on here and what we should do about it? I don't see clamping as a viable option since temperatures of 35 in the winter are still going to produce erroneous growth rates.

[arango]

I have to think very carefully about this one. I not sure if we need a Hz(i,j,k,nold) and Hz(i,j,k,nnew). Or do we need to have the source/sink tems in transport form tracer*Hz which complicate matters.

[kate]

It's not just a question of the old Hz - I checked it. Hz has only changed by maybe 20%, not the factor required to explain this.

[andreykoch]

Hello Kate,

I wonder has the problem you reported above been solved or not? Now I deal with a similar one being puzzled about unrealistic temperature values (~50C) when I read t(nnew) instead of t(nstp) in my npzd-type model.

Andrey

[kate]

We "solved" it by increasing the bottom drag in an experimental way so that the water depth doesn't get that drastically shallow. It also allows us to turn off the WET_DRY option. We still get the occasional blow up which can be gotten over by shortening the timestep for some while (which also increases the maximum drag allowed).