[MITgcm-support] Problem with MNC initialization

Mon Oct 11 13:55:31 EDT 2004

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