readParfile.C string matches against "QUAD"/"quad", which breaks tempo2 when DMEQUAD present in parfile

[Former user]

A new wideband-related parameter, DMEQUAD, is being introduced into tempo, enterprise (which uses tempo2 via libstempo), and PINT. Even though tempo2 does not yet utilize these (or other wideband-related) parameters, it breaks with a bizarre clock correction error, which I've traced to line 983 in readParfile.C, where it matches the strings "QUAD" and "quad", but checks that the parameter is not T2EQUAD. I've added a similar line to check that it is not DMEQUAD (see attached), which solves the problem. You can reproduce the error by simply adding a line like "DMEQUAD -f Rcvr1_2_GUPPI 0.0001" to any working parfile and try running tempo2.

[Tim Pennucci]

Use this one; the other has an edit w.r.t. the default TNRedC setting.

[Michael Keith]

Fix from Tim Pennucci for DMEQUAD.

Fixes bug #62

→ <<cset 8e8cd036c4de>>

[Michael Keith]

I have to say that this is a kind of odd method that matches the QUAD, but I guess string handling in C is often awkward. I comitted your patch in 8e8cd03

[Tim Pennucci]

Thank you!