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