[MITgcm-support] Initialization question

[William Aiken]

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