A Use cases

# VaST: a variability search toolkit

## Abstract

Variability Search Toolkit (VaST) is a software package designed to find variable objects in a series of sky images. It can be run from a script or interactively using its graphical interface. VaST relies on source list matching as opposed to image subtraction. SExtractor is used to generate source lists and perform aperture or PSF-fitting photometry (with PSFEx). Variability indices that characterize scatter and smoothness of a lightcurve are computed for all objects. Candidate variables are identified as objects having high variability index values compared to other objects of similar brightness. The two distinguishing features of VaST are its ability to perform accurate aperture photometry of images obtained with non-linear detectors and handle complex image distortions. The software has been successfully applied to images obtained with telescopes ranging from 0.08 to 2.5 m in diameter equipped with a variety of detectors including CCD, CMOS, MIC and photographic plates. About 1800 variable stars have been discovered with VaST. It is used as a transient detection engine in the New Milky Way (NMW) nova patrol. The code is written in C and can be easily compiled on the majority of UNIX-like systems. VaST is free software available at http://scan.sai.msu.ru/vast/

###### keywords:
methods: data analysis, techniques: photometric, stars: variables
1

## 1 Introduction

2

Variable stars are important tracers of stellar evolution (e.g. 1975IAUS...67.....S), fundamental stellar parameters (2010A&ARv..18...67T), 3D structure of our Galaxy (2015ApJ...811..113P, 2015ApJ...812L..29D, 2016A&A...591A.145G) and beyond (2005MNRAS.359L..42L, 2012ApJ...744..128S, 2015AJ....149..183H, 2017AcA....67....1J) as well as various astrophysical processes related to accretion (1996PASP..108...39O, 2017PASP..129f2001M), ejection (2016MNRAS.460.3720R) and strong magnetic fields (1989MNRAS.236P..29C). It is believed that only a few per cent of the variable stars easily accessible to ground-based photometry are currently known (2015HiA....16..687S). The reason is that contemporary CCDs are very sensitive and small and hence image only a small field of view to a high limiting magnitude.

The next generation surveys Gaia (2016A&A...595A...1G, 2016A&A...595A.133C), VVV (2010NewA...15..433M), Pan-STARRS (2016arXiv161205560C), LSST (2014ApJ...796...53R), NGTS (2017arXiv171011100W) and TESS (2015JATIS...1a4003R) employing large mosaic cameras (or multiple small cameras in case of NGTS and TESS) are expected to greatly increase the number of known variable stars. Still, these surveys have their limitations in terms of observing cadence, sky coverage, accessible magnitude range and survey lifetime. All this leaves room for variability searches with other instruments and different observing strategies. Photometric measurements needed to detect stellar variability are relatively easy to perform (compared to spectroscopy and polarimetry of objects with the same brightness), so even small-aperture telescopes are useful for finding and studying variable stars.

Large time-domain surveys employ custom-built pipelines (e.g. 2002ASPC..281..228B, 2014PASP..126..674L, 2015AJ....150..172K, 2015ASPC..491...83M) to perform photometric data reduction and variable object detection. These pipelines are fine-tuned for the particular equipment and observing strategies employed by these surveys and, while often sharing many common pieces of code, require intervention of a software engineer to adopt them to another telescope or camera. Developing a purpose-built pipeline for a small observing project is often impractical. Instead, one would like to have data reduction software applicable to a variety of telescopes and cameras.

The problem of extracting variability information from surveys, in practice, has not been completely solved. New variable stars are still being identified in the NSVS survey data (e.g. 2013PZP....13...16K, 2014PZP....14....4S) while its observations were completed in 1999–2000 (2004AJ....127.2436W). A number of recent ground-based exoplanet transit surveys, despite having sufficient photometric accuracy and sky coverage for detecting the majority of bright variable stars, have so far provided only limited information on individual objects (e.g. 2013AJ....146..112R, 2016A&A...587A..54N) or specific classes of objects (e.g. 2008AJ....135..850D, 2011A&A...528A..90N, 2012MNRAS.419..330M, 2014MNRAS.439.2078H, 2016arXiv160908449L). Better variability detection algorithms, open data-sharing policies and interfaces to published time-series that allow non-trivial searches in the whole database rather than providing access to a limited number of objects at a time are needed to fully exploit the information hidden in the data. A software to perform variability search in a set of lightcurves imported from a survey archive and visualize the search results may be useful for information extraction and debugging fully-automated search procedures.

Photographic plates used to be the primary type of light detectors in astronomy in the 20th century. Direct images of the sky recorded on glass plates contain information about the positions and brightness that celestial objects had decades ago. This information may be useful on its own or as the first-epoch for comparison with modern CCD measurements. The plates are stored in archives in observatories around the world. Many observatories are digitizing their collections in an effort to preserve the information stored on the plates and make it more accessible. At the time of writing, only the DASCH3 (2012IAUS..285...29G) and APPLAUSE4 (2014aspl.conf...53G, 2014aspl.conf..127T) archives provide source catalogs and photometry derived from the plates while others56 provide only images. Performing photometry on digitized photographic images is a non-trivial task (2005MNRAS.362..542B, 2013PASP..125..857T, 2016arXiv160700312W) that cannot be done well with conventional photometry software developed for CCD images. The conventional software relies on the assumption that an image sensor responds linearly to the number of incoming photons. This assumption is violated for photographic emulsion as well as for some types of contemporary light detectors including microchannel plate intensified CCDs (MICs) used in space-based UV-sensitive telescopes Swift/UVOT (2008MNRAS.383..627P, 2010MNRAS.406.1687B, see also 2014Ap&SS.354...89B), XMM/OM (2001A&A...365L..36M) and fast ground-based cameras (2012ASInC...7..219K). There is a need for a user-level software capable of performing photometry on images obtained with non-linear detectors.

A number of software packages for detection of variable objects have been developed recently. Some of them feature a graphical user interface (GUI) and are aimed at processing small datasets, while others have command-line interfaces and are meant as a complete data processing pipeline or as building blocks for constructing one. LEMON7 is a pipeline based on SExtractor8 (1996A&AS..117..393B) and PyRAF for automated time-series reduction and analysis (2011hsa6.conf..755T). It takes a series of FITS images as an input and constructs lightcurves of all objects. PP9 (2017A&C....18...47M) is an automated Python pipeline based on SExtractor and SCAMP (2006ASPC..351..112B). PP produces calibrated photometry from imaging data with minimal human interaction. While originally designed for asteroid work, the code is be applicable for stellar photometry. LEMON and PP are very similar to VaST in spirit, while they differ in technical implementation and user interface. C-Munipack/Muniwin10 offers a complete solution for reducing observations of variable stars obtained with a CCD or DSLR camera. It runs on Windows and Linux and provides an intuitive GUI. FotoDif11 is a Windows CCD photometry package providing capabilities similar to Muniwin. Astrokit12 (2014AstBu..69..368B, 2016MNRAS.461.3854B) corrects for atmospheric transparency variations by selecting an optimal set of comparison stars for each object in the field. IRAF’s13 (1986SPIE..627..733T) PHOT/APPHOT task is meant to be used to generate input photometric data for Astrokit. Variable star candidates are selected in Astrokit with Robust Median Statistics (2007AJ....134.2067R). FITSH14 (2012MNRAS.421.1825P) is a collection of tasks for advanced image manipulation (including stacking) and lightcurve extraction using aperture, image subtraction, analytic profile modeling and PSF-fitting photometry. VARTOOLS15 (2016A&C....17....1H) implements in C a collection of advanced lightcurve analysis methods providing a command-line interface to them. HOTPANTS16 (2015ascl.soft04004B) is designed to photometrically align one input image with another, after they have been astrometrically aligned with software like WCSremap17, SWarp (2002ASPC..281..228B) or Montage (2010arXiv1005.4454J). HOTPANTS is an implementation of the 2000A&AS..144..363A algorithm for image subtraction. The program is intended as a part of a transient detection/photometry pipeline. ISIS18 (1998ApJ...503..325A) is a complete package to process CCD images using the image subtraction method. It finds variable objects in the subtracted images and builds their light curves from a series of CCD images. DIAPL19 (2017arXiv170909572R) is able to identify variable stars via image subtraction, implemented in C. TraP20 (2015A&C....11...25S) is a Python and SQL based pipeline for detecting transient and variable sources in a stream of astronomical images. It primarily targets LOFAR radio astronomy data, but is also applicable to a range of other instruments (including optical ones).

Most of the above packages were not available at the time VaST development was started (2005ysc..conf...79S). Many of them cannot construct lightcurves without finding a plate solution with respect to an external star catalog. None of the above software addresses the issue of photometry with non-linear imaging detectors. VaST provides a combination of features not yet offered by other software, including the ability to process thousands of images with tens of thousands of stars and interactively display the results in a GUI.

VaST is designed as a user-friendly software implementing the full cycle of photometric reduction from calibrating images to producing lightcurves of all objects within a field of view and detecting variable ones. VaST is capable of handling images obtained with non-linear detectors such as photographic plates and MICs. The software may be applied to images obtained with telescopes of any size with minimal configuration. VaST can be used interactively to inspect a set of images of one field in a PGPLOT21-based GUI. As soon as optimal source extraction and lightcurve post-processing parameters have been identified in the interactive mode, VaST may proceed non-interactively and produce lightcurves for subsequent variability searches with VARTOOLS or custom-built scripts. VaST lightcurve visualization tools and built-in variability statistics routines may also be used to inspect and process lightcurves obtained with other software.

The outline of the paper is as follows. Section 2 presents the overall design of the program centered around the idea of distinguishing variable stars from non-variable ones using “variability indices”. Section 3 describes the steps performed by VaST when processing a set of images. Section 4 presents a specialized transient detection mode that does not rely on variability indices. In Section 5 we present some general remarks on the VaST development procedures. Section 6 gives an account of several notable examples of applying VaST to real data processing. We present a summary in Section 7. A describes common use cases that can be solved with VaST. B presents the list of the command-line arguments to be used with the main program of the toolkit. C describes the log files that summarize image processing results.

