[MITgcm-devel] sunos, open_copy_data_file, and data.cal
Martin Losch
mlosch at awi-bremerhaven.de
Sun May 29 14:00:06 EDT 2005
hey, thanks for the quick help, but it's Sunday, isn't it? I wasn't
expecting anything before Monday ... dedication is a curse (o:
Martin
On May 29, 2005, at 7:42 PM, Patrick Heimbach wrote:
> Hi Martin,
>
> I changed a few pkg_readparms.F this week (cal, exf, ctrl, cost,
> grdchk).
> I replaced all calls to nml_filter by calls to open_copy_data_file
> since the latter is more versatile (e.g. it adds the namelist
> output to stdout).
>
> open_copy_data_file is the "routine of choice" for all core MITgcm
> readparms routines (data, data.gmredi, data.pkg).
> Not clear to me right now what's the problem with cal.
> I'll have a look.
>
> -p.
>
>
>
>> -----Original Message-----
>> From: mitgcm-devel-bounces at mitgcm.org
>> [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Chris Hill
>> Sent: Sunday, May 29, 2005 1:30 PM
>> To: MITgcm-devel at mitgcm.org
>> Subject: Re: [MITgcm-devel] sunos, open_copy_data_file, and data.cal
>>
>>
>> Hi Martin,
>>
>> one possibility.
>> open_data_copy_file creates a temporary file.
>> where that temporary file gets created (i.e. what
>> directory) depends
>> on the compiler and the os etc...
>> i have seem problems where the location (maybe /tmp)
>> becomes full or
>> is unwritable for some reason. i haven't seen that for a
>> long time but
>> given the vintage of some of your machines maybe that could
>> be whats
>> going on.
>> depending on the os there may be an environment variable
>> to change
>> where the temp file gets created.
>>
>> one thing that doesn't fit is that all experiments use
>> open_copy_data_file.
>>
>> Chris
>> Martin Losch wrote:
>>> Hi,
>>>
>>> I run testreport every week on two of our Sun-Machines,
>> both of them
>>> have Solaris9, but I run with different compiler versions
>> (forte7 and
>>> studio9).
>>> This week's test (last night) fails for the only two
>> experiments that
>>> use data.cal (and the calendar package pkg/cal, lab_sea and
>>> global_with_exf). As you can see from, e.g.,
>>>
>> http://mitgcm.org/testing/results/2005_05/tr_rays1_20050529_
> 0/lab_sea/
>> run.log
>> the model stops when opening a data file (it's data.cal). I had a look
>> in the repository, but I cannot see any changes that have been made to
>> either open_copy_data_file.F nor the verification experiments in
>> question in the last week. Last Sunday things still worked. Before I
>> embark on tedious debugging execises, does anyone have an idea, what
>> might be going on?
>>
>> Martin
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list