[MITgcm-devel] Re: it's probably my faults again, but ...
Martin Losch
Martin.Losch at awi.de
Wed Mar 7 15:12:58 EST 2007
Jean-Michel,
I take some of my previous babbling back:
It does not make sense to compute u/vstress again in exf_bulkformulae
#ifndef ALLOW_ATM_WINDS, so at least that part of exf_bulkformulae.F
is a great improvement.
I suggest, that we revert exf_wind.F back to version 1.3, so that
uwind and vwind are computed #ifndef ALLOW_ATM_WINDS, and (more
importantly) so that us(i,j,bi,bj) and sh(i,j,bi,bj) are available
for the iteration in exf_bulkformulae.F where I propose to change
#ifdef ALLOW_ATM_WIND
ustar = rd*sh(i,j,bi,bj)
tau = atmrho*ustar**2
tau = tau*us(i,j,bi,bj)/sh(i,j,bi,bj)
#endif /* ALLOW_ATM_WIND */
to
ustar = rd*sh(i,j,bi,bj)
tau = atmrho*ustar**2
tau = tau*us(i,j,bi,bj)/sh(i,j,bi,bj)
so that tau is really computed (this is the problem in the case of
domain with wholes).
However, why is ustress^2+vstress^2 = 0 in the a few points? I think
the reason is that
#ifdef ALLOW_ATM_WINDS
u/vwind are defined a c-points and u/vstress are also computed at c-
points
#ifndef ALLOW_ATM_WINDS
u/vstress is read/defined at u/v-points and there can be places where
both u and v are dry and the c-point is wet. So maybe the easiest fix
is to replace the computation of tau, so instead of
tau = sqrt(ustress(i,j,bi,bj)*ustress(i,j,bi,bj)
& +vstress(i,j,bi,bj)*vstress(i,j,bi,bj))
compute
tau = .5*sqrt(ustress(i,j,bi,bj)*ustress(i,j,bi,bj)
& +ustress(i+1,j,bi,bj)*ustress(i+1,j,bi,bj)
& +vstress(i,j+1,bi,bj)*vstress(i,j+1,bi,bj)
& +vstress(i,j,bi,bj)*vstress(i,j,bi,bj))
Martin
On 7 Mar 2007, at 20:14, Martin Losch wrote:
> Hi Jean-Michel,
>
> I think, I want to revert exf_wind.F to version 1.3 (and
> exf_bulkformulae.F to version 1.12) because I want (need!) uwind
> and vwind to be computed from ustress and vstress in the case of
> #undef ALLOW_ATM_WINDS
> Also, we (Patrick and I) have tried to separate the heat/evap
> bulkformulae from the wind bulkformulae, now you have mixed them
> together in exf_bulkformulae again. Basically you have gone back to
> the version before the appearance of exf_wind.F and exf_radiation.F
>
> Our intention was that all exf files (stress and wind) are
> available after exf_getforcing independent of what is read from
> file. If our attempts did not result in similar fluxes, then this
> is a problem but still, the way it is now, it breaks a few setups
> that I need here.
>
> Will you try to revert the stuff or should I? My suggestion is that
> it is reverted and then we try to make the fluxes "similar".
>
> Martin
> On 6 Mar 2007, at 16:10, Jean-Michel Campin wrote:
>
>> Hi Martin,
>>
>> I think I did thoses changes in exf_bulkformulae.F (but I was
>> not aware that it was really used with #undef ALLOW_ATM_WINDS).
>> The goal was to get similar fluxes with winds or wind-stress
>> input (Ivana did some tests and I took part of her code in).
>> There are also lot of #ifdef/#else/#endif in this routine
>> so I might have missed something. Sorry for this problem.
>>
>> But when I look to the code (arround line 255):
>> #ifdef ALLOW_ATM_WIND
>> tmpbulk= exf_BulkCdn(sh(i,j,bi,bj))
>> rdn = sqrt(tmpbulk)
>> ustar = rdn*sh(i,j,bi,bj)
>> #else /* ifndef ALLOW_ATM_WIND */
>> tau = sqrt(ustress(i,j,bi,bj)*ustress(i,j,bi,bj)
>> & +vstress(i,j,bi,bj)*vstress(i,j,bi,bj))
>> ustar = sqrt(tau/atmrho)
>> #endif /* ifndef ALLOW_ATM_WIND */
>> I have the impression that ustar (and tau) are set properly
>> (well, at least they are defined), even with #undef ALLOW_ATM_WIND.
>> Is it because ustress & vstress are zero ?
>>
>> Jean-Michel
>>
>> On Tue, Mar 06, 2007 at 09:31:40AM +0100, Martin Losch wrote:
>>> News from my problem with topologies with holes: It may be connected
>>> to the exf-package, and the recent changes in the exf_bulkformulae.F
>>> file. Don't ask me why it doesn't appear in configurations without
>>> holes but here it is:
>>> ustar in bulkformulae is not updated anymore (ifndef
>>> ALLOW_ATM_WINDS)
>>> so that is can stay/become zero which leads to a division by zero in
>>>> hs(i,j,bi,bj) = atmcp*tau*tstar/ustar
>>>> hl(i,j,bi,bj) = flamb*tau*qstar/ustar
>>>> #ifndef EXF_READ_EVAP
>>>> cdm evap(i,j,bi,bj) = tau*qstar/ustar
>>>> cdm !!! need to change sign and to convert from kg/m^2/s to m/s !!!
>>>> evap(i,j,bi,bj) = -recip_rhonil*tau*qstar/ustar
>>>> #endif
>>> I cannot oversee why and where this goes wrong, but it goes wrong
>>> here (and before this place where ustar is evaluated to zero.
>>> when I revert exf_bulkformulae.F (in particular) and exf_wind.F to
>>> their respective previous versions (1.12 and 1.3) then the problem
>>> goes away.
>>>
>>> Martin
>>>
>>> On 27 Feb 2007, at 09:41, Martin Losch wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> I am using (almost) exactly one of Dimitris' configuration, just
>>>> with a different SIZE.h, w2_e2setup.F and W2_EXCH2_TOPOLOGY.h. I'll
>>>> attach these files for 91 tiles (again). If you cannot reproduce
>>>> the problems, then I will certainly check in my entire
>>>> configuration. Is that OK?
>>>>
>>>> Martin
>>>>
>>>> <s91t.tgz>
>>>>
>>>> On 26 Feb 2007, at 19:18, chris hill wrote:
>>>>
>>>>> martin,
>>>>>
>>>>> can you check one of your holes setups (code/, input/ etc..) into
>>>>> MITgcm_contrib/mlosch.
>>>>> then we can try it here.
>>>>>
>>>>> chris
>>>>> Martin Losch wrote:
>>>>>> Hi there,
>>>>>> I have further investigated the issue with domains with holes and
>>>>>> I have narrowed down the problem to checkpoint58u_post. All
>>>>>> checkpoints prior to this one seem to work with my cs32 setup
>>>>>> with 91 tiles. This is what supposedly happenend 58u:
>>>>>>> checkpoint58u_post
>>>>>>> o new test-exp: fizhi-cs-32x32x40 (40 levels) to replace the 10
>>>>>>> levels.
>>>>>>> o move call to INI_FORCING from PACKAGES_INIT_VARIABLES to
>>>>>>> INITIALISE_VARIA.
>>>>>>> o testreport: add option "-skipdir" to skip some test.
>>>>>>> o exf: when input wind-stress (#undef ALLOW_ATM_WIND), by-pass
>>>>>>> turbulent
>>>>>>> momentum calculation.
>>>>>>> o gad_advection: fix vertAdvecScheme (if different from
>>>>>>> advectionScheme)
>>>>>>> o some cleaning: usePickupBeforeC35 no longer supported ; remove
>>>>>>> this option.
>>>>>>> remove checkpoint.F and the_correction_step.F (no longer used);
>>>>>>> do the k loop inside CYCLE_TRACER (supposed to be more
>>>>>>> efficient).
>>>>>>> o add option (linFSConserveTr) to correct for tracer source/sink
>>>>>>> due to
>>>>>>> Linear Free surface
>>>>>>> o pkg/seaice: fix a bug in the flooding algorithm: turn off the
>>>>>>> snow machine
>>>>>>> o pkg/thsice: fix reading mnc-pickups
>>>>>> I don't see anything, that could affect exchanges. Do you? I
>>>>>> also did a diff on all files that I actually compile, which I
>>>>>> attach (I removed everything thing, that is just white space or
>>>>>> spelling difference in comments etc.), but I don't see anything
>>>>>> that could explain the NaN's in version 58t.
>>>>>> Martin
>>>>>> On 20 Feb 2007, at 21:04, Martin Losch wrote:
>>>>>>> rats, forgot to include blanklist.txt:
>>>>>>> 31
>>>>>>> 34
>>>>>>> 35
>>>>>>> 47
>>>>>>> 79
>>>>>>>
>>>>>>> M.
>>>>>>>
>>>>>>> On 20 Feb 2007, at 21:01, Martin Losch wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I have run a quick test with the appended stuff, (cs32 with 91
>>>>>>>> 8x8 tiles) and the model produces NaNs right away, in the first
>>>>>>>> timestep. So there appears to be something broken in exch2?
>>>>>>>> (after my great lapse last week I dare not claim anything
>>>>>>>> anymore).
>>>>>>>>
>>>>>>>> Martin
>>>>>>>> <s91t.tgz>
>>>>>>>>
>>>>>>>> On 20 Feb 2007, at 18:44, Martin Losch wrote:
>>>>>>>>
>>>>>>>>> Dimitris,
>>>>>>>>>
>>>>>>>>> the reason why I think it's the seaice-ice model (but the
>>>>>>>>> problem may very well have nothing to do with the seaice-
>>>>>>>>> model, but only show up in the seaice model first) is that the
>>>>>>>>> monitor output has valuse of > 1e173 for u/vice_del2 while all
>>>>>>>>> other variables look ok for time step 1440 (which is the time
>>>>>>>>> step of the pickup, that is at this point nothing has
>>>>>>>>> happended so far, and the do_the_model_io and monitor packages
>>>>>>>>> are called from initialise_varia.
>>>>>>>>>
>>>>>>>>> which one is the cs32 test, so I can try it, too?
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> On 20 Feb 2007, at 18:32, Dimitris Menemenlis wrote:
>>>>>>>>>
>>>>>>>>>> Martin, I am transferring your e-mail to devel list as Chris
>>>>>>>>>> or others may have comments. What makes you think that it is
>>>>>>>>>> the sea-ice model that causes trouble? I have used the
>>>>>>>>>> s1500t_17x51/SIZE.h_500 configuration in the past
>>>>>>>>>> successfully but have not done so in a very long time. What
>>>>>>>>>> is special about this configuration is that there are holes
>>>>>>>>>> in the domain, i.e., no computations take place over some of
>>>>>>>>>> the land.
>>>>>>>>>>
>>>>>>>>>>>>> MY QUESTION TO THE DEVEL LIST IS WHETHER ANYONE ELSE HAS
>>>>>>>>>> USED
>>>>>>>>>>>>> DOMAINS WITH HOLES RECENTLY?
>>>>>>>>>>
>>>>>>>>>> I don't think that this part of the exch2 package is tested
>>>>>>>>>> on regular basis, so it may be broken. I am in process of
>>>>>>>>>> rearranging the description of experiments, etc., as per your
>>>>>>>>>> suggestions and there is a small test with holes on the
>>>>>>>>>> 32x6x32 domain that I plan to test and get back. D.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> ... just to make sure that I am not trying something stupid:
>>>>>>>>>>> After having
>>>>>>>>>>> made one day of integration on 216 CPUs (and actually
>>>>>>>>>>> picking up and running
>>>>>>>>>>> a second day with 216 CPUs), I have tried using a higher
>>>>>>>>>>> number of CPUs
>>>>>>>>>>> (which is more effective on the machine that I am running
>>>>>>>>>>> on), that is the
>>>>>>>>>>> SIZE.h_500 in the s1500t directory. So I replaced SIZE.h
>>>>>>>>>>> with SIZE.h_500 and
>>>>>>>>>>> w2_ee2setup.F and W2_EXCH_TOPOLOGY.h and recompiled. Then I
>>>>>>>>>>> tried to restart
>>>>>>>>>>> from the same pickup, from which I have already successfully
>>>>>>>>>>> started with
>>>>>>>>>>> 216CPUs. The model starts (after waiting 4days in the queue)
>>>>>>>>>>> and seems to
>>>>>>>>>>> pickup fine, at least the model part.
>>>>>>>>>>> [ now it's definitely my fault, that I send this email
>>>>>>>>>>> prematurely, sorry for
>>>>>>>>>>> that ]
>>>>>>>>>>> I am attaching the stdout, and you can see that something is
>>>>>>>>>>> wrong with the
>>>>>>>>>>> seaice model and then the first timestep is already very
>>>>>>>>>>> wrong. My eedata is
>>>>>>>>>>> correct this time. And I am using the MULTICATEGORY seaice
>>>>>>>>>>> (all the way, it's
>>>>>>>>>>> also in the pickup files), but that shouldn't make a
>>>>>>>>>>> difference, should it?
>>>>>>>>>>> So my question is really: Do you regularily use this
>>>>>>>>>>> configuration at all or
>>>>>>>>>>> have I made one of my famous mistakes again?
>>>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list