## 2 VaST design and the challenge of variability detection

VaST is designed to accomplish three main tasks:

1. Construct lightcurves of all objects visible at the input series of images of a given star field.

2. Compute variability indices to quantify “how variable” each lightcurve appears to be.

3. Visualize the variability indices, lightcurves and images to let the user decide which objects are actually variable.

In addition, VaST includes tools to calibrate the magnitude zero-point of the produced lightcurves, check if a given object is a cataloged variable, apply the heliocentric correction to a lightcurve, etc. The software modules implementing each of the above tasks are united by a common internal lightcurve file format. They can be run together or independently of each other. All data processing is done within the VaST working directory which contains all the necessary binaries and scripts, so the modules can locate each other without the need to set environment variables. This also allows for an easy “unpack and compile” installation procedure described in A.1.

The input to VaST may be either a set of images (for a practical example see A.2) or a set of lightcurves constructed using other software or imported from an archive (A.14). The output is a set of lightcurves and variability indices computed for each lightcurve. The indices and lightcurves can be either visualized and searched for variable objects interactively or exported for further processing with external software.

The fundamental problem in optical variability detection is that the accuracy of photometric measurements is not precisely known as the measurements may be affected by various systematic effects or corrupted. These effects include, but are not limited to:

• Residual sensitivity variations across the detector that were not taken out by flat fielding. These may be both large- (vignetting, defocused images of dust grains in optical path) and small-scale (individual dead pixels). The object’s image moves across the detector due to imperfect guiding resulting in apparent variations in brightness.

• Variation of atmospheric extinction across the field.

• Differential extinction in the atmosphere resulting in apparent change (as a function of airmass) in relative brightness of stars having different colors.

• Charge transfer inefficiency in a CCD (2015MNRAS.453..561I).

• Changing seeing conditions resulting in varying degree of overlap between images of nearby objects.

• If the instrument’s point spread function (PSF) is not point-symmetric (for example it may have diffraction spikes) the amount of blending between objects will change with changing parallactic angle.

• The PSF shape varies across the image resulting in different fraction of object’s light falling within the aperture (in the case of aperture photometry) or presenting a challenge of accurate PSF variations reconstruction (in PSF-fitting photometry).

• Resampling and stacking images may also have the unintended consequence of distorting brightness of some sources.

The solution adopted by the community is to rely on the assumption that no instrumental effect can in practice mimic a reasonably well sampled lightcurve of a variable star of a known type. While this is a reasonable assumption for periodic variables, for irregular ones it is necessary to have an idea of the practical limits of the amplitude and timescale of instrumental effects that may be found in a given photometric dataset.

In order to distinguish candidate variables from noise in the absence of reliable estimates of measurement errors one may assume that the majority of stars are not variable at the few per cent level of photometric accuracy (2008AN....329..259H, 2014aspl.conf...79S) typically achieved in ground-based survey observations. Using this assumption one may select as candidate variables the objects that appear “more variable” than the majority of objects in this dataset. Among these candidates there will be true variable objects as well as false candidates whose measurements were severely corrupted by some rare instrumental effect like an object’s image falling on a dead pixel. If the instrumental effect is not rare, e.g. if bad pixels are abundant and affect measurements of many stars, the affected stars will not stand out as “more variable” compared to the other stars in the dataset. It is ultimately up to a human expert to investigate lightcurves and images of the candidate variables and judge if the measurements of a particular object are trustworthy or have obvious problems (bad pixels, blending, etc) making them unreliable.

There is a number of ways to characterize a “degree of variability” in a lightcurve. We call the variability indices all the values that:

• Quantify the scatter of brightness measurements: , MAD, IQR, etc. (2017A&A...604A.121F, 2017MNRAS.464..274S).

• Quantify the smoothness of the lightcurve like the index (1993AJ....105.1813W) or (vonneumann1941).

• Sensitive to both smoothness and scatter (Stetson’s index), maybe also taking into account the shape of the measured brightness distribution (e.g. index 1996PASP..108..851S, 2016A&A...586A..36F).

• Characterize the strength of a periodic signal in the lightcurve (e.g. 2012AJ....143..140F, 2016arXiv160503571S).

In the absence of detailed information about measurement errors and instrumental effects one should consider the above parameters computed for a given lightcurve in the context of other lightcurves in this dataset to decide if a given variability index value corresponds to a variable object or not. The indices are not equally sensitive to all types of variability. Some of them are more susceptible to individual outliers (corrupted measurements) than the others. Scatter-based indices are generally sensitive to variability of any kind while the indices that characterize smoothness are more sensitive than scatter-based indices to objects that vary slowly compared to the typical observing cadence. That comes at the cost of these indices being insensitive to variability on timescales shorter than the observing cadence. Table 1 presents the list of variability indices computed by VaST. We refer to 2017MNRAS.464..274S for a detailed discussion and comparison of these indices.

In the following Section we present a detailed description of all the processing steps from reading input images to constructing lightcurves, computing and visualizing the variability indices. A gives practical examples of using the code.

## 3 Data processing flow

The primary input for VaST is a series of FITS22 images. The images are expected to be taken with the same telescope-camera-filter combination and cover the same area of the sky. The images may be shifted, rotated and reflected with respect to each other, but should overlap by at least 40 per cent with the sky area covered by the first image. The first image supplied to VaST serves as the astrometric and photometric reference. If the input images vary in quality, it is up to the user to select a good reference image and put it first on the command line (A.3). Below we describe the main processing steps performed to extract lightcurves from a set of images.

Information about the observing time, image dimensions and CCD gain information (that is needed to accurately compute contribution of the Poisson/photon noise to the total photometric error), is extracted from FITS header of each input image. The observing time assigned to each image is the middle of the exposure. The exposure start time is derived from one or two (if date and time are given separately) keywords from the following list: DATE-OBS, TIME-OBS, EXPSTART, UT-START, START. The exposure time in seconds is extracted from EXPOSURE or EXPTIME. If none of the two keywords are present in the header, the difference between the observation start and its middle-point is assumed to be negligible (the exposure time is set to 0). The derived time is converted to Julian date (JD).

If no keyword describing the exposure start time is found, but the JD keyword is present in the header, the keyword is assumed to correspond to the middle of exposure. This simplified convention for recording the observation time in the FITS header has been introduced within the program of digitizing photographic plates of Sternberg Astronomical Institute’s collection (2008AcA....58..279K, 2010ARep...54.1000K, 2014aspl.conf...79S). This is different from the definition of the JD keyword adopted by the widely-used CCD camera control software MaxIm DL. However, MaxIm DL will always write the DATE-OBS keyword which, if present, is used by VaST instead of JD. If VaST fails to recognize the format in which the observing time is specified in the FITS header of your images, please send an example image to the authors.

VaST supports the following two time systems: Coordinated Universal Time (UTC) and Terrestrial Time (TT). The Earth rotation period is a few milliseconds longer than 86400 SI seconds and is changing irregularly when measured at this level of accuracy. To keep UTC timescale in sync with the Earth rotation, a leap second is introduced every few years. The UTC time, being the basis of civil time, is readily available in practice through GPS receivers, NTP servers and radio broadcast, so the time of most images is recorded in UTC. The observing time from some instruments, notably Swift/UVOT, is recorded in TT. The advantage of TT is that this timescale is continuous, not interrupted by leap seconds. At each moment of time, the two timescales are related as

 TT=UTC+(TAI−UTC)+32.184sec

where is the difference between the International Atomic Time (TAI) and UTC for a given date23. As of spring 2017, the difference between TT and UTC is 69.184 sec.

The program tries to determine the time system in which the observing time is expressed in the FITS header by searching for the TIMESYS key or parsing the comment field for the keyword used to get the time. If neither UTC nor TT are explicitly mentioned in the header, the input time is assumed to be UTC. The observing time in the lightcurves created by VaST is by default expressed in terrestrial time – JD(TT). The conversion from UTC to TT may be disabled (B).

No heliocentric correction is applied to the lightcurves by default, as by design of the program, it is possible to produce lightcurves without knowing the absolute celestial coordinates of the imaged objects. If the coordinates are known, the correction may be applied after constructing a lightcurve as described in A.16. See 2010PASP..122..935E for a detailed discussion of accurate timing problems in the context of optical photometric observations.

### 3.2 Source extraction and photometry

VaST relies on SExtractor for detecting sources, measuring their positions (in pixel coordinates) and brightness. The source extraction parameters are set in the SExtractor configuration file default.sex located in the VaST directory. Depending on the command-line settings (B), more than one run of SExtractor may be needed for each image:

option I) If all images are to be measured with a circular aperture of the fixed diameter, only a single SExtractor run is performed for each image.

option II) If the circular aperture diameter is allowed to vary between images to account for seeing changes (e.g. 2017AJ....153...77C), a preliminary SExtractor run is performed to determine the typical source size. For each source the maximum spatial r.m.s. dispersion of its profile is computed (SExtractor output parameter A_IMAGE). The aperture diameter for each image is computed as , where the median is computed over all the detected sources passing selection criteria and the default value of .

option III) If the program is running in the PSF-fitting photometry mode, multiple SExtractor passes over the input image are required. First, a preliminary run is performed to determine seeing, as in the option II) above. Then SExtractor is run with conservative detection limits to extract bright sources and save their small images (SExtractor output parameter VIGNET). These small images are used by PSFEx24 (2011ASPC..442..435B) to construct a model of spatially-variable point spread function (PSF). The size of these small images as well as limits on size of objects accepted for PSF reconstruction are determined based on seeing. The PSF reconstruction step is followed by PSF-fitting with SExtractor. Objects that provide a bad fit (non-stellar, heavily blended, corrupted or overexposed objects) are discarded from the output catalog. Finally, an aperture photometry run is conducted with SExtractor (again, same as in option II). This step is performed for technical reasons: a catalog that includes all the objects, even the overexposed ones, is needed at later processing steps to perform absolute astrometric calibration discussed in Section 3.7.

