[MITgcm-support] exf /obcs not opening forcing files

[Martin Losch]

Hi Jill,

you need something like the attached EXF_OPTIONS.h in your code  
directory (it's basically a copy of the ECCO_CPPOPTIONS.h file in the  
lab_sea/code directory).
also I don't know if commenting out "exf_yftype='RL'," is the right  
thing to do (although 'RL' is the default). This could be the reason  
for the 1e32 in the obcs values.

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: EXF_OPTIONS.h
Type: application/octet-stream
Size: 1143 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20060925/777148da/attachment.obj>
-------------- next part --------------

On Sep 25, 2006, at 9:32 AM, jschwarz at awi-bremerhaven.de wrote:

> Hi Martin,
> Here are the /input/data* and /code/* files..
> thanks, goodnight and good luck (:
> jill.
>
>
>
> ----- Original Message -----
> From: Martin Losch <mlosch at awi-bremerhaven.de>
> Date: Monday, September 25, 2006 6:50 pm
> Subject: Re: [MITgcm-support] exf /obcs not opening forcing files
>
>> Hi Jill,
>> can you post all your "data.*" files and the content of you "code"
>> directory?
>>
>> there is some "historical" connection between exf and ecco, but you
>>
>> can move all of the exf-relevant stuff of ECCO_CPPOPTIONS.h to a
>> EXF_OPTIONS.h file
>>
>> Martin
>>
>> On Sep 25, 2006, at 7:03 AM, jschwarz at awi-bremerhaven.de wrote:
>>
>>> Hi all,
>>>
>>> Another question from the beginner's corner:  With exf and obcs
>>> packages listed in /code/package.config, and useOBCS=TRUE in
>>> data.pkg, and make reporting no errors; exf and obcs packages
>> both
>>> look fine..  I am unable to convice exf to even attempt to open
>> my
>>> open boundary initialisation files or the daily forcing data
>>> files.  In the runtime output blurb, data.obcs is read, the open
>>> boundaries are reported, velocities at the boundary are
>> initialised
>>> to junk (e+32) and t, s to the reference values.  As data.exf is
>>> processed, the blurb actually reports that all the input
>> filenames
>>> are ' '.  This is despite setting ALLOW_OBCS_PRESCRIBE and
>> careful
>>> checking that i'm reading and writing at precision 32bits, and
>>> specifying input files (which do exist) as in /verification and
>>> Matt's examples.
>>>
>>> It seems that exf only attempts to initialise from external
>> forcing
>>> files if it finds #define ALLOW_ATM_TEMP/WIND etc; but i only
>> found
>>> references to these settings in the ecco options file - surely
>> ecco
>>> isn't required for exf?
>>>
>>> And also;  when i switch on seaice, i get the following compile
>> error:> **************************
>>> In file budget.f:1396
>>>
>>>         ATEMP(I,J,bi,bj)=MAX(273.16d0+MIN_ATEMP,ATEMP(I,J,bi,bj))
>>>                         1
>>> Error: Statement function at (1) is recursive
>>>  In file budget.f:1397
>>>
>>>         LWDOWN(I,J,bi,bj)=MAX(MIN_LWDOWN,LWDOWN(I,J,bi,bj))
>>>                          1
>>> Error: Statement function at (1) is recursive
>>>  In file budget.f:1448
>>>
>>>      &       +D1*UG(I,J)*ATEMP(I,J,bi,bj)+D1I*UG(I,J)*AQH(I,J,bi,bj)
>>>                                                         1
>>> Error: Function 'aqh' at (1) has no IMPLICIT type
>>>  In file budget.f:1454
>>>
>>>      &       +D1*UG(I,J)*ATEMP(I,J,bi,bj)+D1I*UG(I,J)*AQH(I,J,bi,bj)
>>>                                                         1
>>> Error: Function 'aqh' at (1) has no IMPLICIT type
>>>  In file budget.f:1517
>>>
>>>             QSWI(I,J,bi,bj)=-(ONE-ALB(I,J))*SWDOWN(I,J,bi,bj)
>>>                                                  1
>>> Error: Function 'swdown' at (1) has no IMPLICIT type
>>> make: *** [budget.o] Error 1
>>> ******************************************************
>>> .. any ideas why?  (This is using checkpoint58)
>>>
>>> At the risk of being verbose.. i'm listing the initialisation
>>> section of the output text (a 3step trial with no seaice, using
>> all
>>> dummy input files - no time variation, just constant fields, not
>>> that it matters because the files never get opened..)  at the end
>>
>>> of this.
>>> Any help appreciated!
>>> cheers,
>>> jill.
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> <jillcode.tar>
>> <jilldata.tar>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support