> Thank you. Let us know if you need specifics on configuration other > than what Hoop has already posted. > > Don > > On 7/26/12 6:26 PM, Unidata THREDDS Support wrote: > >> John- > >> > >> On 7/25/12 5:37 PM, Unidata THREDDS Support wrote: > >>> This problem only affects NcML joinExisting aggregations. > >> > >> Thanks for that clarification. > >> > >>> If there's a problem with FMRC FeatureCollections, its a seperate problem > >>> that we dont know about. > >> > >> When Hoop first sent his messages to the thredds mailing list about the > >> NcML aggregation not working, he was told by Ethan to use the > >> FeatureCollection instead to fix the problem. He did and the problem > >> still persisted and reported the problem there. Ethan suggested several > >> things which did not solve the issue. So, if you only tested the NcML > >> aggregation, then perhaps you can review the conversation on the thredds > >> list: > >> > >> https://www.unidata.ucar.edu/mailing_lists/archives/thredds/2012/msg00138.html > >> > >> and test the FeatureCollection as well. > > > > Lansing will try to recreate the problem with FMRCs. > > > > > > Ticket Details > > =================== > > Ticket ID: YRL-997326 > > Department: Support THREDDS > > Priority: Normal > > Status: Open > > > > -- > Don Murray > NOAA/ESRL/PSD and CIRES > 303-497-3596 > http://www.esrl.noaa.gov/psd/people/don.murray/ > > Don, I've been working with some of the data files that Hoop previously provided for me (SST for a few years, with two different length versions for 2012) to reproduce the issue in fmrc that manifests. Basically, I set up a collection with full years 2009-2011 and a partial year for 2012 (through May 13=4, 2012). I fire up the tds, look at the collection, etc. Then I switch the 2012 file for one that goes through May 15, 2012. I've found a couple of interesting things. First off, it appears that fmrc is working in the current release of tds 4.2. However, there is an error in updating catalog metadata, which results in a catalog page that appears out of date, i.e., it appears not to pick up the modified file. However, clicking through to an access page (opendap in this case) reveals that the changes have been picked up by the tds. This is also evidenced looking at the collection with toolsui. Second, there seem to be a couple of gotchas in play, perhaps environmental. I have been battling some sort a shadow issue that manifests from time to time. It is possible that you are seeing this in your installation, as well. To see if this is the case, we would need to look at a fresh set of log files from the current stable tds release - particularly the featureCollectionScan.log and others in /content/thredds/logs. Here is the snippet from my catalog for the fmrc: <featureCollection featureType="FMRC" name="hoop_issue" harvest="true" path="hoop2"> <metadata inherited="true"> <serviceName>ncdods</serviceName> <dataFormat>netcdf</dataFormat> <documentation type="summary">Constantly changed and updated modeled sea surface temperatures</documentation> </metadata> <collection spec="/C:/Users/madry/hoop2/sst.day.mean.#yyyy#.v2.nc$" name="modeled_SST" olderThan="1 min"/> <update startup="true" rescan="0 * * * * ? *" trigger="allow"/> <protoDataset choice="Penultimate" change="0 2 3 * * ? *" /> <fmrcConfig regularize="false" datasetTypes="TwoD Best Files Runs ConstantForecasts ConstantOffsets" /> </featureCollection> It would be good to establish whether the behavior that I have observed manifests in your configuration. -Lansing Ticket Details =================== Ticket ID: YRL-997326 Department: Support THREDDS Priority: Emergency Status: Open
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.