Christian, > I have been struggling for many days to get a correct ERE for REQUEST > in ldmd.conf for CONDUIT to add vertical motion (GFS). > > I currently have, for CONDUIT in ldmd.conf (I have to limit because of > bandwidth and server limited performance). It is on rpc.ldmd NOTE: > Starting Up (version: 6.7.0; built: Dec 15 2008 20:50:30). It is an old > version because the server is old (and will be replaced very soon). > > request CONDUIT > "prod/gfs.*grbf.*PMSL|prod/gfs.*grbf.*HGHT|prod/gfs.*grbf.*P..M|prod/gfs.*grbf.*RELH/2.m|prod/gfs.*grbf.*TMPK|prod/gfs.*grbf.*TMXK03|prod/gfs.*grbf.*TMNK03|prod/gfs.*grbf.*CLD|prod/gfs.*grbf.*HGT*FRZH|prod/gfs.*grbf.*UREL*/10m|prod/gefs.*TMPK/850" The ERE above can be shortened to "prod/((gfs.*grbf.*(PMSL|HGHT|P..M|RELH/2.m|TMPK|TM[XN]K03|CLD|UREL*/10m)|gefs.*TMPK/850)" The substring "UREL*", however, means "UREL" followed by zero or more "L"s. Is that what you want? > request CONDUIT > "awip3d.*PMSL|awip3d.*HGHT|awip3d.*P..M|awip3d.*RELH/2.m|awip3d.*TMPK|awip3d.*TMXK03|awip3d.*TMNK03|awip3d.*CLD|awip3d.*HGT*FRZH|awip3d.*UREL*/10m|prod/gfs.*grbf.*UREL.*/..0|prod/gfs.*grbf.*RELH/2.m|prod/gfs.*grbf.*CLD|prod/gfs.*grbf.*PRES/0*NONE" The ERE above can be shortened to "(awips3d.*(PMSL|HGHT|P..M|RELH/2.m|TMPK|TM[XN]K03|CLD|HGT*FRZH|UREL*/10m))|(prod/gfs.*grbf.*(UREL.*/..0|RELH/2.m|CLD|PRES/0*NONE)) Again, the questionable string "UREL*" appears, as do the strings "HGT*" and "0*". > request CONDUIT > "status|awip3d.*UREL*/..0|awip3d.*VREL*/..0|awip3d.*WX|gfs.*grbf.*UREL.*/850|gfs.*grbf.*WX|gfs.*grbf.*OMEG" The ERE above can be shortened to "status|awip3d.*([UV]REL.*/..0|WX)|gfs.*grbf.*(UREL.*/850|WX|OMEG)" -- assuming the "REL*" strings should, instead, be "REL.*". You should test your patterns by executing a notifyme(1) process -- with the pattern as an argument -- that connects to the upstream LDM, e.g., notifyme -vl- -f CONDUIT -p "status|awip3d.*([UV]REL.*/..0|WX)|gfs.*grbf.*(UREL.*/850|WX|OMEG)" -o 3600 -h upstream.ldm.site > and in pqact.conf > CONDUIT ^.status\.(.*) [0-9][0-9][0-9][0-9][0-9][0-9] > FILE -close data/models/conduit/status/\1 > CONDUIT prod/gfs\.(..........)/gfs.*pgrbf(.*)\.grib > FILE data/models/conduit/gfs/\1_\2_gfs.grib > CONDUIT prod/nam\.(........)/nam\.t(..)z.awip3d(.*)\.tm > FILE data/models/conduit/nam/\1\2_\3_nam.grib You can also use the same notifyme(1) test with the above patterns -- to either the upstream LDM or to the local LDM. I tried them here and the first two worked. I didn't get anything from the third but that could be because that model hasn't come in yet. > However, even with OMEG I don't get it in the output file. I also tried to > add status, but it doesn't get written to disk... but if I use ldmadmin > watch -f CONDUIT I get the headers, but no VVEL or OMEG. So it points > out to the ERE in ldmd.conf. > > And it doesn't explain why I do not get status. I don't have error when > starting LDM, or when running. > > Any clues? > > Thanks! > > Cheers, > > Christian PagÃ > UQAM Regards, Steve Emmerson Ticket Details =================== Ticket ID: WDO-168362 Department: Support LDM Priority: Normal Status: Closed
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.