Subject: periodic pts in dt

From: Ben Foster <[email-masked]>
Date: Thu, 21 Apr 2005 10:25:57 -0600 (MDT)

Wenbin:

I am about to save tiegcm1.8dev2, and wanted to check up on your
comment from last September, copied below. I made 2 10-day runs,
one with the periodic points set in dt, and one without. After
10 days, there were *zero* differences between the runs for the
major fields, including Z (t,u,v,o2,o,no,n4s,ne,te,ti,o2p,w,poten,z)

When you got inconsistent values for zl and zp, were you printing
these numbers directly from the model, or saving them to secondary
histories and then using the processors? 

The model saves i=3,74 to the histories (it does not save the
periodic points), so the arrays on the histories are dimensioned 
72. The processor reads these values into i=1-72, and sets 73 <- 1.
I understand that the pp in dt are used in dldp (duv.F), but why 
should we take the time (including mpi) to set the periodic pts in
dt if they have no effect on the final results?

--Ben

>Hi, Ben

in dt.F in versions of tiegcm I see that subroutines that set periodic
points for updated neutral temperature are commented out. I belive that we
need values at those periodic points for updated temperatures in subroutine
dldp in duv.F, when calculating second order derivatives of the potential
height. Could you please double check this? I got inconsistent values for
zl and zp at i=3,4 and i=73, 74. Or may be just a problem for the Linux
version I have?

Thanks

Wenbin

-----------------------------------------------------------------------
Ben Foster		      	High Altitude Observatory (HAO)
[email-masked]			phone: 303-497-1595  fax: 303-497-1589  
Nat. Center for Atmos. Res.     P.O. Box 3000 Boulder CO 80307 USA
-----------------------------------------------------------------------

---

From: Wenbin Wang <[email-masked]>
Date: Thu, 21 Apr 2005 15:11:53 -0600

Ben

In subroutine dldp when calculating zl and zp at grid points lonbeg and lonend
you need values of zin at grid points lonbeg-1 and lonend+1
zin is defined in subroutine glp as ztmp which is in turn obtained using 
tn_upd.
Thus you need period points of tn_upd at i=2 and i=75 to do the calculation 
of Zl and ZP.

You did not blow up the model, and got "identical" results after 10 days in 
your test runs, You are
lucky. This is probably because Bluesky or Lightning initiate those 
undefined points of tn_upd to zeros or pickup some numbers that are close 
to tn. This, however, does not mean that we should not correct this bug 
since if people run the model on a different platform or use a different 
compiler, these undefined points may be assigned to random numbers instead 
of zeros and blow up the model. This happened to me.

I printed these numbers directly form the model, not from the post-processor.

So I would add period points to tn_upd even this may slow down the code (MPI).

Regards

Wenbin