The input images are expected to be well-focused. VaST may be used to process strongly-defocused images with “donut-shaped stars” given a careful selection of the processing parameters including source detection and deblending thresholds (A.8) and manually specified aperture size and star matching radius (Section 3.3, B).

The list of sources detected by SExtractor may be filtered to remove saturated, blended and extended sources as their brightness measurements are less accurate and such sources may appear as spurious candidate variables later in the analysis. Saturated sources are removed based on the source detection flag set by SExtractor. The filtering of blended and extended sources may be accomplished using SExtractor flags (if SExtractor deblending was successful) and by identifying outliers in the magnitude-size plot (Figure 1). The sources that were not properly deblended will appear larger than the other sources of similar brightness. Rejection of blended sources is done using individual images rather than using information about source size and detection flags collected from the full series of images because a generally “good” source may appear blended on some images where it is affected by a cosmic ray hit, a CCD cosmetic defect or a particularly bad seeing. It is desirable to reject only measurements of the source brightness associated with the affected images while keeping the good measurements for further analysis. The acceptable SExtractor flag values (A.8, A.15) and the magnitude-size filter may be controlled using VaST command line options (B).

### 3.3 Cross-matching source lists

VaST does not require any world coordinate system (WCS; 2002A&A...395.1061G) information to be present in the headers of the input FITS images. Instead, the code finds a linear transformation of pixel coordinates of objects detected on each image to the pixel coordinate system of the first image (taken as the astrometric reference).25 The correct transformation is found by identifying similar triangles constructed from the brightest stars detected on the current and reference images. When we created this algorithm, we were unaware that analogous star lists matching algorithms based on finding similar triangles were proposed by other authors (1986AJ.....91.1244G, 1995PASP..107.1119V, 2006PASP..118.1474P, 2007PASA...24..189T)26. A similar algorithm has also been independently proposed by P. B. Stetson27. While sharing the basic idea that angles and side length ratios of a triangle are not changed by translation, rotation, scale change and flip, the various implementations of the algorithm differ in how the lists of triangles are constructed from the input star lists, how the triangles are matched to find the initial guess of the coordinate frame transformation and how this initial transformation is further refined.

Our cross-matching algorithm goes through the following steps for the lists of sources (assumed to be mostly stars) derived from each image:

1. Sort the detected stars in magnitude.

2. Select brightest stars having acceptable SExtractor flags as the reference. The value of is discussed below.

3. Construct a set of triangles from the selected stars using the following two algorithms together:

1. For each reference star find the two nearest reference stars to form a triangle.

2. For each reference star having the index in the magnitude-sorted list, form triangles from stars having indices: (, , ), (, , ), (, , ), (, , ), (, , ), (, , ), (, , ), (, , ), (, , ) and (, , ).

In practice, a combination of these two algorithms allows one to obtain overlapping lists of triangles for virtually any pair of reference star lists if these lists overlap.

4. Similar triangles are identified in the lists by comparing ratios of the two smaller sides to the larger side of each triangle in the first list (corresponding to the reference image) to these ratios for triangles in the second list (corresponding to the current image).

5. Accept only the similar triangles that have approximately the same scale to improve stability of the algorithm.

6. For each pair of similar triangles construct a linear transformation between the pixel coordinates at the current frame and pixel coordinates at the reference frame. The transformations are applied to the reference stars.

7. The transformation that allowed VaST to match the highest number of reference stars is now applied to all the detected stars on the frame. The residuals along the two axes (dX,dY) between the predicted and measured positions of each matched star are recorded.

8. The residuals dX and dY are approximated as linear function of coordinates (X,Y) on the reference frame by least-square fitting planes into the 3D datasets (X,Y,dX) and (X,Y,dY). The derived least-square coefficients are used to correct the coordinates of all sources computed from the initial linear transformation determined from a pair of matched triangles. This correction is necessary for large images matched using a pair of small triangles (likely constructed by the algorithm (a) above). Since the positions of stars forming the triangle are measured with a limited accuracy, the initial linear transformation will be inaccurate for stars far away from the triangle.

9. Use the corrected positions to match stars to the ones detected on the reference image. A custom spatial indexing scheme is used to avoid the computationally expansive step of calculating distances from each star in the current image list to each star in the reference list (see the discussion by e.g. 2017PASP..129b4005R). The reference list used in this last step is complemented by stars detected on previously matched images even if they were not detected (or rejected because of unacceptable flag values) on the reference image. Only the stars originally detected on the reference image are used in the reference list to construct triangles.

The main input parameter of this algorithm is the number of reference stars . VaST is trying to match images probing various values of in the range 100–3000. The lower value is sufficient to match most narrow-field images while the upper value is set by the requirement to perform the match in a reasonably short time. The secondary input parameter is the matching radius – the maximum acceptable distance between the source position measured on the reference image and the one measured on the current image and transformed to the coordinates system of the reference image. If the distance is larger than the matching radius the source detected on the current image is assumed to be different from the one detected on the reference image (no match). By default, the matching radius is taken as times the aperture diameter for the current image (it will vary with aperture from image to image depending on seeing). Alternatively, the user may specify a fixed matching radius in pixels on the VaST command line (B). If for a given source detected on the current image multiple sources are found within the matching radius on the reference image, the nearest source is taken as the correct match.

If an image could not be matched because of its bad quality (e.g. many hot pixels/cosmic rays confused for real sources) or has insufficient overlap with the reference image, the unmatched image is discarded and VaST continues to the next image in the series. The matching results are logged as described in C.

The above image matching algorithm assumes a linear transformation between images. This assumption may be approximately correct even for highly-distorted wide-field images as long as the relative shifts between the distorted images are small. For a successful match, the coordinate transformation error at image edges needs to be smaller than the matching radius and typical distance between stars (to avoid confusion). The requirements for star matching are less strict than they would be for image stacking (that demands sub-pixel coordinates transformation accuracy). In practice, the matching algorithm works well for sky images obtained with lenses having a focal length of 100 mm or longer.

### 3.4 Cross-calibration of instrumental magnitudes

The aperture and PSF-fitting magnitudes are measured by SExtractor with respect to an arbitrary zero-point which differs from image to image. VaST uses the stars matched with the reference image to convert magnitude scales of all images to the instrumental magnitude scale of the reference image. While it is common practice in reducing CCD images to compensate for a constant offset between magnitude scales of the images using one or many reference stars (e.g. 2016MNRAS.462.2506B, 2017AJ....153...77C), VaST uses a large number of matched stars to reconstruct the scale offset as a function of magnitude. This allows VaST to calibrate magnitude scales of images obtained with non-linear image detectors listed in Section 1. The only requirement is that the current and reference image have a sufficient number of common stars (). The dependency of the magnitudes in the instrumental scale of the reference image, , on the instrumental magnitudes of the current image, (the calibration curve), is reconstructed using all the stars matched between the two images and approximated by one of the three functions selected by the user:

1. linear function

 mref=a1minst+a0 (1)
2. parabola

 mref=a2m2inst+a1minst+a0 (2)
3. “photocurve” function proposed by 2005MNRAS.362..542B:

 mref=a0×log10(10a1×(minst−a2)+1)+a3 (3)

or the inverse function of it

 mref=1a1×log10(10(minst−a3)a0−1)+a2 (4)

depending on which of the two functions provides a better fit to the data.

Here are the free parameters of the fit. Fitting is performed using the linear least-squares for the first two functions while the Levenberg-Marquardt algorithm is used to perform non-linear least-squares fitting of the photocurve. The data points are weighted according to the inverse square of their estimated photometric errors. An iterative clipping procedure is applied to discard variable, poorly measured or misidentified objects. An example magnitude scale calibration between two photographic images is presented on the left panel of Figure 2.

VaST can attempt to minimize the effect of the difference in extinction across the image (e.g. 2007MNRAS.375.1449I) by least-squares fitting a plane in the 3D dataset (X,Y,dm), where (X,Y) are the image coordinates and dm is the residual difference in magnitudes measured for a given object on the reference and the current image after applying the calibration curve. The best-fit plane is then subtracted from the magnitudes measured on the current image, thus correcting for the linear (in magnitude) term of the extinction, regardless of image orientation. This correction is similar to the coordinates correction performed after applying the initial transformation derived from matched triangles (Section 3.3). However, performing this correction may do more harm than good if the plane cannot be fitted with sufficient accuracy. The correction may be turned on or off by the user (B). By default, the correction is applied to images having detected sources. It is assumed that this large number of sources will be sufficient to accurately fit the plane. Note that this plane-fitting correction does not correct for the extinction difference, but rather for the difference in extinction difference between the reference and the current image. Photometric calibration described in Section 3.8 assumes one zero-point for the whole field, resulting in offsets between zero-points of lightcurves of objects visible in the upper and lower (with respect to the horizon) parts of the reference image. At this stage VaST does not take into account the color term in extinction correction (differential color extinction) as the colors of the observed sources are, in general, unknown. After constructing lightcurves you may fit for the differential color extinction together with other systematic effects affecting multiple sources in the field by applying the SysRem algorithm as described in A.11.

### 3.5 Output lightcurves, statistics and the graphical interface

The lightcurves of all the objects are saved in individual ASCII files named outNNNNN.dat where NNNNN is the source number. Each line of the lightcurve file contains:

• The middle-of-exposure JD in TT or UTC (Section 3.1).

• Magnitude in the instrumental system corresponding to the reference image.

• Magnitude error estimated by SExtractor. The estimation includes contributions from the background noise over the aperture area and photon noise. The photon noise is estimated correctly only if the GAIN parameter is set correctly from the FITS header (Section 3.1) or by the user in the default.sex file.

• Pixel coordinates of the object on the current image reported by SExtractor (parameters XWIN_IMAGE and YWIN_IMAGE).

• Aperture size in pixels used for this image.

• Path to the image file from which the above measurements of the object’s parameters were obtained.

For each object VaST computes a number of variability indices characterizing the scatter of magnitude measurements and/or smoothness of the lightcurve (2017MNRAS.464..274S). The indices are constructed so that variable stars tend to have larger values of the indices compared to the majority of non-variable stars, but the index values (and their scatter) expected for non-variable stars are strong functions of magnitude, so the simple cut in index values is usually not sufficient for efficient selection of variable stars. The index values for each object are stored in vast_lightcurve_statistics.log its format being detailed in the accompanying file vast_lightcurve_statistics_format.log. The index values may be utilized by the user as an input for automated selection of candidate variables using external software implementing complex cuts in index values or machine learning.

The simplest way of using VaST is to visualize the variability indices vs. magnitude plots using its GUI (Figure 3). By clicking on an object in these plots a user may visualize its lightcurve and clicking on a point in the lightcurve plot – display an image corresponding to this point. This way it is possible to select objects displaying high variability index values and make sure the apparent variability is not caused by brightness measurement problems resulting from blending with nearby objects or CCD cosmetic defects (the problems that readily appear on visual inspection of the object’s images). With one keystroke a user may launch the star identification script described in Section 3.7 or send its lightcurve to the online period search tool28.

The VaST GUI is based on the PGPLOT library29 which is well suited for displaying and editing data and image plots. It is exceptionally easy to use for a developer. The downside is that the resulting interface is counterintuitive to a contemporary user as it has no buttons, just the clickable plots. Whenever a user has a choice between multiple actions, instead of clicking a button to execute the desired action, a user has to press a key on a keyboard. For each GUI window, a list of possible keyboard keys is printed in a terminal window.

### 3.6 Processing time

VaST running time is mostly limited by the image processing time with SExtractor. On a 2.20 GHz quad core Intel Core i7 laptop it takes about 2 minutes to process 784 images each containing about 250 stars (the dataset described in D) in the aperture photometry mode. Processing the same images in the PSF-fitting mode takes about 50 minutes using the same hardware.

### 3.7 Astrometric calibration

It is possible to construct lightcurves in the instrumental magnitude scale and search for variability with VaST without finding the transformation between the reference image and celestial coordinates. If the field center is known to the user, detected variable stars can be identified by visually comparing the displayed image with a star atlas like Aladin30 (2000A&AS..143...33B), see also A.6. However, this approach is practical only for narrow-field image sets containing only few variable objects.

For larger fields it is more practical to find a plate solution in an automated way (see the usage example in A.7). The script will use the Astrometry.net software to plate-solve the reference image and identify the star with USNO-B1.0 (2003AJ....125..984M) for positional reference and with databases listing variable stars: GCVS31 (2009yCat....102025S), VSX32 (2006SASS...25...47W) and SIMBAD33 (2000A&AS..143....9W). The catalogs are accessed through VizieR34 using vizquery or directly through a web interface using cURL. The Astrometry.net software may be run by the script locally (if installed in the system) or on a remote server. In the latter case source extraction is done locally and only the list of detected stars (not the full image) is uploaded to the server to save bandwidth. The FITS header containing the WCS information created by Astrometry.net is merged into the original FITS image and the approximate equatorial coordinates of all sources are measured with the additional run of SExtractor.

In practice, the accuracy of the coordinates derived this way may not be sufficient for unambiguous object identification for the following reasons. While finding a blind plate solution Astrometry.net may fit for image distortions and store them in the FITS header following the SIP convention (2005ASPC..347..491S). This convention is not understood by SExtractor which is using the PV convention to represent geometric distortions (2012SPIE.8451E..1MS). As a workaround, VaST employs xy2sky routine from WCSTools (1997ASPC..125..249M, 2014ASPC..485..231M) to convert SExtractor-derived pixel coordinates to celestial coordinates rather than rely on SExtractor to do this conversion.

The following two problems are specific for large-format photographic plates digitized with a flatbed scanner. If the scanner’s image detector (scanning ruler) is smaller than the plate width, the detector has to make multiple passes along the plate and the image strips resulting from each pass have to be stitched together (Figure 4). Such a stitch results in a discontinuity in image to celestial coordinates conversion (Figure 5, right panel) that cannot be adequately represented with a low-order polynomial description of distortions. The other problem is the characteristic “hacksaw” distortions pattern (2007A&A...471.1077V) resulting from non-uniform mechanical movement of the scanning ruler (see Figure 5, left panel). While the star matching algorithm proposed by 2013MNRAS.433..935H is capable of dealing with shearing, we are not aware of an algorithm that could accommodate a shift or a discontinuity in coordinates transformation.

To minimize the negative effects of the above, VaST relies on the assumptions that image distortions are similar for objects that are close to each other and the distortions are sufficiently small to allow for correct identification for the majority of objects. After attempting to match all the detected objects with the UCAC4 catalog (2013AJ....145...44Z, accessed from VizieR) using the uncorrected coordinates, for each detected object VaST computes the mean difference between the measured and the catalog positions of matched objects within a certain radius of the current object. This difference is used as a local astrometric correction. A range of local correction radii is tested for each object and the one resulting in the smallest scatter of the measured-to-catalog distances is used to compute the final correction. The corrected positions of all the detected sources are used to match them with UCAC4 again in an attempt to find new matches. This procedure is repeated iteratively until the new iteration does not result increased number of matched stars or the maximum number of iterations is reached. The matching radius is set based on the image field of view. Figure 5 illustrates how the complex distortions introduced by a flatbed scanner can be corrected by applying the described procedure. The systematic effects are removed at the expense of slightly increased random errors in astrometry.

### 3.8 Photometric calibration

The magnitude scale can be calibrated manually using a nearby star. This can be done by interactively specifying a comparison star with a known magnitude as described in A.6.

If the reference image has a sufficiently large field of view to be blindly solved with Astrometry.net, the magnitude scale can be calibrated using APASS (2016yCat.2336....0H, 2014CoSka..43..518H) magnitudes as described in A.7. The following filters are supported: B, V, R, I, r and i. The R and I magnitudes are not present in APASS, so they are computed from r and i magnitudes following 2005AJ....130..873J:

 R=V−1.09(r−i)−0.22 (5)
 I=R−1.00(r−i)+0.21 (6)

(the above relations already takes into account that R and I magnitudes are defined in the Vega system while r and i magnitudes are always defined in the AB system, 2005ARA&A..43..293B). The relation between the catalog magnitudes and the instrumental magnitudes is approximated by one of the relations (1)–(4) selected by the user. An example relation between the catalog and measured instrumental magnitudes is presented on the right panel of Figure 2. VaST assumes the magnitude calibration curve is equally applicable to all objects across the image ignoring the effects of differential extinction (which are important for wide-field images) and possible flat-fielding imperfections.

### 3.9 Flag images

Sometimes input FITS images contain large regions not covered by data: overscan columns, gaps between chips of a mosaic CCD and an area around the originally rotated image after it was resampled to the North-up/East-left orientation (Figure 6). Sources detected on the boundary between these areas and areas covered by data are not flagged by internal SExtractor flags, as the program has no way of knowing that these are the physical edges of an image. VaST tries to identify large clusters of zero-value pixels (isolated zero-value pixels may be common if the image is background-subtracted) and produces a flag image that is masking these clusters and a few pixels surrounding them. The generated flag image is supplied to SExtractor and used to filter-out sources close to the image edges. An example flag image is presented in the right panel of Figure 6. Note that the flag image is used only to flag the spurious detections. It does not affect background level calculations performed by SExtractor.

## 4 Searching for transients with VaST

Transient sources like supernovae, novae and dwarf novae are often found with the image subtraction technique (1998ApJ...503..325A, 2016MNRAS.457..542B). Unlike a small-amplitude variable star, a new object appearing well above the detection limit results in an obvious change in an image of a star field. A list of software implementing this technique may be found in Section 1. Image subtraction has the advantage that it can naturally handle a new object appearing on top of a previously visible one, like a supernova appearing on top of a galaxy image. With the traditional source detection on sky images (rather than on difference images) to learn that something has changed the supernova has to be either successfully deblended from the host galaxy or it should be sufficiently bright to cause a detectable change in the measured brightness of the galaxysupernova compared to the measured brightness of the galaxy alone. However, the image subtraction may be difficult to implement if the PSF and its variations across the images are difficult to reconstruct. In such cases transient detection based on comparison of the lists of sources detected on first- and second-epoch images may still be preferable.

The transient detection was implemented in VaST for processing the New Milky Way (NMW35) nova patrol (2014ASPC..490..395S) images. Unlike the main lightcurve-based variability search mode that is fairly generic, VaST’s transient detection mode is applicable only to wide-field relatively shallow images (as it relies on Tycho-2 catalog for magnitude calibration; 2000A&A...355L..27H) and tied to the specific observing strategy. For each transient survey field, exactly four images are required as the input: tow first-epoch (reference) images and two second-epoch images. The two images at each epoch should be obtained with a sufficiently large shift (20 pixels or more) to suppress spurious detections due to image artifacts. Two first-epoch images are needed to reduce the probability of an object visible on the reference image not being detected by SExtractor due to blending or an image artifact. If this object is detected on the second-epoch images - it would be incorrectly identified as new.

