[MITgcm-devel] vermix test experiment

[Jean-Michel Campin]

Hi Martin,

I will change the EOS in vermix test and generate new outputs.

Regarding sigmaR, looks like it was there in the 1rst version
of do_oceanic_phys.F (before pkgs my82, ggl90, pp81) and
was before in thermodynamics.F (since the 1rst version, in 2001).
We can put this (using sigmaR instead of the 2 find_rho calls)
on the list of to-do things, if you don't see any problem with this.
I was thinking of changing some of those find_rho calls (again !)
to store the 3-D in-situ density anomaly in a common block;
could make those changes at the same time.

And BTW, thanks for checking this EOS check stuff.

Cheers,
Jean-Michel

On Thu, Aug 21, 2008 at 01:33:58PM +0200, Martin Losch wrote:
> Hi Jean-Michel,
>
> great, go ahead with eosType='MDJWF'. The reason, why the wrong k-level 
> gives the same result is probably because the tref and sref are constant 
> with k.
>
> sigmaR: when I wrote these pkgs, sigmaR was not around. Maybe it's  
> really worth replacing the buoyancy computation with this field. I won't 
> have time for this in the next 2 weeks, so if you want to go ahead, feel 
> free.
>
> Martin
>
> On 12 Aug 2008, at 14:34, Jean-Michel Campin wrote:
>
>> Hi Martin,
>>
>> I was thinking of changing verification/vermix/input/data
>> to switch from Linear EOS to eosType='MDJWF', (it's already
>> there, but commented out):
>> The reason is that when I was changing all those "call find_rho"
>> in all those vertical mixing scheme pkg (by the way, most of
>> those calls could be removed just by using sigmaR),
>> I intentionally added a bug (wrong k reference level) to check
>> how wrong it was, and with linear EOS, the results were identical
>> (no change, with or without the bug).
>> Since those tests (vermix.*) are just there to check
>> all those pkg, it would be better to make it more selective
>> (and indeed, with MDJWF, the bug shows up clearly in the output).
>> Plus, I don't see any experiment which is testing this EOS,
>> is it right ? this could be an additional good reason.
>>
>> Cheers,
>> Jean-Michel
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel