[MITgcm-support] Initialization question

[Martin Losch]

Hi Bill,

a few more things that may be helpful. The problem with the generic  
routines is that you never know where they were called from. Only  
from looking at the general calling tree, the first time that  
MSD_READ_FIELD is called is from INI_CURVILINEAR_GRID (if you are  
using that, see "data", PARM04, usingCurvilinearGrid=.true.),  
otherwise it's called in ini_depth (via read_rec_xy_rs ->  
mdsreadfield -> mds_read_field ) and should then be the topography  
file.(data, PARM05, bathyFile).

Which experiment are you using in  your tests?

Martin

On 15 Jun 2007, at 23:00, William Aiken wrote:

> Martin,
>
>  Lots of great ideas in your email!
>
> I started with checkpoint58.tar, maybe it's older than I thought.
>
> My version has mdsio_readfield.F, which contains the statement
> SUBROUTINE MDSREADFIELD(...
>
> In my shorthand summary below, I used lower case and maybe dropped  
> some
> underline characters along the way.
>
> I used the ugly technique of inserting print statements in my  
> version of
> several of these routines to determine where the IEEE unhappiness  
> first
> occurs. That's how I identified which open statement was being used to
> the file that contained at least one NaN value.
>
> I decided it was "unnamed" because I added a write(6,*)dataFName line
> and got no printable characters when the file was opened. Later call
> through this same logic resulted in .bin files being opened, and their
> names did print out.
>
> This code is at the very beginning and the numbers in the file vary
> wildly, as if no data has yet been written to the files, which is a
> possiblity. I just didn't have the time to trace back to where the  
> file
> was first created, but I think this might be the first time.
>
>> So the name of the file is dataFName. What's the value of dataFName?
>> It should be the name of your file that holds the initial values of
>> theta, as specified in "data", namelist PARM05, hydrogThetaFile =  
>> '???',
>>
>> If this file contains random values or NaNs it may have to do with a
>> big/little endian issue (which can be fixed by setting a compiler
>> flag or a CPP-flag _BYTESWAPIO in the build_options file)?
> I'll check into this some more on Monday.
>
> Thanks again for your ideas.
>
> Bill
>
>
> Martin Losch wrote On 06/15/07 16:42,:
>> Hi Bill,
>>
>> that's great, I have once tried to trace down this warning/error but
>> was not persistent enough. I am not an expert on the mdsio pkg, but I
>> know so much about it that I never touch it (o:
>>
>> Seriously, after having a quick look at the code I found that
>> mdsio_readfield.F no longer exists, but now it's called
>> mdsio_read_field.F (and the subroutine is also called
>> MDSIO_READ_FIELD, called frorm MDSREADFIELD called from
>> READ_FLD_XYZ_RL). Can you reproduce this warning with the latest  
>> code?
>>
>> Also: in mdsio_read_field, how do you know it's an "unnamed" global
>> file? There is this statement in mdsio_read_field:
>>              OPEN( dUnit, file=dataFName, status='old',
>>       &            access='direct', recl=length_of_rec )
>> and the read statement is
>>                READ(dUnit,rec=irec) r4seg
>> So the name of the file is dataFName. What's the value of dataFName?
>> It should be the name of your file that holds the initial values of
>> theta, as specified in "data", namelist PARM05, hydrogThetaFile =  
>> '???',
>>
>> If this file contains random values or NaNs it may have to do with a
>> big/little endian issue (which can be fixed by setting a compiler
>> flag or a CPP-flag _BYTESWAPIO in the build_options file)?
>>
>> Martin
>>
>> On 14 Jun 2007, at 21:05, William Aiken wrote:
>>
>>
>>> I have been investigating why I get
>>>
>>>
>>>> STOP: NORMAL END
>>>>
>>>>> Note: IEEE floating-point exception flags raised:
>>>>>    Inexact;  Invalid Operation;
>>>
>>> messages when I build and run the exp2 model and verification case
>>> on my Solaris x64 system.
>>>
>>> I followed the logic through:
>>>
>>> main
>>> the_main_model
>>>  initialize_varia
>>>   ini_fields
>>>    ini_theta
>>>     read_fld_xyz_rl
>>>      mdsio_readfield
>>>       mdsio_seg4torl
>>>
>>> I'm opening an unnamed global file in mdsio_readfield, reading each
>>> record into r4seg and passing this array to MDS_SEG4toRL, where the
>>> data
>>> is copied to array arr. The values in r4seg seem to be random,
>>> differing
>>> by 30 orders of magnitude or more, but at least one of the values is
>>> -NaN. The above IEEE warnings are triggered when this value is
>>> copied to
>>> arr.
>>>
>>> I'd like to sanitize this part of MITgcm to detect NaN's when  
>>> reading
>>> the input, but am an MITgcm newbie and unsure where the best  
>>> place in
>>> the code is to do these checks.
>>>
>>> Is mdsio_readfield the best routine to change in this case, or is
>>> there
>>> another routine which writes the random data to a file which is then
>>> read by mdsio_readfield?
>>>
>>> Any suggestions?
>>>
>>> Thanks,
>>>
>>> Bill
>>>
>>> -- 
>>> William Aiken          Sun Microsystems, Inc.
>>> Phone: 781.442.3312    Market Development Engineering
>>> FAX: 781.442.1678      One Network Drive UBUR01-204
>>>                       Burlington, Massachusetts 01803
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> -- 
> William Aiken          Sun Microsystems, Inc.
> Phone: 781.442.3312    Market Development Engineering
> FAX: 781.442.1678      One Network Drive UBUR01-204
>                        Burlington, Massachusetts 01803
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support