The candidate transients are selected as objects that were not detected at any of the reference images, or where at least 1 mag. fainter compared to the second-epoch images. The second criterion is needed to identify flaring objects and new objects that are blended with previously-visible ones.

VaST generates an HTML report containing a list of candidate transients and opens it in a web browser. For each candidate transient the HTML report displays the following information (Figure 7):

• Cutouts from the first and second epoch images centered on the transient candidate.

• Photometry and astrometry of the candidate.

• Results of VSX search for known variable stars around the transient’s position. A local copy of the catalog is used.

• Results of astcheck36 search for known asteroids around the transient’s position; astcheck relies on a local copy of asteroid orbit data.

• Links to search the transient’s position in SIMBAD and VizieR databases as well as NSVS, ASAS (1997AcA....47..467P, 2002AcA....52..397P) and CSS (2009ApJ...696..870D) photometry archives. A link to the WISE (2010AJ....140.1868W) image atlas is also provided. It is especially useful for distinguishing unknown red variables (bright in the infrared light) from nova/cataclysmic variable candidates. The object’s position may also be checked in MPChecker37 (that has the latest information on asteroids and comets) and the NMW image archive.

A.15 provides an example of running VaST in the transient detection mode.

## 5 Remarks on development process

Some of the best practices for scientific computing were reviewed by 2012arXiv1210.0530W. Here we highlight a few procedures that were found especially useful for VaST development.

The core functionality of VaST is implemented in C. Valgrind38 (Net:valgrind2007) tools are used for profiling (Net:workload-characterization2006) and detecting memory errors and leaks (Sew:memcheck2005). Parallel processing is implemented using OpenMP.

Defensive programming style is adopted whenever possible. VaST continues execution after failing to process an individual image. With this we are trying to avoid the situation when hours of computation are lost because of a bad image mixed into a generally good input dataset (e.g. 2001ASPC..238..306R). An attempt is made to print a meaningful error message in cases when the execution of the program cannot continue: most such situations are caused by incorrect input on the command-line or from image/lightcurve files and can be corrected by the user.

Automated testing was not implemented from the start of the project, but it quickly appeared that adding new functionality to the code broke some of the rarely-used functionality added earlier. The solution was found in system testing implemented in a form of a BASH script. The script runs VaST in a non-interactive mode on various sets of test data and checks if the output is consistent with the expectations. After VaST processed a set of test images, the script checks if all middle-of-exposure JDs were computed correctly, if all the images were successfully matched to the reference image, if the reference image was plate-solved and if the object having the highest lightcurve scatter can be identified with a known variable star or if a known flaring or moving object is among the list of detected transients. While the tests check high-level functionality of the software, once a problem is discovered it is often easy to pin-point a recently modified piece of code that caused it. Bug reports from VaST users provide a steady source of non-trivial test cases.

VaST is developed and tested under Gentoo Linux that, in the authors’ view, provides a developer-friendly environment. A set of portability tests is performed prior to release. The tests ensure that VaST compiles and runs well on the latest Ubuntu and Scientific Linux, as well as the old Scientific Linux 5.6 recommended39 for building portable applications by the BOINC project (2012AREPS..40...69K). The testing is also performed on the latest stable release of FreeBSD. All these operating systems are run as virtual machines through VirtualBox. A number of bizarre differences in behavior between versions of gcc, make, BASH, awk and sort commands supplied with different Linux distributions (not to mention differences between their version supplied with Linux and FreeBSD) were encountered, confirming the need for the portability testing40. We emphasize that the operating system versions mentioned above are not the ones strictly required for running VaST, rather they should be representative examples of the current UNIX-like systems diversity. The goal of our portability testing is to have a reasonable expectation that VaST will compile and run on any contemporary Linux or FreeBSD system.

To make VaST installation as easy as running the command make, the package includes copies of some non-standard libraries it relies on that are automatically built from source code before compiling VaST source files. VaST also comes with its own copy of SExtractor however it is configured with --disable-model-fitting to avoid dependency on the ATLAS library and therefore cannot perform PSF-fitting. To enable PSF-fitting photometry one has to install ATLAS, PSFEx and SExtractor system-wide. VaST will use the system installation of SExtractor if it finds one.

The main obstacle in VaST adaptation by the users appears to be the complexity of its command-line interface combined with the lack of clear documentation. While software with overly complex user interfaces and non-trivial installation procedures (think AIPS, ESO-MIDAS, IRAF) are often tolerated in astronomy for historical reasons, many variable star observers expect software in this field to have an intuitively-understandable GUI. The problem is not confined to the interface of the program, but also includes the operating system interface. Familiarity of potential users with POSIX-like command-line interface is increasing thanks to the rise in popularity of Mac OS. VaST documentation should be improved, in particular video tutorials seem to be a good way to introduce the software to potential users. We are also considering a radical re-design of the user interface to make it fully web-based.

## 6 VaST applications

The development of VaST was mostly driven by the author’s data processing needs. These evolved from a piggyback variability search in targeted CCD observations of known variable objects (2005IBVS.5654....1A, 2011PZ.....31....1S) to variability search using digitized photographic plates (2008AcA....58..279K, 2014ARep...58..319S), Swift/UVOT data analysis (2009PZP.....9....9S, 2012MNRAS.425.1357G), visualization of CoRoT lightcurves (2010CoAst.161...55S), photometry of individual active galactic nuclei (2011A&A...532A.150S, 2014A&A...565A..26S) and wide-field search for bright optical transients (2014ASPC..490..395S) that resulted in the discovery of Nova Sagittarii 2012 #1 (=V5589 Sgr; 2012CBET.3089....1K, 2012ATel.4061....1S). VaST was applied for variability search in CCD data by others including 2013A&A...560A..22M, 2014PZP....14...12L, 2015PZP....15....3K. 2017arXiv171007290P used VaST to compute multiple variability indexes needed to test a machine learning-based approach to variable star detection. From the list of VaST-related publications maintained at the code’s homepage41 it is estimated that VaST contributed to the discovery of at least 1800 variable stars.

## 7 Summary

VaST takes a series of sky images as an input and produces lightcurves for all imaged objects. A set of variability indices is computed that characterize scatter and smoothness of the lightcurves and allow the user to distinguish variable objects from non-variable ones. The user interface aids in visual inspection of candidate variables by visualizing variability index–magnitude plots, lightcurves and images associated with each lightcurve point. Thanks to parallel processing and smart memory management, the code is able to process thousands of images while running on modest hardware. VaST is free software, distributed under the terms of the GNU General Public License (GPL)42. We hope that the description of the code provided here will be useful both to VaST users and those who aim to develop the next generation variability search software.

## Acknowledgments

We thank the anonymous referees, Dr. Alceste Bonanos, George Kakaletris, Maria Mogilen, Dean Roberts, Dr. Nikolay Samus, Olga Sokolovskaya, Dr. Alexandra Zubareva and Dmitry Litvinov for critically reading the manuscript. Thanks to Mark Vinogradov for the suggestion on improving the text. We thank Dmitry Nasonov who designed the VaST homepage, Sergei Nazarov (Moscow) who coined the name for the code and Sergei Nazarov (CrAO) who created great instructions43 on variability search (in Russian), Stanislav Korotkiy for starting the NMW nova patrol project, Dr. Alexei Alakoz, Dr. Panagiotis Gavras and Dr. Jean-Baptiste Marquette for testing the code on Mac OS. KS thanks Dr. Sergei Antipin and Dr. Vladimir Amirkhanyan for illuminating discussions of photometric data analysis, Daria Kolesnikova and Andrey Samokhvalov for many suggestions that helped to improve the output and interface of the program, Dr. Richard White for the illuminating discussion of flag images and weight maps handling by SExtractor. This work is partly based on observations made with the 2.3 m Aristarchos telescope, Helmos Observatory, Greece, which is operated by the Institute for Astronomy, Astrophysics, Space Applications and Remote Sensing of the National Observatory of Athens, Greece. This research has made use of the SIMBAD database, operated at CDS, Strasbourg, France. This research has made use of the VizieR catalog access tool, CDS, Strasbourg, France. The original description of the VizieR service is presented by 2000A&AS..143...23O. This research has made use of the International Variable Star Index (VSX) database, operated at AAVSO, Cambridge, Massachusetts, USA. This research has made use of NASA’s Astrophysics Data System.

## Appendix A Use cases

This section provides installation instructions and practical examples of how common variability-search problems can be solved with VaST.

### a.1 Compiling VaST

To run VaST you will need a computer running Linux, FreeBSD or Mac OS X operating system. If you have a different system – run one of the supported systems in a virtual machine. Make sure gcc compiler with C++ and Fortran support as well as header files needed to compile X.Org GUI applications are installed.

In a terminal window, download and unpack the archive containing VaST source code, change to the unpacked directory and compile the code:

wget http://scan.sai.msu.ru/vast/vast-1.0rc78.tar.bz2
tar -xvf vast-1.0rc78.tar.bz2
cd vast-1.0rc78
make

The script may complain about missing external programs or header files. Install any missing components in your system and run make again. At this point you should have a working version of VaST ready to perform aperture photometry, as descried in the following examples. All processing is done from within the VaST directory (vast-1.0rc78 in the above example) – no system-wide installation is needed.

### a.2 Variability search in a series of CCD images

Suppose we have a series of dark-subtracted and flat-field-corrected images of a particular star field in the directory ../sample_data To construct lightcurves and perform variability search in these images, form the VaST directory run

