Astrometry, like photometry, requires good data to get a good result. The process to derive an astrometric solution is a complex one and is described in brief in http://www.astro-wise.org/portal/howtos/man_howto_astrom/man_howto_astrom.shtmlHOW-TO Derive Astrometry, and in detail in the ftp://ftp.strw.leidenuniv.nl/pub/ldac/software/pipeline.pdfLDAC pipeline documentation and many other astrometry references.
The scope of this document is to describe specific things that can go wrong in an astrometric solution and approaches to improve the astrometric solution, both in the context of the Astro-WISE Environment.
If a correction method below refers to a parameter to be set, it can be set through the http://www.astro-wise.org/portal/howtos/man_howto_configure/man_howto_configure.shtmlprocess parameters interface. In short:
> pars = Pars(AstrometricPatameters) > pars.process_params.SOME_VALUE = 100 > ... > AstrometricParametersTask(..., pars=pars.get()).execute()
As with any aspect of data reduction, a good rule of thumb if you have any problem with astrometry, inspect the data if no obvious error presents itself. Please take a look at http://www.astro-wise.org/portal/howtos/man_howto_qcastrom/man_howto_qcastrom.shtmlHOW-TO Inspect Astrometry to see how this is done in the Astro-WISE Environment.
LDAC is the software suite used to create the astrometric solution, whose steps are given in http://www.astro-wise.org/portal/howtos/man_howto_astrom/man_howto_astrom.shtmlHOW-TO Derive Astrometry. Despite (or because of) the best efforts of programmers, software can always have problems or can exit for very specific reasons. To help make the error messages less cryptic, LDAC's Python wrapper has been upgraded to output an ordered list of debugging information in case of a software failure. All individual programs linked by a common instance of the LDAC class (e.g., preastrom, associate, aplastrom, astrom, etc.) will have their output logged where it normally would have been supressed so that any warnings preceeding the failure can be seen.
The normal output of an individual LDAC program will show only the command-line, the program version, and program description. If an error occurs, the configuration file, warnings, and errors are also added to this output. If there are programs run from the same LDAC instance, those that have run will have their full output preceeding the output of the failed program. The bottom line is that errors should be easier to diagnose for both the user and the programmer.
Viewing the log output is the best way to try and troubleshoot any astrometry error. The LDAC class instance has verbosity set to NORMAL by default which gives the minimum of information when all is well, and everything when there is a problem. By setting the individual routine settings to VERBOSE (or even DEBUG) instead:
> pars = Pars(AstrometricPatameters) > pars.preastromconf.VERBOSE = 'VERBOSE' > ... > AstrometricParametersTask(..., pars=pars).execute()will increase the verbosity in the event of an error. If you need even more and want as much information as LDAC can produce, you can set the LDAC class verbosity in the code to VERBOSE or DEBUG:
ldac = LDAC.LDAC(verbose='DEBUG') ... ldac.preastrom(...) ...This latter method is recommended only if it is absolutly necessary, as it involves code changes and a very large amount of program output to go through.
If the solution fails with a software exception, deciphering the output is the only way to figure out what happened. The terminal Exception (the very last error message) should contain some indication of what happened. If there is no help there, a perusal of the previous log messages can be helpful. If they are not, posting the output to the http://www.astro-wise.org/portal/issues_mailing_list.shtmlIssues list is the quickest way to get expert help.
Below are included some very common log messages that may indicate specific problems. Some terms are defined for this section only for clarity:
Astrometric solutions in Astro-WISE, like all other calfiles, have QC limits to determine if the calfile has the required quality. If these limits are exceeded, the solution is marked as bad and there may be methods to help improve the quality. This section addresses specific cases where quality may be improved.
Low NREF (number of output reference pairs) can be caused by a number of situations, from low SNR data (low EXPTIME), to very sparce fields, to large differences in filter band between the extracted and reference catalogs. There are two ways that too low an NREF can harm a solution:
To improve a solution with an NREF too low where either of these situations occurred, more reference pairs are necessary. There are a few ways to accomplish this. One method would involve decreasing the extraction threshold:
Usually, more reference pairs are better, but only to a certain limit. If the
density of sources is too high (e.g., greater than approximately 1200 in a
2kx
Very little can be done to help this kind of data other than trying to decrease
the number of reference pairs by decreasing the number of extracted sources.
This can be done by increasing the extraction threshold:
If the standard deviation of 1#1
What is being adjusted here is the factor of the object's size (actually
an ellipse as set by the source extraction parameters RA, DEC, a, b, 2#2
In addition to software exceptions and QC limit issues, the data can be
of such a type to prevent a solution from converging. This section describes
some specific configurations that can be adjusted to fix certain problems.
The first step of solving astrometry in Astro-WISE is running preastrom
to solve the translation, rotation, and scaling of the input data.
The recommendations below have been incorporated into the AstrometricParameters routines as a fallback in case preastrom fails
with the basic settings. If there are still preastrom failures at the
more conservative settings, inspect the data to make sure there is nothing
unusual, and proceed carfully.
The first step of preastrom is measuring distances between all objects
and examining the (1#1
If inspection of the logs of failed preastrom runs reveals the number of
extracted and reference objects are similar and number on the order of 100,
there may be a shift beyond the default value of MAX_OFFSET. Inspect the
frame as shown in
http://www.astro-wise.org/portal/howtos/man_howto_qcastrom/man_howto_qcastrom.shtmlHOW-TO Inspect Astrometry
to see if this is the case. If so, increase the value of MAX_OFFSET to larger
than the offset observed. Be aware, however, that if the object density
increases in parts of the border area (e.g., presence of a clutser), increasing
MAX_OFFSET may have unpredictable results.
After the (1#1
If excessive scaling or moderate rotation (
3#3
Once the subset of data is chosen, a triangulation method using angle and
distance is used to determine the final rotation and scaling (affine
transformation), and final offsets. If the RMS of the fit is above RMS_TOL,
SEL_MIN will be increased to choose a larger number of sources and
triangulation will proceed iteratively to try to reduce the RMS below RMS_TOL.
In practice, this iteration seldom improves things due to the nature of the
method and the quality of the input data. Setting a higher RMS_TOL is usually
the only way to overcome this affine transformation determination error.
Increasing both RMS_TOL and SEL_MIN will allow a poorer quality
preastrometric fit to continue through the pipeline, where the final solution
may or may not be of good quality.
After the gross, linear corrections have been made, the reference and
extracted sources can be associated using associate. associate has
really only one parameter to help improve the precision of the solution. This
is the distance within which objects will be associated, and are represented by
the two parameters ISO_COLOR_TOL and INTER_COLOR_TOL.
The definitions and optimizations of these parameters was described in
§ above. Repeating, INTER_COLOR_TOL is for associations
between sources in different catalogs (e.g., extracted and reference catalogs),
ISO_COLOR_TOL is for associations between sources in the same catalog (e.g.,
a joined extracted catalog). Setting these to lower values can result in a
more precise fit, but should be used with care.
The PDEG parameter describes the polynomial degree used to map the observed
sky, the pixel image, denoted by (x,y) to the idealized sky denoted by
(4#4
The FDEG parameter is a list that describes how the mapping of the PDEG
degree polynomial occurs from pointing to pointing. The first value
in the list maps linear terms (order 1), the second, quadratic terms (order
2), etc. Only the first 3 can ever be changed. Based on the value of each
list element, the polynomial coefficents of different pointings can be mapped
to each other linearly (FDEG index 1), quadratically (FDEG index 2), etc., or
held constant (FDEG index 0). For example, in the default case:
For single chip fields, it is unlikely that a PDEG >
Please note, this does nothing to decrease the number of reference sources! As
such, the helpfullness off this method is limited. In addition to reducing the
number of extracted objects, the association radius between the extracted and
reference catalogs:
should be decreased to reduce the chance of false associations. An associated
parameter, ISO_COLOR_TOL, has no effect for local solutions involving only
onechip. Changing it in this case is unnecessary.
1.1.2.3 SIG_DRA or SIG_DDEC, or RMS too high
to lower values will do just this with respect to sources in a reference
catalog, and adjusting:
will affect only overlapping sources in the same catalog (e.g., global
solutions).
1.1.3 Problems with the Solution
1.1.3.1 preastrom
1.1.3.2 MAX_OFFSET
1.1.3.3 POS_ERROR
1.1.3.4 RMS_TOL & SEL_MIN
1.1.3.5 associate
1.1.3.6 ISO_COLOR_TOL & INTER_COLOR_TOL
6#6
1.1.3.7 astrom
FDEG = [1, 0, 0]
indicates all first order terms will be mapped linearly between pointings
and all higher order terms will be held constant. Similar to PDEG, as FDEG's
total value increases, so increases the number of associations and spatial
uniformity required to converge.
Footnotes