obstime conversion in xmltompc80col

[federicaspoto]

@stevechesley I have another request.

In xmltompc80col, the conversion of the obstime field is done in the following way: sexDate = sexVals.isoToSexDate(item['obsTime'], precTime), where precTime (and the other precision) is defined as an input argument:

   # Set obs80 precision constants
   defaultPrecTime = '1'
   defaultPrecRA = '0.001'
   defaultPrecDec = '0.01'
   if args.lowPrec:
      defaultPrecTime = '10'
      defaultPrecRA = '0.01'
      defaultPrecDec = '0.1'

I know we discussed about this multiple times and it is true that the MPC is using high precision for both RA and Dec. We noticed that at MPC we don't always use high precision for the conversion of obstime, but we dynamically set the precision according to the submission. Would it be okay to do something similar in xmltompc80col? I'd be happy to change the code, if you agree.

Thanks! Federica

[stevechesley]

@federicaspoto I recall that the consensus was that if the original submission was in obs80 then the script will use the prec* fields to reproduce the original obs80 record. The prec* fields are required for obs80 (and earlier) submissions and disallowed for ADES submissions.

On the other hand, if the prec* fields are not missing then the conversion should be done so that the time, RA and Dec fill all available columns.

This means that the default values above (not those for the lowPrec argument) should give the desired behavior. I've tested this and it seems to hold. I grabbed some XML from a recent DOU and made some minor edits to precTime. The XML is here: K24F89_short.xml.txt and the output is

01685         C2024 03 06.69552 07 16 22.69 -00 24 04.2          14.2 Rq4-F89168
01685         C2024 03 06.70665007 16 24.350-00 23 58.09         14.4 Rq4-F89168
01685         C2024 03 06.71500007 16 25.570-00 23 53.59         14.4 Rq4-F89168
01685         C2024 03 26.11953507 59 56.719+01 44 11.18         15.65oV4-F89W68

Here you can see that precTime is 10 on the first record, 1 on the second record and missing on the last two records, which use the default value of 1.

All seems correct to me, and so perhaps I do not understand the issue here.

[federicaspoto]

@stevechesley the issue does not happen in the case of obs80 submissions, because, as you said, the prec fields are populated. The prec fields are not populated for ADES submissions and this is when the issue happens. This observation has been submitted is ADES XML:

 <optical>
    <provID>2014 WO573</provID>
    <mode>CMO</mode>
    <stn>L87</stn>
    <obsTime>2024-03-07T22:20:34Z</obsTime>
    <ra>189.16838</ra>
    <dec>-24.97268</dec>
    <rmsRA>0.32</rmsRA>
    <rmsDec>0.32</rmsDec>
    <astCat>Gaia3E</astCat>
    <mag>18.9</mag>
    <rmsMag>0.23</rmsMag>
    <band>G</band>
    <photCat>Gaia3E</photCat>
    <photAp>23.0</photAp>
    <logSNR>0.98</logSNR>
    <exp>450</exp>
    <rmsFit>0.38</rmsFit>
    <notes>K</notes>
  </optical>

and the obs80 was stored in the database as (using the MPC's conversion code): K14Wv3O KB2024 03 07.93095 12 36 40.411-24 58 21.65 18.9 GX~7ugrL87

Using xmlto80col.py, the conversion becomes: K14Wv3O KB2024 03 07.93094912 36 40.411-24 58 21.65 18.9 GX L87 and as you can see, the obstime has one more digit here.

In this case the prectime field is not populated because the observation came in ADES format and the conversion done in xmlto80col.py set prectime to 1 by default.

[stevechesley]

I think I'm starting to understand this issue: You want to change the behavior of xmlto80col.py to match what the MPC code is (or was) doing.

But I'm not sure why since (I think) xmlto80col.py currently has the desired behavior. And it's not clear what behavior you would select for converting obsTime to decimal date for obs80 records.

It seems better to revise the times in the database rather than modifying xmlto80col.py to match what was done in the past for the db. And even if you don't update the db values it's not clear that there is a problem with leaving xmlto80col.py as is.

Still not sure that I have a complete understanding here, but I would prefer to not degrade xmlto80col.py if it can be avoided.