./vast ../sample_data/*

Here the input images are specified as command-line arguments and the * sign indicates all files in the directory. The files that are not FITS images will be automatically ignored. After performing the processing steps described in Sections 3.13.4, the program will open an interactive window displaying a variability index–magnitude plot and allowing to inspect individual lightcurves and images as described in Section 3.5.

### a.3 Setting a reference image of your choice

VaST is using the first image specified on the command-line as the reference image. This may be a bad choice if the first image in a series is of poor quality. To specify a different image, just put it first on the command-line. In the example above, one may set f_72-058r.fit as the reference image

./vast ../sample_data/f_72-058r.fit ../sample_data/*

Note that in this example f_72-058r.fit appears on the list of input images twice: the first time it is specified explicitly and the second time – when it satisfies the condition specified with the wildcard character *. VaST will recognize this is again the reference image and will not try to measure it twice.

### a.4 Restarting work after a break

The main interactive window may be closed by right-clicking or pressing ’X’ on the keyboard twice. It may be re-opened with

./find_candidates -a

If one runs ./find_candidates without a command-line argument, it will re-compute the variability indices instead of re-displaying the old computations. This is useful if the lightcurves were altered, e.g. after calibrating the magnitude scale (A.6, A.7) or applying SysRem algorithm (A.11).

All the lightcurves and log files produced after measuring a set of images may be saved to a directory MY_FIELD_NAME

util/save.sh MY_FIELD_NAME

and loaded back to the VaST working directory

### a.5 View a lightcurve of an individual star

The user may view a lightcurve of an object by selecting it on the reference image:

./select_star_on_reference_image

or if the object’s number (12345) is known from the previous VaST run, the lightcurve can be plotted with

./lc out12345.dat

You may zoom in to a section of the lightcurve by pressing 'Z' on the keyboard (press 'Z' twice to zoom out). You may send the entire lightcurve to the online period search tool by pressing 'L'. If the lightcurve is generated by VaST and not imported from external software, you may click on each lightcurve point to view the image corresponding to this point. You may try to identify the object with a known variable by pressing 'U' (see Section 3.7). As with the other VaST GUI applications, look at the terminal to see the list of possible keyboard commands.

### a.6 Manual single-star magnitude calibration

After generating lightcurves from a set of images (A.2, A.10 or A.12) run

util/magnitude_calibration.sh

The script will display an image marking the stars that pass all the quality cuts. Identify a reference star of your choice by clicking on it and enter its magnitude in the terminal. The APASS catalog visualized through Aladin is a good place to find reference stars (Section 3.8). An example of such single-star zero-point calibration is discussed in D.

### a.7 Automated magnitude scale calibration

If the field of view is large enough to be automatically plate-solved, the magnitude calibration can be performed by automatically matching the detected stars to the APASS catalog:

util/magnitude_calibration.sh V

where the command-line argument specifies the observing band (see Section 3.8). An interactive plot displaying the APASS magnitude as a function of the instrumental magnitude (Figure 2) will be displayed. A fitting function may be chosen among the ones described in Section 3.4 by pressing ’P’. Weighting may be turned on or of by pressing ’W’. Outlier points may be interactively removed by pressing ’C’ and drawing a rectangle with a mouse around the outliers. After a satisfactory fit is found, right-click to apply the calibration.

### a.8 Fine-tuning source extraction parameters

To check how well star detection is performed on an image:

./sextract_single_image ../sample_data/f_72-001r.fit

where ../sample_data/f_72-001r.fit is the path to the image file. This will display the image marking all the detected objects with green circles. Normally, one would like to have all objects clearly visible on the image to be detected while a minimal number of obvious artifacts like hot pixels or noise peaks to be mistaken for real astronomical sources. The default source extraction parameters work well for most CCD images while the images acquired with DSLR cameras (typically equipped with CMOS detectors) and digitized photographic images typically require fine-tuning of the extraction parameters.

The extraction parameters are set in the default.sex file. The most relevant are DETECT_MINAREA and DETECT_THRESH. A detailed description of the parameters may be found in SExtractor documentation44. The VaST directory includes a few example files named default.sex*.

A click on a detected source will print its derived properties (including pixel position and instrumental magnitude) in the terminal. Inspection of object’s properties is useful to find out why a particular known object of interest did not pass the selection criteria and its lightcurve was not generated. It is useful to check SExtractor flags typically assigned to the detected objects. By default, VaST only accepts sources that have flag values 0 or 1. If the star field is very crowded or the instrument’s PSF has a funny shape, the majority of objects may be marked with flags 2 or 3. In that case you may either try to find more optimal extraction parameters by changing the detection threshold as described above as well as deblending parameters DEBLEND_NTHRESH and DEBLEND_MINCONT or run VaST with -x3 command-line argument in order not to filter out blended stars.

### a.9 Selecting best aperture size for each source

VaST may use SExtractor to measure brightness of each source in multiple circular apertures. For each source all apertures have the same center and their sizes are 10 per cent smaller, equal, 10. 20 and 30 per cent larger than the size of the reference aperture selected automatically for each image based on seeing (as described in Sec. 3.2) or set to a fixed size by the user for the whole series of images (B). After processing all the images, VaST may select for each source the aperture that resulted in the smallest lightcurve scatter (quantified by MAD). The following command will activate the best aperture selection:

./vast --selectbestaperture ../sample_data/*

In practice, selecting aperture size individually for each object was found to result only in a minor improvement of photometric accuracy compared to the use of a properly-selected single-size aperture for all sources on a frame. This was previously reported by 2001phot.work...85D, see also 1999ASPC..172..317M.

### a.10 PSF-fitting photometry with PSFEx

In order to enable PSF-fitting you will need to install SExtractor (not disabling PSF-fitting support, see Section 5) and PSFEx (along with the libraries they depend on) system-wide. Then you may run

./vast -P ../sample_data/*

where '-P' tells VaST to use PSF-fitting.

While the simple aperture photometry works well out-of-the box for most CCD images, PSF-fitting photometry will require fine-tuning of PSF extraction parameters for each new telescope+camera combination. The PSF extraction parameters are set in default.psfex and described in the PSFEx documentation45. The two most relevant ones are PSFVAR_DEGREES and PSFVAR_NSNAP. A user should experiment with different values of these parameters and select the ones that minimize the lightcurve scatter for the bright stars in the field (that may be visualized with ./find_candidates, see A.4) for final processing. This may be a time-consuming process as each PSF-fitting photometry run needed to construct lightcurves and estimate their scatter is taken considerably longer than an aperture photometry run on the same images. Fortunately, it is sufficient to select the best PSF extraction parameters once for a given instrument.

The source catalogs generated from the input images are cleaned from detections that resulted in bad PSF-fit quality. This reduces the number of false detections due to cosmic ray hits and hot pixels as well as objects that could not be properly deblended and hence have their photometry corrupted.

For faint stars PSF-fitting photometry results in considerably smaller lightcurve scatter compared to the fixed-aperture photometry. However, the accuracy of PSF-fitting photometry of bright stars is actually lower than that of aperture photometry. The reason is that for the bright stars the dominating source of errors are the residual uncertainties in reconstructing spatial and temporal variations of the PSF rather than background noise (as is the case of faint stars). The quality of PSF-fitting lightcurves can often be considerably improved by applying a few iterations of the SysRem procedure discussed in A.11.

### a.11 Improving photometric accuracy with SysRem

The SysRem algorithm proposed by 2005MNRAS.356.1466T attempts to remove linear effects that, to a various degree, affect many lightcurves in a set. The original paper explains the algorithm using differential extinction as an example, but actually the algorithm is applicable to systematic effects of any physical origin, as long as many stars are affected by it.

After constructing lightcurves in the usual way (A.2, A.10, A.14) run

util/sysrem2

then use

./find_candidates

to re-compute the variability indices and inspect the results. Repeat the procedure until there is not further improvement in lightcurve scatter. Each util/sysrem2 removes no more than one systematic effect (while a real physical effect may be modeled as multiple linear effects removed by multiple SysRem iterations). Typically 3–6 SysRem iterations are sufficient to considerably improve quality of CCD lightcurves. One should avoid unnecessary SysRem iterations, as after all the detectable systematic effects are cleaned from the dataset, individual variable objects may start to dominate the SysRem solution and their real variability may be erroneously removed (2013MNRAS.435.3639R, e.g.).

### a.12 Variability search with photographic plates

When dealing with digitized photographic images, they typically first have to be converted from TIFF (the format commonly produced by scanner software) to FITS. The conversion can be performed with the tiff2fits tool46:

./tiff2fits -i input.tiff output.fits

where the -i argument indicates that a positive (white stars on black sky) should be produced. Information about the observing time should be added to the FITS header:

After producing a series of images they may be processed with VaST (note that a default.sex with customized detection parameters is needed)

cp default.sex.beta_Cas_photoplates default.sex
./vast -o -j ../photographic_fits_images/*

Here default.sex.beta_Cas_photoplates is the example SExtractor parameters file for photographic plates, -o enables the photocurve magnitude calibration function described in Section 3.4, -j enables correction for the linear magnitude trend across the image (Section 3.4).

### a.13 Identification of a variable object

If the image field of view is sufficiently large to be automatically plate-solved with Astrometry.net you may run the automatic star identification by pressing 'U' key in the lightcurve inspection window or typing in a free terminal

util/identify.sh out12345.dat

where out12345.dat is the file containing VaST-format lightcurve of the object you are interested in. This will run a series of scripts that will plate-solve the first image at which the object is detected, determine its equatorial coordinates and attempt to match it external catalogs as described in Section 3.7.

The ability to plate-solve narrow-field images is limited by the index files available to Astrometry.net code and processing time. At the time of writing, the plate-solve servers communicating with VaST are able to solve only images with the field of view larger than about . If a narrow field images need to be solved, it is recommended to install Astrometry.net code locally on the computer running VaST and supply the code with only with index files corresponding to the field of view of the images. VaST will automatically detect a local Astrometry.net installation if its binaries are found in PATH.

### a.14 Importing lightcurves from other software

It is possible to load lightcurves produced by other software into VaST. The lightcurves should be in three-column (”JD mag err”) ASCII files. If such lightcurve files are placed in the directory ../lcfiles run

util/convert/three_column_ascii2vast.sh ../lcfiles/*
./find_candidates

### a.15 Transient detection

An overview of transient search with VaST is presented in Section 4. You’ll need libpng header files installed in your system for this mode to work. If they were not present the time you installed VaST, you will need to re-compile it by running

make

The following parameters are recommended:

./vast -x7 -uf \
../transient_detection_test_Ceres/reference_images/* \
../transient_detection_test_Ceres/second_epoch_images/*
util/transients/search_for_transients_single_field.sh

here -x7 tells VaST to accept all detections with SExtractor flags 7 or lower (a transient may well be blended with background stars or saturated), -u (or --UTC) indicates that the UTC to TT time system conversion should not be performed (Section 3.1), -f tells the program not to start ./find_candidates. Instead of staring the interactive display, VaST will start a web browser displaying an HTML page presenting search results (Figure 7). If the Astrometry.net code is installed locally (Section 3.7), it is possible to run the transient search and perform a basic search for known variables (VSX) and asteroids (astcheck) without having internet connection, but for a full investigation of transient candidates it is highly recommended to use also the online services. To keep the number of false candidates low, you will likely need to experiment with source extraction parameters as described in A.8.

### a.16 Heliocentric correction

As the Earth orbits around the Solar system barycenter, it gets closer or further from distant celestial objects that are not at the ecliptic poles. The time light from a distant object needs to travel this extra distance may be as high as 499 seconds for an object at the ecliptic plane observed from the closest and furthest points of the Earth orbit. This extra time should be taken into account for accurate timing analysis.

VaST has a tool (based on NOVAS47 library; 1989AJ.....97.1197K) that applies heliocentric (center of the Sun) correction to a lightcurve given the equatorial J2000 coordinates of the observed object:

# If the input lightcurve is in TT
util/hjd_input_in_TT out123.dat 12:34:56.7 +12:34:56
# If the input lightcurve is in UTC
util/hjd_input_in_UTC out123.dat 12:34:56.7 +12:34:56
# The output JDs are always expressed in TT

If timing accuracy of better than 8 sec is needed, one should consider using an external software (e.g. VARTOOLS compiled with SPICE48 support; 1996P&SS...44...65A) to compute barycentric correction instead of heliocentric. The reason why only the simple heliocentric correction is implemented in VaST instead of barycentric correction is that the heliocentric correction can be computed using a few inline constants in the code, while the computation of barycentric correction requires a complex Solar system model.

### a.17 Re-formatting a lightcurve for publication

VaST out*.dat lightcurve files include columns with information about object pixel coordinates, measurement aperture and local path to the image files that are not needed for a lightcurve attached to a publication of VSX database submission. VaST includes a tool that removes the unnecessary columns and sorts the input lightcurve in JD:

util/cute_lc out00268.dat > lc_00268.txt

### a.18 Split multi-extension Fits image

VaST cannot properly handle multi-extension images – FITS files containing multiple images obtained at different epochs of with different CCD chips. Multi-extension images are commonly found in the HST and Swift/UVOT archives. These images should be split into multiple FITS files each containing only one image before they can be processed with VaST. A multi-extension file can be split using the tool

util/split_multiextension_fits multiextension_image.fits

## Appendix B Command line options

./vast is the main program that constructs lightcurves from a set of input images. It accepts a number of command-line options listed below.

-h or --help       print help message
-9 or --ds9        use DS9 instead of pgfv to view FITS images
-f or --nofind     do not run ./find_candidates after constructing lightcurves
-p or --poly       use linear instead of polynomial magnitude calibration (useful for good quality CCD images)
-o or --photocurve use formulas (1) and (3) from Bacher et al. (2005, MNRAS, 362, 542) for magnitude calibration. Useful for photographic data
-P or --PSF        PSF photometry mode with SExtractor and PSFEx
-r or --norotation assume the input images are not rotated by more than 3 deg. w.r.t. the first (reference) image
-e or --failsafe   FAILSAFE mode. Only stars detected on the reference frame will be processed
-u or --UTC        always assume UTC time system, do not perform conversion to TT
-k or --nojdkeyword  ignore "JD" keyword in FITS image header. Time of observation will be taken from the usual keywords instead
-a5.0 or --aperture5.0  use fixed aperture (e.g. 5 pixels) in diameter
-b200 or --matchstarnumber200  use 200 (e.g. 200) reference stars for image matching
-y3 or --sysrem3  conduct a few (e.g. 3) iterations of SysRem
-x2 or --maxsextractorflag 2  accept stars with flag <=2 (2 means 'accept blended stars')
-j or --position_dependent_correction    use position-dependent magnitude correction (recommended for wide-field images)
-J or --no_position_dependent_correction   DO NOT use position-dependent magnitude correction (recommended for narrow-field images with not too many stars on them)
-g or --guess_saturation_limit try to guess image saturation limit based on the brightest pixels found in the image
-G or --no_guess_saturation_limit DO NOT try to guess image saturation limit based on the brightest pixels found in the image
-1 or --magsizefilter filter-out sources that appear too large or to small for their magnitude (compared to other sources on this image)
-2 or --nomagsizefilter filter-out sources that appear too large or to small for their magnitude (compared to other sources on this image)
-3 or --selectbestaperture for each object select measurement aperture that minimized the lightcurve scatter
-4 or --noerrorsrescale disable photometric error rescaling
-5 10.0 or --starmatchraius 10.0 use a fixed-radius (in pixels) comparison circle for star matching

## Appendix C Log files

After processing an image series, apart from the lightcurve files VaST will create a number of log files:

vast_summary.log file summarizes the processing results. It indicates how many images were successfully processed, which image was used as the reference (A.3) what time system is used for JDs in lightcurve files (Section 3.1).

vast_image_details.log contains information about processing of individual images including the start time and middle of exposure JD derived from the FITS header, aperture size used for this image, number of detected sources and how many of them are matched and if the overall image matching and magnitude calibration were successful, image rotation angle with respect to the reference image.

vast_command_line.log stores all the command-line arguments specified for the latest VaST run.

vast_lightcurve_statistics.log is the table with raw variability index values computed for all lightcurves that have a sufficient number of points (Section 3.5).

vast_lightcurve_statistics_normalized.log is the table with variability index values normalized by their scatter estimated for each object’s magnitude.

vast_lightcurve_statistics_format.log describes the format of the variability index tables.

## Appendix D Comparison with AstroImageJ and Muniwin

In order to check the quality of photometry produced by VaST in aperture and PSF-fitting modes we compare it with two other aperture photometry packages: AstroImageJ (2017AJ....153...77C) and Muniwin (Section 1). These two packages were selected for comparison as they are free and provide a friendly GUI for lightcurve construction. As the test dataset49 we used a series of -band images of a candidate cataclysmic variable Gaia16bnz obtained with the 2.3 m Aristarchos telescope50 (2010ASPC..424..422G, 2016A&A...585A..19B) using a VersArray e2v back-illuminated CCD, cooled by liquid nitrogen. The images cover the sky area of arcminutes. The images were bias-subtracted and flat-fielded in VaST which was also used to wright the observing time of each image in the commonly accepted format using the DATE-OBS and EXPTIME keywords in the FITS hearer (Section 3.1).

As the target is one of the few brightest stars on the frame (which may cause problems for VaST when running with the default parameters), the following VaST command line options (B) were used to run the test in the aperture photometry mode:

./vast -a10 -up --noerrorsrescale --magsizefilter \
This requires {\scshape VaST} to use a single aperture 10\,pixels in
diameter for all images, do not perform UTC to TT time conversion
(Section\ref{sec:fitsheader}), use a linear function (\ref{eq:linear})
for frame-to-frame magnitude calibration (Section\ref{sec:calibinstmag}),
enable the magnitude-size filter (Section\ref{sec:sextraction}) and disable
the bad image filter (as no similar filtering is offered by the other tools).
For the PSF-fitting photometry we used the following command line:
\begin{lstlisting}[language=vastmarkup]
./vast -P -a10 -up --noerrorsrescale --magsizefilter \
For {\scshape AstroImageJ} and {\scshape Muniwin} we
set the measurement aperture diameter to 10\,pixels and the sky annulus inner
and outer diameters to 15 and 35 pixels. We used a single
comparison star URAT1\,697-107802 \citep{2015AJ....150..101Z} assuming
$R = 13.648$ -- computed from APASS colors using
(\ref{eq:apassrbandconversion}). The same comparison star was used to set
the zero-point of {\scshape VaST} photometry (\ref{sec:examplemanualmagcalib}). The lightcurves
obtained with the different methods agree within 0.005\,mag ($\sigma$) and
0.003\,mag (MAD). A section of the resulting lightcurves is presented in
Figure\ref{fig:softwaretest}.
The errorbars reported by {\scshape AstroImageJ} and {\scshape Muniwin}
are a factor of three larger than the ones reported by {\scshape VaST}
because they take into account different sources of errors (resulting from
the difference in magnitude calibration technique). The {\scshape VaST} errorbars are
derived from the combination of the background and photon noise
corresponding to the target (and scaled with the magnitude calibration
function described in Section\ref{sec:calibinstmag}). They neglect the
uncertainty in magnitude zero-point determination as it is derived from all
stars matched between the current and reference frames. The errorbars
reported by {\scshape AstroImageJ} and {\scshape Muniwin} include
the uncertainty in magnitude zero-point determination which in this case
include the photon and background noise from a single comparison star that
is fainter than the target. Normally, the {\scshape VaST} errorbars are
rescaled following the procedure described by
\citep{2009MNRAS.397.1228W,2017MNRAS.468.2189Z}. However, this rescaling procedure
results in overestimating the errors for the brightest stars
(if there are few bright stars on the frame) and was disabled for this test.
\begin{figure}
\centering
\includegraphics[width=0.48\textwidth,clip=true,trim=0cm 0cm 0cm 0cm]{softwaretest.eps}
\caption{Lightcurve of a candidate cataclysmic variable measured with {\scshape VaST}
in PSF-fitting and aperture photometry mode, as well as {\scshape AstroImageJ} and
{\scshape Muniwin} both performing aperture photometry. }
\label{fig:softwaretest}
\end{figure}
The candidate cataclysmic variable may be identified as the object
having a higher lightcurve scatter compared to other objects of similar
brightness. Figure\ref{fig:softwaretestmagdev} presents the lightcurve
scatter versus magnitude plots computed with {\scshape VaST} and
{\scshape Muniwin}. {\scshape AstroImageJ} has no built-in capability to visualize
magnitude-scatter plots so it is not considered here. {\scshape VaST} and {\scshape Muniwin}
have a different way to quantify lightcurve scatter. In {\scshape VaST} the
default measure of scatter is the unweighted standard deviation computed
over a lightcurve from which 5\,percent of brightest and faintest points
were removed, but not more than 5 points from each side (see appendix in \citealt{2017arXiv171007290P}).
In addition to this clipped $\sigma$ {\scshape VaST} has other ways to characterize scatter
and shape of a lightcurve (Table\ref{tab:varindex}). {\scshape Muniwin}
uses a custom robust measure of lightcurve scatter as the variability detection statistic.
The few objects with $R\gtrsim16$ showing elevated lightcurve scatter in the {\scshape Muniwin}
plot were automatically identified as blended (Section\ref{sec:sextraction}) and excluded from the
{\scshape VaST} analysis.
Figure\ref{fig:softwaretestmagdev} also illustrates the difference
between the aperture and PSF-fitting photometry with {\scshape VaST}.
While for the brighter point-like sources both techniques produce
a comparable measurement accuracy, for fainter sources PSF-fitting results
in much smaller lightcurve scatter than aperture photometry. The effect is
exaggerated here as {\scshape VaST} was forced to use a large aperture
in order to maximize photometric accuracy for the bright target at
the cost of the elevated background noise mostly affecting the fainter sources.
\begin{figure}
\centering
\includegraphics[width=0.48\textwidth,clip=true,trim=0cm 0cm 0cm 0cm]{softwaretest_magdev.eps}
\caption{The magnitude-scatter plot produced with {\scshape VaST}
in PSF-fitting and aperture photometry mode and {\scshape Muniwin}.
For {\scshape VaST} the Y-axis is the standard deviation computed over
clipped lightcurves, while for {\scshape Muniwin} the Y-axis
represents its custom robust measure of lightcurve scatter. The candidate cataclysmic variable
is marked with the circle. It can be identified as the object with elevated
lightcurve scatter compared to other objects of similar brightness.}
\label{fig:softwaretestmagdev}
\end{figure}
%% \section{}
%% \label{}
%% References
%%
%% Following citation commands can be used in the body text:
%%
%%  \citet{key}  ==>>  Jones et al. (1990)
%%  \citep{key}  ==>>  (Jones et al., 1990)
%%
%% Multiple citations as normal:
%% \citep{key1,key2}         ==>> (Jones et al., 1990; Smith, 1989)
%%                            or  (Jones et al., 1990, 1991)
%%                            or  (Jones et al., 1990a,b)
%% \cite{key} is the equivalent of \citet{key} in author-year mode
%%
%% Full author lists may be forced with \citet* or \citep*, e.g.
%%   \citep*{key}            ==>> (Jones, Baker, and Williams, 1990)
%%
%% Optional notes as:
%%   \citep[chap. 2]{key}    ==>> (Jones et al., 1990, chap. 2)
%%   \citep[e.g.,][]{key}    ==>> (e.g., Jones et al., 1990)
%%   \citep[see][pg. 34]{key}==>> (see Jones et al., 1990, pg. 34)
%%  (Note: in standard LaTeX, only one note is allowed, after the ref.
%%   Here, one note is like the standard, two make pre- and post-notes.)
%%
%%   \citealt{key}          ==>> Jones et al. 1990
%%   \citealt*{key}         ==>> Jones, Baker, and Williams 1990
%%   \citealp{key}          ==>> Jones et al., 1990
%%   \citealp*{key}         ==>> Jones, Baker, and Williams, 1990
%%
%%   \citeauthor{key}       ==>> Jones et al.
%%   \citeauthor*{key}      ==>> Jones, Baker, and Williams
%%   \citeyear{key}         ==>> 1990
%%   \citeyearpar{key}      ==>> (1990)
%%   \citetext{priv. comm.} ==>> (priv. comm.)
%%   \citenum{key}          ==>> 11 [non-superscripted]
%% Note: full author lists depends on whether the bib style supports them;
%%       if not, the abbreviated list is printed even when full requested.
%%
%% For names like della Robbia at the start of a sentence, use
%%   \Citet{dRob98}         ==>> Della Robbia (1998)
%%   \Citep{dRob98}         ==>> (Della Robbia, 1998)
%%   \Citeauthor{dRob98}    ==>> Della Robbia
%% References with bibTeX database:
\bibliographystyle{model2-names}
\bibliography{vast}
%% Authors are advised to submit their bibtex database files. They are
%% requested to list a bibtex style file in the manuscript if they do
%% not want to use model2-names.bst.
%% References without bibTeX database:
% \begin{thebibliography}{00}
%% \bibitem must have one of the following forms:
%%   \bibitem[Jones et al.(1990)]{key}...
%%   \bibitem[Jones et al.(1990)Jones, Baker, and Williams]{key}...
%%   \bibitem[Jones et al., 1990]{key}...
%%   \bibitem[\protect\citeauthoryear{Jones, Baker, and Williams}{Jones
%%       et al.}{1990}]{key}...
%%   \bibitem[\protect\citeauthoryear{Jones et al.}{1990}]{key}...
%%   \bibitem[\protect\astroncite{Jones et al.}{1990}]{key}...
%%   \bibitem[\protect\citename{Jones et al., }1990]{key}...
%%   \harvarditem[Jones et al.]{Jones, Baker, and Williams}{1990}{key}...
%%
% \bibitem[ ()]{}
% \end{thebibliography}
\end{document}
%%
%% End of file `elsarticle-template-2-harv.tex'.

### Footnotes

1. journal: Astronomy & Computing
2. footnotetext: This code is registered at the ASCL with the code entry ascl:1704.005.
3. http://dasch.rc.fas.harvard.edu/
4. https://www.plate-archive.org
5. http://dc.zah.uni-heidelberg.de/lswscans/res/positions/q/info
6. http://plate-archive.hs.uni-hamburg.de/index.php/en/
7. https://github.com/vterron/lemon
8. http://www.astromatic.net/software/sextractor
9. https://github.com/mommermi/photometrypipeline
10. http://c-munipack.sourceforge.net/
11. http://www.astrosurf.com/orodeno/fotodif/
12. http://astro.ins.urfu.ru/en/node/1330
13. http://iraf.noao.edu/
14. https://fitsh.net/
15. http://www.astro.princeton.edu/~jhartman/vartools.html
16. http://www.astro.washington.edu/users/becker/v2.0/hotpants.html
17. http://www.astro.washington.edu/users/becker/v2.0/wcsremap.html
18. http://www2.iap.fr/users/alard/package.html
19. http://users.camk.edu.pl/pych/DIAPL/index.html
20. https://github.com/transientskp/tkp
21. http://www.astro.caltech.edu/~tjp/pgplot/
22. http://fits.gsfc.nasa.gov/
23. VaST will automatically get the current values from http://maia.usno.navy.mil/ser7/tai-utc.dat
24. http://www.astromatic.net/software/psfex
25. The use of internal pixel-based coordinate system instead of celestial coordinates may seem strange nowadays, but was natural back in 2004 when we started developing VaST. Before the release of the Astrometry.net software (2010AJ....139.1782L, 2008ASPC..394...27H) there was no easy way to assign WCS to “random” images having no a priori information in FITS header about the image center, scale and orientation (which was often the case for images obtained with non-robotic telescopes).
26. A C implementation of 2007PASA...24..189T algorithm may be found at
http://spiff.rit.edu/match/
27. https://ned.ipac.caltech.edu/level5/Stetson/Stetson5_2.html
28. http://scan.sai.msu.ru/lk/
29. http://www.astro.caltech.edu/~tjp/pgplot/
31. http://www.sai.msu.su/gcvs/gcvs/
32. https://www.aavso.org/vsx/
34. http://vizier.u-strasbg.fr/
35. http://scan.sai.msu.ru/nmw/
36. http://www.projectpluto.com/pluto/devel/astcheck.htm
37. http://www.minorplanetcenter.net/
38. http://valgrind.org/
39. https://boinc.berkeley.edu/trac/wiki/VmCompatibility
40. For example, mawk which is the default awk in Ubuntu will not understand "%lf" in the printf formatting string (accepting only "%f"):
echo 1.23 | awk '{printf "%lf\n",\$1}'
while it is perfectly fine for gawk which is the default in most Linux distributions as well as BSD awk. This kind of differences are hard to anticipate, so they need to be tested for.
41. http://scan.sai.msu.ru/vast/#public
43. http://astrotourist.info/poisk-peremennykh-zvezd
44. https://www.astromatic.net/pubsvn/software/sextractor/trunk/doc/sextractor.pdf
46. ftp://scan.sai.msu.ru/pub/software/tiff2fits/
47. http://aa.usno.navy.mil/software/novas/novas_info.php
48. https://naif.jpl.nasa.gov/naif/
49. http://scan.sai.msu.ru/vast/Helmos_test
50. http://helmos.astro.noa.gr/
You are adding the first comment!
How to quickly get a good reply:
• Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
• Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
• Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minumum 40 characters