[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