[Met_help] [rt.rap.ucar.edu #67152] History for MET-TC installation at NHC

John Halley Gotway via RT met_help at ucar.edu
Tue May 20 09:40:50 MDT 2014


----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

I'm working on moving MET-TC to the location at NHC where it will be
initially run.  I tried transporting the version that was put together on
jet during my recent visit to DTC, and tc_stat works fine, but tc_dland and
tc_pairs do not.  Both give me an error message that they are looking for
the location of "ConfigConstants".  Is there a way to override the location
of ConfigConstants, so it knows to look in a local directory?

ERROR  : MetConfig::read(const char *) -> unable to open input file
"/lfs1/projects/neo-cp/dzelinsky/met_tc/METv4.1/data/config/ConfigConstants"

(/lfs1/... is the location on jet where it was originally built)


-David Zelinsky


----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: Re: [rt.rap.ucar.edu #67152] MET-TC installation at NHC
From: John Halley Gotway
Time: Tue May 20 09:29:50 2014

Dave,

Yes there is.  At run time, the MET tools read some static data files
that are included in the MET release, such as ConfigConstants.  At
compilation time, the top-level directory of the MET
installation is stored in a variable named MET_BASE, and those static
data files are defined relative to MET_BASE.

However, you can set MET_BASE as an environment variable, and that
should override the setting defined at compilation time.  We did that
for this very reason - people compiling MET somewhere but
moving it somewhere else.  Please try setting the MET_BASE environment
variable to the current top-level directory for MET (e.g.
/home/dzelinsky/METv4.1), and then try rerunning.

Thanks,
John Halley Gotway
met_help at ucar.edu

On 05/20/2014 07:14 AM, David Zelinsky - NOAA Affiliate via RT wrote:
>
> Tue May 20 07:14:12 2014: Request 67152 was acted upon.
> Transaction: Ticket created by david.a.zelinsky at noaa.gov
>         Queue: met_help
>       Subject: MET-TC installation at NHC
>         Owner: Nobody
>    Requestors: david.a.zelinsky at noaa.gov
>        Status: new
>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67152 >
>
>
> I'm working on moving MET-TC to the location at NHC where it will be
> initially run.  I tried transporting the version that was put
together on
> jet during my recent visit to DTC, and tc_stat works fine, but
tc_dland and
> tc_pairs do not.  Both give me an error message that they are
looking for
> the location of "ConfigConstants".  Is there a way to override the
location
> of ConfigConstants, so it knows to look in a local directory?
>
> ERROR  : MetConfig::read(const char *) -> unable to open input file
> "/lfs1/projects/neo-
cp/dzelinsky/met_tc/METv4.1/data/config/ConfigConstants"
>
> (/lfs1/... is the location on jet where it was originally built)
>
>
> -David Zelinsky
>

------------------------------------------------
Subject: MET-TC installation at NHC
From: David Zelinsky - NOAA Affiliate
Time: Tue May 20 09:36:03 2014

That did the trick.  I defined MET_BASE within my .sh script (just
starting
with the one you wrote a couple weeks ago), but forgot to set it as an
environment variable.  Thanks!

-Dave


On Tue, May 20, 2014 at 11:29 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Dave,
>
> Yes there is.  At run time, the MET tools read some static data
files that
> are included in the MET release, such as ConfigConstants.  At
compilation
> time, the top-level directory of the MET
> installation is stored in a variable named MET_BASE, and those
static data
> files are defined relative to MET_BASE.
>
> However, you can set MET_BASE as an environment variable, and that
should
> override the setting defined at compilation time.  We did that for
this
> very reason - people compiling MET somewhere but
> moving it somewhere else.  Please try setting the MET_BASE
environment
> variable to the current top-level directory for MET (e.g.
> /home/dzelinsky/METv4.1), and then try rerunning.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On 05/20/2014 07:14 AM, David Zelinsky - NOAA Affiliate via RT
wrote:
> >
> > Tue May 20 07:14:12 2014: Request 67152 was acted upon.
> > Transaction: Ticket created by david.a.zelinsky at noaa.gov
> >         Queue: met_help
> >       Subject: MET-TC installation at NHC
> >         Owner: Nobody
> >    Requestors: david.a.zelinsky at noaa.gov
> >        Status: new
> >   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67152 >
> >
> >
> > I'm working on moving MET-TC to the location at NHC where it will
be
> > initially run.  I tried transporting the version that was put
together on
> > jet during my recent visit to DTC, and tc_stat works fine, but
tc_dland
> and
> > tc_pairs do not.  Both give me an error message that they are
looking for
> > the location of "ConfigConstants".  Is there a way to override the
> location
> > of ConfigConstants, so it knows to look in a local directory?
> >
> > ERROR  : MetConfig::read(const char *) -> unable to open input
file
> >
> "/lfs1/projects/neo-
cp/dzelinsky/met_tc/METv4.1/data/config/ConfigConstants"
> >
> > (/lfs1/... is the location on jet where it was originally built)
> >
> >
> > -David Zelinsky
> >
>
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #67152] MET-TC installation at NHC
From: John Halley Gotway
Time: Tue May 20 09:40:48 2014

Dave,

Glad that fixed it.  Just let us know if you have any more questions
in your use of MET.

Thanks,
John

On 05/20/2014 09:36 AM, David Zelinsky - NOAA Affiliate via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67152 >
>
> That did the trick.  I defined MET_BASE within my .sh script (just
starting
> with the one you wrote a couple weeks ago), but forgot to set it as
an
> environment variable.  Thanks!
>
> -Dave
>
>
> On Tue, May 20, 2014 at 11:29 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Dave,
>>
>> Yes there is.  At run time, the MET tools read some static data
files that
>> are included in the MET release, such as ConfigConstants.  At
compilation
>> time, the top-level directory of the MET
>> installation is stored in a variable named MET_BASE, and those
static data
>> files are defined relative to MET_BASE.
>>
>> However, you can set MET_BASE as an environment variable, and that
should
>> override the setting defined at compilation time.  We did that for
this
>> very reason - people compiling MET somewhere but
>> moving it somewhere else.  Please try setting the MET_BASE
environment
>> variable to the current top-level directory for MET (e.g.
>> /home/dzelinsky/METv4.1), and then try rerunning.
>>
>> Thanks,
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On 05/20/2014 07:14 AM, David Zelinsky - NOAA Affiliate via RT
wrote:
>>>
>>> Tue May 20 07:14:12 2014: Request 67152 was acted upon.
>>> Transaction: Ticket created by david.a.zelinsky at noaa.gov
>>>          Queue: met_help
>>>        Subject: MET-TC installation at NHC
>>>          Owner: Nobody
>>>     Requestors: david.a.zelinsky at noaa.gov
>>>         Status: new
>>>    Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=67152 >
>>>
>>>
>>> I'm working on moving MET-TC to the location at NHC where it will
be
>>> initially run.  I tried transporting the version that was put
together on
>>> jet during my recent visit to DTC, and tc_stat works fine, but
tc_dland
>> and
>>> tc_pairs do not.  Both give me an error message that they are
looking for
>>> the location of "ConfigConstants".  Is there a way to override the
>> location
>>> of ConfigConstants, so it knows to look in a local directory?
>>>
>>> ERROR  : MetConfig::read(const char *) -> unable to open input
file
>>>
>> "/lfs1/projects/neo-
cp/dzelinsky/met_tc/METv4.1/data/config/ConfigConstants"
>>>
>>> (/lfs1/... is the location on jet where it was originally built)
>>>
>>>
>>> -David Zelinsky
>>>
>>
>>

------------------------------------------------


More information about the Met_help mailing list