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

[LDM #WDO-168362]: Conduit ERE ldmd.conf: problems getting vertical motion and status



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[5464] 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.