[MITgcm-devel] Re: it's probably my faults again, but ...
Jean-Michel Campin
jmc at ocean.mit.edu
Wed Mar 7 15:58:07 EST 2007
Hi Martin,
OK, I start to unsterdand why I had problems to see whether
the stress was at center or u/v point.
But, I am not qualified to tell was is logical and good to
change in exf, and please feel free to revert the changes in
exf_wind.F and exf_bulkformulae if it's needed.
And if there is something to save from my previous check-in,
we can see later.
Jean-Michel
On Wed, Mar 07, 2007 at 09:12:58PM +0100, Martin Losch wrote:
> 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list