[MITgcm-support] Problem with MNC initialization

Mon Oct 11 14:18:23 EDT 2004

Hi Baylor,

 I think another temporary fix is to revert to the latest "checkpoint" rev
of the mnc package. To do this I would do something like
cd pkg/
mv pkg/mnc pkg/mnc.hidden
cvs co -r checkpoint55 -d mnc MITgcm/pkg/mnc

Then do a make CLEAN and redo genmake2 etc... for your experiment.
If checkpint55 pkg/mnc doesn't work with latest code, then I would try a
pkg/mnc fron "checkpoint55b_post". It looks like some mnc changes went in
after that - see

http://mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/doc/tag-index?rev=1.365&content
-type=text/vnd.viewcvs-markup

Chris 

> -----Original Message-----
> From: mitgcm-support-bounces at mitgcm.org 
> [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of 
> Baylor Fox-Kemper
> Sent: Monday, October 11, 2004 1:56 PM
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] Problem with MNC initialization
> 
> Hi Chris and Patrick and Ed,
>    I don't have ifc yet, and I really wanted to do some runs 
> while I'm away later this week, so I'm working on a fix here.
> 
>    The problem seems to lie in the way that the 'scalar' 
> version of mnc_cw_rs is interpreted by my compiler.
>    When you send the first element of an array like xc to
> mnc_cw_rs_w(...,xc,...) then you relabel the first element as 
> var inside, the compiler doesn't look in the same place in 
> memory when accessing var(i).  Apparently, only the first 
> element is matched.  So, if you do
> 
> print *, xc
> before
> call mnc_cw_rs_w
> 
> Then you get all the xc values.
> 
> If you do
> 
> do i=1,247
>     var(i)
> enddo
> 
> inside mnc_cw_rs_w, you get all sorts of crazy stuff...Only 
> the first element, the var(1) element matches...
> 
> Hope that helps...
>    -Baylor
> 
> On Oct 11, 2004, at 1:30 PM, Chris Hill wrote:
> 
> > Hi Baylor,
> >
> >  Ed is fixing this as I write. This seems to have started happening 
> > late last week. Patrick reports that things appear for his 
> codes with 
> > ifc (see below), so he suggests that as a temporary work around 
> > (either that or use this as an excuse to go and enjoy the beautiful 
> > fall weather).
> >
> > Chris
> >
> >
> > Ed,
> >
> > two things:
> >
> > 1.
> > Using ifc I don't get a seg. fault,
> > so this might be a good work around for people wanting to use mnc.
> >
> > 2.
> > I think, unrelated to this issue is that, e.g. for lab_sea, I no 
> > longer get monitor output:
> > grep dynstat output.txt
> > gives nothing, but
> > grep dynstat ../results/output.txt\
> > gives plenty of output.
> >
> > -Patrick
> >
> >
> >
> >> -----Original Message-----
> >> From: mitgcm-devel-bounces at mitgcm.org 
> >> [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Ed Hill
> >> Sent: Sunday, October 10, 2004 11:57 AM
> >> To: MITgcm-devel
> >> Subject: RE: [MITgcm-devel] useMNC not in PARAMS.h ?
> >>
> >>
> >> On Sun, 2004-10-10 at 10:12, Patrick Heimbach wrote:
> >>> Hi Ed,
> >>>
> >>> it's not clear to me how you got the clean testreport.
> >>> The seg. fault on lab_sea and dic_example persist with an 
> entirely 
> >>> fresh checkout as of now (9:36am).
> >>>
> >>> I've traced down the problem to S/R MNC_CW_RS_W_OFFSET and within 
> >>> there to the loop over j2, ..., j7 but got lost then.
> >>>
> >>> -Patrick
> >>>
> >>> PS:
> >>> platform is sea.mit.edu
> >>>> uname -a
> >>> Linux sea 2.4.24-openmosix2 #1 Wed Jul 28 14:33:52 CEST 2004 i686 
> >>> unknown
> >>
> >>
> >> Hi Patrick,
> >>
> >> Yes, this is a head-scratcher for me, too.  I got the clean 
> >> testreport runs on both my laptop and the black Athlon 
> desktop in my 
> >> office (both are running FC2) and thought I was done.  Then this 
> >> morning I saw the failed faulks tests and could reproduce the seg 
> >> faults with gdb showing that it dies in mnc_cw_rl_w_offset().
> >>
> >> I'll keep at it and send news as soon as I can determine exactly 
> >> whats b0rked and why.  In the mean time, please either 
> disable MNC or 
> >> roll back to the MNC version in the last checkpoint if you 
> need the 
> >> MNC functionality.
> >>
> >> Ed
> >>
> >> --
> >> Edward H. Hill III, PhD
> >> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
> >>              Cambridge, MA 02139-4307
> >> emails:  eh3 at mit.edu                ed at eh3.com
> >> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> >> phone:   617-253-0098
> >> fax:     617-253-4464
> >>
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> >>
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> >
> >> -----Original Message-----
> >> From: mitgcm-support-bounces at mitgcm.org 
> >> [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of Baylor 
> >> Fox-Kemper
> >> Sent: Monday, October 11, 2004 1:14 PM
> >> To: mitgcm-support at mitgcm.org
> >> Subject: [MITgcm-support] Problem with MNC initialization
> >>
> >> Hello,
> >>    I'm having a problem with the most recent cvs update with mnc.  
> >> When the model initializes, I get a seg fault.  I am using 
> g77 on Mac 
> >> OSX.
> >> The debugging info is:
> >>
> >> When the original 'state' file is written in ini_model_io:
> >> C     Write coordinates to "state" file
> >>        CALL MNC_CW_SET_UDIM('state', 0, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'XC',xC, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'YC',yC, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'XU',xG, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'YU',yC, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'XV',xC, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'YV',yG, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'XG',xG, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'YG',yG, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'RC',rC, myThid)
> >>        CALL MNC_CW_RS_W('R','state',0,0,'RF',rF, myThid)
> >>
> >> The mnc_cw_rs_w dies when it calls:
> >>
> >>        var_arr(1) = var
> >>        CALL MNC_CW_RS_W_OFFSET(stype,fbname,bi,bj,vtype, var_arr,
> >>       &     offsets, myThid)
> >>
> >> Ultimately, this stems from a call inside this routine 
> indicated with 
> >> the arrow:
> >>
> >>        IF (stype(1:1) .EQ. 'R') THEN
> >>          DO j1 = s(1),e(1)
> >>            k1 = k2 + j1
> >>            kr = kr + 1
> >> ==>          resh_r(kr) = var(k1)
> >>          ENDDO
> >>
> >> In my particular run, this crashes when k1=247, but I'm 
> sure that's 
> >> setup specific.
> >>
> >> Since var is this subroutine's version of var_arr, and var_arr in 
> >> this instance is xc, which is an 80x30=2400 array, I am 
> puzzled why 
> >> this crashes before k1=2400.
> >>
> >> Running with -fbounds-check doesn't seem to improve the problem...
> >>
> >> Thanks,
> >>     -Baylor
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> >>
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> 