[MITgcm-devel] Re: it's probably my faults again, but ...
Martin Losch
Martin.Losch at awi.de
Tue Mar 6 10:34:19 EST 2007
Good question. I am not sure, what's going on in all these routines,
so I am just reporting what I find. It is very well possible that the
problem that I found in exf_bulkformulae is really connected to some
way that these fields are manipulated while they are being read. It
is striking, that this problem appears only in
1. the exf package
2. only when there are holes in the domain (5 tiles are empty in my
case)
maybe, someone has an idea what to check next?
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
More information about the MITgcm-devel
mailing list