[MITgcm-devel] Re: it's probably my faults again, but ...
Martin Losch
Martin.Losch at awi.de
Tue Mar 6 03:31:40 EST 2007
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
More information about the MITgcm-devel
mailing list