[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IDV #RJZ-602723]: error with grib file on RAMADDA

I see. So it has nothing to do with the installation of the TDS on Brian's machine, but rather the TDS that is shipped with RAMADDA.

The default place for the CDM to put the index files is alongside the file itself; in the event the user running the TDS does not have permission (which user tomcat does not), then it defaults to ${home}/.unidata. The user tomcat does not have permission to create that directory on Brian's machine, so no love for caching in RAMADDA at the moment. The TDS needs to be able to write out the index files somewhere, and at the moment, it has no place to do so.

I created a soft link (/opt/tds-live/.unidata) to point to /data/repository/.unidata, which has the correct permissions for the user tomcat. Things appear be working now.

Jeff, it would be useful if there could be an option in the repository.properties config file for the user to be able to set the location of the tds cache location, rather than trying to define a set place in the threddsConfig.xml. The IDV sets the location in DataManager; is there a similar central manager in RAMADDA where this can be done? I can take a look at this tomorrow.



On 3/9/14, 4:38 AM, Jeff McWhirter wrote:
The TDS and RAMADDA are in the same JVM so there may be some shared
global state.

Is the path "/opt/tds-live/.unidata/cache" being set in the TDS config
or is that the default GRIB index path and it doesn't exist.

As I said - RAMADDA does not set any GRIB config in its
threddsConfig.xml. What needs to be set in the config?


On Sat, Mar 8, 2014 at 7:41 PM, Sean Arms <address@hidden
<mailto:address@hidden>> wrote:

    No sure what's going on here. The TDS will only index files that it
    has cataloged, and the ECMWF files are not cataloged.

    TDS and RAMADDA are running in different tomcat installs.
    /opt/tds-live is the apache tomcat directory for TDS; RAMADDA is in
    /opt/repos. I cannot think of any reason as to why an index file
    would be in the .unidata folder.

    Brian, are you by any chance trying to run the IDV on the machine to
    generate images on RAMADDA? Is that something Tom setup for you?


On 3/8/14, 12:29 PM, Jeff McWhirter wrote:

        There might be some global setting the TDS uses

        On Saturday, March 8, 2014, Brian Mapes <address@hidden
        <mailto:address@hidden>__>> wrote:

             Thanks Jeff.

             I think Sean set up our TDS, Sean does this ring any bells?
             I didn't realize RAMADDA drew on that somehow.


On Mar 8, 2014, at 6:34 AM, Jeff McWhirter <address@hidden <mailto:address@hidden> <javascript:_e(%7B%7D,'cvml','address@hidden <mailto:address@hidden>');>> wrote:

Yuan - If you looked at the actual error you would see that it is a server side error - not an IDV error. If you go to the opendap link page: http://weather.rsmas.miami.__edu/repository/opendap/synth:__601aa404-ac59-4abb-8c4f-__11c08474a214:LzIwMTEtMTAuZ3Ji/__entry.das <http://weather.rsmas.miami.edu/repository/opendap/synth:601aa404-ac59-4abb-8c4f-11c08474a214:LzIwMTEtMTAuZ3Ji/entry.das>

                 This is the error:

/opt/tds-live/.unidata/cache/__data2-brian-DYNAMO-ECMWF-__analysis-2011-10.grb.gbx9 (No such file or directory)

                 The question is is why is RAMADDA pointing to
            /opt/tds-live/... as
                 the place to write GRIB caches to? In RAMADDA we write
            out the
                 threddsConfig.xml to define the subset service
            directory but we
                 don't do anything with the GRIB settings:
                   Writing GRIB indexes.

I am assume there is also a TDS running under the same TOMCAT? I would guess that it has set some configuration options.

                 Yuan - this should be looked at by the TDS folks


             Brian Mapes
        address@hidden <mailto:address@hidden>

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.