read_e2ds

tayph.read_e2ds(inpath, outname, read_s1d=True, instrument='HARPS', star='solar', config=False, save_figure=True, skysub=False, rawpath=None, nod='both')

This is the workhorse for reading in a time-series of archival 2D echelle spectra from a couple of instrument pipelines that produce a standard output, and formatting these into the order-wise FITS format that Tayph uses. These

The user should point this script to a folder (located at inpath) that contains their pipeline-reduced echelle spectra. The script expects a certain data format, depending on the instrument in question. It is designed to accept pipeline products of the HARPS, HARPS-N, ESPRESSO, CARMENES and UVES instruments. In the case of HARPS, HARPS-N, CARMENES and ESPRESSO these may be downloaded from the archive. UVES is a bit special, because the 2D echelle spectra are not a standard pipeline output. Typical use cases are explained further below.

Outname is to be set to the name of a datafolder to be located in the data/ subdirectory. An absolute path can also be set (in which case the path stars with a “/”). A relative path can also be set, but needs to start with a “.” to denote the current path. Otherwise, Tayph will place a folder named “data” in the data/ subdirectory, which is probably not your intention.

This script formats the time series of 2D echelle spectra into 2D FITS images, where each FITS file is the time-series of a single echelle order. If the spectrograph has N orders, an order spans npx pixels, and M exposures were taken during the time-series, there will be N FITS files, each measuring M rows by npx columns. This script will read the headers of the pipeline reduced data files to determine the date/time of each, the exposure time, the barycentric correction (without applying it) and the airmass, and writes these to an ASCII table along with the FITS files containing the spectral orders.

A crucial functionality of Tayph is that it also acts as a wrapper for the Molecfit telluric correction software. If installed properly, the user can call this script with the read_s1d keyword to extract 1D spectra from the time-series. The tayph.run.molecfit function can then be used to let Molecfit loop over the entire timeseries. To enable this functionality, the current script needs to read the full-width, 1D spectra that are output by the instrument pipelines. These are saved along with the 2D data. Tayph.run.molecfit can then be called separately on the output data-folder to apply molecfit to this time-series of 1D spectra, creating a time-series of models of the telluric absorption spectrum that is saved along with the 2D fits files. Tayph later interpolates these models onto the 2D spectra to telluric-correct them, as part of the main dataflow. Molecfit is called once in GUI-mode, allowing the user to select the relevant fitting regions and parameters, after which it is repeated automatically for the entire time series.

The read_s1d keyword to activate this functionality is currently ignored. Instead, this switch is now done based on the mode keyword alone, but the keyword is left in for compatibility purposes. We may decide to make this optional again, later.

Set the config keyword equal to true, if you want an example config file to be created in the data output folder, named config_empty. You can then fill in this file for your system, and this function will fill in the required keywords for the geographical coordinates and air, based on the instrument mode selected.

THE FOLLOWING PARAGRAPH IS DEFUNCT AS OF SEPTEMBER 2023:

By setting the measure_RV keyword, the code will run a preliminary cross-correlation with a stellar (PHOENIX) and a telluric template at both vaccuum and air wavelengths to provide the user with information about the nature of the adopted wavelength solution and possible wavelength shifts. the star keyword allows the user to switch between 3 stellar PHOENIX templates. A solar type (6000K), a hot (9000K) or a cool (4000K) template are available, and accessed by setting the star keyword to ‘solar’, ‘hot’ or ‘cool’ respectively. Set the save_figure keyword to save the plot of the spectra and the CCF to the data folder as a PDF. ———-

About the different spectrographs: The processing of HARPS, HARPS-N and ESPRESSO data is executed in an almost identical manner, because the pipeline-reduced products are almost identical. To run on either of these instruments, the user simply downloads all pipeline products of a given time-series, and extracts these in the same folder, producing a sequence of ccfs, e2ds/s2d, s1d, blaze, wave files for each exposure.

For UVES, the functionality is much more constricted because the pipeline reduced data in the ESO archive is generally not of sufficient stability to enable precise time-resolved spectroscopy. I designed this function therefore to run on intermediary pipeline-products produced by the Reflex (GUI) software. For this, a user should download the raw UVES data of their time series, letting ESO’s calselector tool find the associated calibration files. This can easily be many GBs worth of data for a given observing program. The user should then reduce these data with the Reflex software. Reflex creates resampled, stitched 1D spectra as its primary output. However, we will use the intermediate pipeline products, which include the 2D extracted orders, located in Reflex’s working directory after the reduction process is completed.

A further complication of UVES data is that it can be used with different dichroics and ‘arms’, leading to spectral coverage on the blue, and/or redu and redl chips. The user should take care that their time series contains only one blue or red types at any time. If they are mixed, this script will throw an exception. The blue and red arms are regarded as two different spectrographs, and they are. The most important complication this causes is that they have different read-out times, leading to differently sampled time-series. The two red chips (redu and redl) are combined when reading in the data, but the blue data cannot generally be combined. So it’s as if you are dealing with spectral time series from two unrelated observatories that happen to observe at the same time.

When reading ESPRESSO data, the user may choose to read sky-subtracted spectra by setting the skysub keyword to True. If not, Tayph will read the BLAZE files by default. Note that sky subtracted files are also blaze-corrected, meaning that the CCFs will be weighed poorly in Tayph. (Therefore, consider reading of sky-subtracted files to be an incomplete functionality at this time and you are recommended not to use it).

When reading CRIRES+ data, read_e2ds assumes that the data is formatted analogous to when using pycrires (github.com/thomasstolker/pycrires). This implies a file structure, naming and also that the necessary header information is not preserved when evaluating nod combinations. So when reading CRIRES data from pycrires (date June 2 2023), this will work out of the box. But if using a different file structure, or if you find that pycrires doesn’t produce the expected file structure, you may need to set the rawpath variable to point at the location of the raw files that were used by pycrires. What file structure to expect, you ask? Imagine that the data was placed in a folder called /home/user/crires_data The raw fits files then have to be (per pycrires instructions) in: /home/user/crires_data/raw. pycrires renames those files to a format like “CRIRES_SPEC_OBS059_xxxx.fits”, numbering your entire time-series. When going through the pycrires pipeline, other folders will be added in /home/user/crires_data/ including the calib, config and product sub-folders. When running obs_nodding, your reduced data will end up in /home/user/crires_data/product/obs_nodding, including files named as cr2res_obs_nodding_extracted_A/B_xxx.fits. These are the files we need, and this is the folder which’ path we need to give to read_e2ds. Relative to this path, the original raw files are located at ../../raw. This is the default location expected by read_e2ds. If the raw files were located elsewhere, that’s ok, but then you’d have to set the rawpath keyword in read_e2ds explicitly.

For CRIRES you can (and should probably) also set which nod you want to use. Because the two nods get a wavelength shift and can generally behave quite differently, it may be best to treat each nodding position as a separate time series. To do this, you run read_e2ds twice, once with nod=’A’ and again with nod=’B’.