Deal with inconsistent RA/DEC keywords in marx parameter file and aspect file

[hamogu]

Thanks to Pat Broos for reporting this:

I think you may be interested in a discussion I had with Kenny (via CXC Helpdesk ticket 16386) in May of 2015.

A change to the CIAO command wcs_update in CIAO 4.7 led to an astrometric inconsistency between event data and MARX-generated PSF images in AE extractions. I subsequently modified AE to work around this problem, so I do not need you to do anything.

However, I thought you might want to modify MARX to warn non-AE users that run into this issue. My discussion with Kenny is long and complex, but the bottom line for you is described in the following excerpts from my original ticket:

We use MARX to generate PSF images for each of our sources. Just like APE, MARX has access to two sets of RA_NOM/DEC_NOM values. On the command line, MARX is passed RA_Nom and Dec_Nom parameters; we pass the original (archive) values. Via the DitherFile parameter, MARX is also passed the aspect file; in CIAO 4.7 this will contain modified RA_NOM/DEC_NOM values. Unlike APE, the event list produced by MARX adopts the new SKY coordinate system defined by the modified dither file. We thus end up with two different SKY systems in our project, which causes all sorts of issues.

I believe the only suggestion I can offer is that both APE and MARX could be modified to throw an error and halt if the two sets of NOM keywords they have been given are not identical, on the assumption that such a mismatch strongly suggests that the observer has a flawed workflow.

[hamogu]

I'm not sure this warrants an error. If the user does not specify a RA_NOM or DEC_NOM on the command line, there will still be some number in the marx.par file. Setting the asol option just overrrides that number and there is plenty of precedence of one keyword making another one non-functional (e.g. when reading a spectrum from a file, MaxEnergy will be ignored). Can I see inside marx if the keyword was set on the command line or in the marx.par? If there is an easy way, I could error out only if the wrong number is set on the command line. If not, all I can do is to print a warning.

[hamogu]

There is code in marx.c (line 330-355) that's currently commented out, but could deal with a similar issue for TStart and TStop that I could easily modify to address this issue.