[MITgcm-support] more KPP blues, maybe related?

[Martin Losch]

Hi again,

found the problem, but I don't take the blame, when I left MIT, 
everything was working fine (o:
for MDJWF, rho is computed as the ratio of the two polynomials 
N(umerator) and D(enomiator): rho = N/D
In find_alpha (exactly the same is true for find_beta) alpha is 
computed as
alpha = 1/D*( dN/dT - rho*dD/Dt).
This worked fine until someone (I think I know who, but not me) changed 
the output of find_rho from rho to rho-rhoConst, so that the rho in 
find_alpha is on the order of 10 instead of 1000, so that alpha is now 
on the order of 1 instead of 1e-2.

I suggest a further change in find_alpha/beta: Instead of calling 
find_rho and find_rhoden I suggest calling find_rhonum and find_rhoden, 
and then compute the density "online". In find_rho, both 
pressure_for_eos and find_rhoden are called again, so that we might 
loose the advantage of the "faster" MDJWF polynomial.

What do you think? Do you have the time to think about this at all? Or 
should I just check this stuff in (maybe tomorrow, when you are all 
asleep (o: )? There are no verification experiments that use the MDJWF 
EOF, so there shouldn't be any interference ...

Martin


On Monday, October 27, 2003, at 02:26  PM, Martin Losch wrote:

> Chris,
>
> I was about to write an email. I think I have localized the problem, 
> but I haven't fixed it. It doesn't have anything to do with KPP but 
> with the equation of state. And as usual, I am to blame for all the 
> trouble:
> The problem only occurs with I use
> eosType='MDJWF',
> so the super-duper new, latest, fantastic EOS by McDougall et al. 
> (2003), but it's not the equation of state itself but probably alpha 
> (in find_alpha), that's wrong. And since find_alpha/beta is only 
> called from somewhere within kpp_routines.F and nobody ever uses MDJWF 
> together with KPP (probably nobody every uses MDJWF to begin with, 
> there's no test case for it), nobody has ever had the problem. I am 
> glad that I am only responsible for my loss of time.
>
> I'll try to fix the problem (it's probably just a wrong coefficient or 
> so) and then you can decide when or if I can check it in.
>
> Martin
>
> On Monday, October 27, 2003, at 02:15  PM, Chris Hill wrote:
>
>> Martin,
>>
>>  Could you put your setup on-line at MIT (if its not already there)
>> somewhere? There are a couple of other coarse resolution KPP issues 
>> that
>> people have found here (though not of the 30-40 day blow up sort). It
>> would be good to get Dimitris to take a quick look at the various 
>> setups
>> people have while he is here this week.
>>
>> Thanks,
>>
>> Chris
>>
>>
>>
>>> -----Original Message-----
>>> From: mitgcm-support-bounces at mitgcm.org
>>> [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of Martin Losch
>>> Sent: Monday, October 27, 2003 3:29 AM
>>> To: mitgcm-support at mitgcm.org
>>> Subject: Re: [MITgcm-support] more KPP blues, maybe related?
>>>
>>>
>>> Hi again,
>>>
>>> I have made this mistake with the downward solar radiation, but
>>> unfortunately, this does not appear to be my real problem. I
>>> checked my
>>> input fields again, and I had another look at FFIELDS.h where I had
>>> already appreciated the ranges provided. I use net shortwave
>>> radiation
>>> (netsw) now. My fields are all in the proper ranges: (with Qnet =
>>> latent+sensible+netlw+netsw, that's the default for
>>> global_ocean.90x40x15, Qsw=netsw)
>>> -225 < Qnet < 442, FFIELDS.h says: Typical range: -250 < Qnet
>>> < 600 -321 < Qsw < 0, FFIELDS.h says: Typical range: -350 <
>>> Qsw < 0 and here may be the problem: -9 < Qnet-Qsw < 550
>>> which I think is what I should use for surfQFile
>>> together with surfQswFile
>>>
>>> As far as I understand, I can use either
>>> surfQFile = Qnet
>>> or
>>> surfQFile = Qnet-Qsw
>>> surfQswFile = Qsw
>>> I actually tried the combination
>>> surfQfile = Qnet
>>> surfQswFile = Qsw
>>> which doesn't make any sense to me because netsw is included
>>> twice. But
>>> only when I use surfQFile = Qnet alone (without surfQswFile)
>>> the model
>>> remains stable. The other two combinations above with KPP
>>> blow up after
>>> 30-45 days. It must be something really stupid, like a scale
>>> factor of
>>> 1000 somewhere, because the effect is so drastic.
>>>
>>> Also, when I turn off KPP in data.pkg, then the model appears to be
>>> stable with
>>> surfQFile=Qnet-Qsw; surfQswFile=Qsw;
>>>
>>> I am still hoping for a miracle.
>>>
>>> Martin
>>>
>>>
>>> On Sunday, October 26, 2003, at 05:28  PM, Dimitris Menemenlis wrote:
>>>
>>>>>> For SHORT_WAVE_HEATING input "Qsw" I use downward solar
>>> flux (with
>>>>>> oposite sign) which may be wrong (now I am almost sure
>>> it's wrong).
>>>>
>>>> Martin, if you are using a relatively recent version of the
>>> code, have
>>>> a
>>>> look at definitions at beginning of FFIELDS.h (or
>>> exf_fields.h if you
>>>> are using pkg/exf).  For each input field there is a
>>> typical range of
>>>> values.
>>>>
>>>> For global_ocean.90x40x15 experiment you need to use "net shortwave
>>>> radiation", which is different from "downward shortwave radiation",
>>>> and which is provided separately by NCEP.
>>>>
>>>> Note that if you are using pkg/exf, then you can specify either net
>>>> (swflux) or downward (swdown) shortwave radiation, and the
>>> model will
>>>> convert as needed:
>>>>
>>>> c--   Compute net from downward and downward from net longwave and
>>>> c     shortwave radiation, if needed.
>>>> c     lwflux = Stefan-Boltzman constant * emissivity * SST - lwdown
>>>> c     swflux = - ( 1 - albedo ) * swdown
>>>>
>>>> Hope this helps.
>>>>
>>>> One last thing, there is a small but finite chance that sign
>>>> convention for Qnet and Qsw may change for release 2.  So
>>> make sure to
>>>> take a look at FFIELDS.h and at exf_fields.h when you
>>> download release
>>>> 2.
>>>>
>>>> D.
>>>>
>>>> --
>>>> Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
>>>> Jet Propulsion Lab, California Insitute of Technology
>>>> MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099
>>>> tel: 818-354-1656;  fax: 818-393-6720
>>>>
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support