DKIST Data Set Caveats (ViSP / VBI)

General Caveats

Please note that there are limitations inherent to the Operations Commissioning Phase (shared-risk environment). During early operations, we continue to learn more about the instruments and the environment that they are operating in, and some prior unknown technical limitations have been encountered. For ViSP for example, some of these limitations had an impact on the frame rate and as such the time spent on an individual slit position and the map cadences that ViSP can achieve.

In general, summit science operations staff (i.e., resident scientists and science operations specialists) strive to match the requests of any observing proposal the best they can, but there are no guarantees that for example, the lengths of observations, cadences or the requested seeing will be 100% consistent with the proposal. If you do have any questions about (summit) science operations and the execution of your observing program(s) you may also contact the DKIST Program Scientist for Operations atritschler@nso.edu or use the DKIST Help Desk.


ViSP Data Set Caveats

These caveats cover all the ViSP datasets released so far through OCP 1.8 (December 2023). There have been major updates to the ViSP pipeline code during the OCP. Most recently these have included,

  • Improved polarization calibration algorithms to resolve modulation variation along the slit.

  • Dual-beam intensity balancing prior to combination.

  • Dual-beam alignment (geometric registration) improvements.

  • Polarization coordinate frame corrections

  • Modified flat field algorithms to remove residual gain artifacts. 

A brand-new release of ViSP data was initiated on April 23, 2023, which incorporated the changes mentioned above. They are explained in detail in [ViSP pipeline calibration changes (Apr/May 2023)] and demonstrate considerable improvement in the calibration of 630 and 854 nm data. Existing Ca II 396 nm data has also been reprocessed, though the level of improvement is less pronounced.

Spatial Registration

Metadata Issues

  • The current ViSP L1 data has incorrect pointing information in the WCS headers. This is not currently correctable. When possible, users are recommended to use the VBI data as context for the VISP data, and, again when possible, perform spatial registration of VISP maps with other solar data sets.

  • The effects of atmospheric dispersion are inherent to all ground-based data. No attempt to correct or augment WCS information has been made to account for atmospheric dispersion.

  • In particular, with the earlier OCP data, there is a problem with the ViSP CDELT2 keyword (see also the following issue), which gives the pixel plate scale along the slit. We have not yet been able to fix it in all VISP files. The following are the recommended nominal values:

    • arm 1 630 nm: 0.0298"/pixel

    • arm 2 397 nm: 0.0245"/pixel

    • arm 3 854 nm: 0.0194"/pixel

  • The keywords NAXIS1 and NAXIS2 give the lengths of the spatial and spectral axis of the data array, respectively. In earlier data, the keywords CDELT1, CDELT1A, CRPIX1, CRPIX1A, CRVAL1, CRVAL1A, CTYPE1, CTYPE1A, CRDATE1, and CRDATE1A had referred to spectral quantities as opposed to spatial quantities. While this is believed to now be fixed, there may be other keywords (for example the PCi_j matrix elements) that are "transposed" as a result of this issue.

Slit Width and Stepping Width

Prior to March 2023, the units given in the header for the keywords ‘VSPWID’ and ‘VSPSLTSS’ were incorrect. VSPWID records the VISP slit width in arcsec (on Sky), and VSPSLTSS records the slit raster step size in mm. The equivalent step size in arcsec is determined by the plate scale at the VISP slit, which is 1.613 arcsec per mm. For example, the value of VSPSLTSS for the EID_1_118 data is 0.1326759 mm. In arcseconds, this corresponds to a 0.214 arcsec step size equivalent to the slit width used for this experiment.

Spatial Drift along Slit during Raster Scan

The position of the hairline fiducials is known to drift during the raster scan by a few pixels along the spatial direction. This remains uncorrected in the Level 1 data at this time.

Spectral Registration

Correcting the spectral axis

The wavelength axis information contained in the L1 data headers is not currently accurate. At this time, it is inherited from the raw data values without further corrections applied within the pipeline. Therefore, users must do their due diligence to ensure the wavelength axis is calibrated to an accuracy sufficient for their own purposes. In cycle 1, the VISP wavelengths of 397, 630, and 854 nm had nominal dispersions of 0.77 pm pixel-1, 1.285 pm pixel-1, and 1.882 pm pixel-1, respectively. However, users should be aware that the dispersion is nonlinear. At 630 nm and 854 nm, there is a ~1% change in the linear dispersion value across the observed bandwidth. The figures below demonstrate a spectral calibration of the first spatial step’s characteristic spectrum in two datasets from EID_1_118, as identified. The spectral calibration is achieved by fitting the positions of the strongest telluric lines in the VISP spectrum (in 0-indexed pixel units) and the NSO/FTS Telluric Atlas (in corrected wavelength units). A quadratic polynomial is then fit to these values, as given in the figures. At 397 nm, this comparison likely must rely on the solar lines themselves, requiring closer attention from the user.

Drifts of the spectral axis as a function of scan position

The spectral axis is also known to drift as a function of the raster step position. This is not currently corrected in the L1 VISP data. Below, the derived spectral shift in pixel units is given for the EID_1_118 BRWJV dataset as a function of the Slit Translation Position in millimeters.

Polarization Accuracy

General Comments

Ensuring very high polarization accuracy is a key objective for all VISP data, and it relies on both calibration data acquired during a specific experiment and system-level calibration data that is used to model the polarization properties of the telescope mirrors between M1 and the Coude laboratory. In addition, a number of factors can influence the polarization accuracy of a given data set. For example, stray light (discussed further below) and seeing-induced polarization can both degrade polarization accuracy in ways that can be difficult to quantify. This is especially the case during the current OCP phase as we continue to learn more about the instrument’s performance. Do proceed cautiously and please use the DKIST Help Desk to ask questions if and when they arise.

Polarization Coordinate Frame

L1 data distributed prior to April 2023 attempted to rotate the telescope’s polarization coordinate frame to the solar frame; however, it only included the parallactic angle (ignoring the P-angle) and applied the rotation in the wrong direction. This led to an incorrect and time-variable polarization reference frame. The revised data products now apply the correct rotation so that the polarization coordinate frame is stable in time and consistent with canonical reference coordinates used by SDO/HMI and Hinode-SP, as shown in the figure below (courtesy of Ichimoto et al. Sol Phys 249, 233–261 (2008). https://doi.org/10.1007/s11207-008-9169-9). The figure references the solar cardinal points where N/S is aligned with the solar rotation axis. The solar rotation axis is misaligned from the geocentric celestial frame by the P angle which varies from +/- the Earth’s obliquity. Additionally, the celestial frame is rotated from the Alt/Az local frame by the parallactic angle. The two combined are sometimes referred to as the solar orientation angle.

Residual Crosstalk Corrections

After polarization calibration, it is common to have small-scale residual I-> Q,U,V crosstalk still present in the data, as these crosstalk terms are the most difficult to reliably control. The typical approach used to mitigate this residual crosstalk is to assume the continuum is unpolarized, which is an increasingly valid assumption with proximity to the disk center.

The residual signal within the continuum for the I-normalized polarized state (X) gives a direct measure for the fraction of Stokes I to X crosstalk. Therefore, on an individual spectrum basis, one can apply a correction as follows (e.g. for Q):

As, an example, a single Stokes spectrum from EID_1_118 Dataset BRWJV is shown below, before and after applying the correction to Q. (NOTE: U and V corrections not shown). Note how the horizontal streaking and the signatures of the telluric lines are removed from the corrected Q state.

The above correction can be applied on a spectrum-by-spectrum basis. It is common for the median crosstalk value to evolve in time as a function of the raster step position number, as shown in the following figure.

Detailed Description of Optical Issues and Mitigation Efforts

Stray Light

Testing had identified multiple sources of stray light in ViSP. Some stray light had entered from the sides and top at the end of the camera arms that were open to the environment. Installation of various baffles was done between May and June 2022. These were successful in reducing stray light from external sources. Data taken through at least OCP 1.4 (ended 06/17/2022) will contain stray light from this source.

A second source of background light was identified to come from within the beam. Mitigation of this source has included the insertion of aperture masks within the relay arms, which has considerably improved data acquired later in OCP 1, especially during OCP 1.8 (Dec 2022).

For most OCP 1 data, an ad-hoc algorithm was developed and used to fit and subtract this background source using PolCal data (see below). Analysis of this signal shows it to be additive and mostly unpolarized, much like a dark or background signal. This signal has a much more significant contribution in frames with overall low flux (e.g. 396 nm and 854 nm channels, and the dimmer of the two dual beams).

In order to mitigate this, the Data Center is currently using an algorithm that uses the PolCal frames taken at a single slit position. We use the assumption that the modulation should be spectrally constant over the ~1nm bandpass covered within a ViSP camera arm.  By normalizing each of the raw PolCal intensity spectra to the mean overall spectral pixels, we get a spectrum compensated for the intensity modulation. Variation in these normalized intensities with wavelength is a measure of the stray light impact.  Spectral invariance of modulation has been confirmed in each camera arm, and also by comparing the intensity modulation curves of both orthogonally polarized beams recorded strictly simultaneously in the dual beams of each camera. The worst behavior has been observed in the 854nm channel, in one of the two beams as seen below:

The algorithm finds a single background unpolarized spectrum, that when subtracted from all the individual modulated spectra, minimizes the spectral variation of the mean-normalized intensities.  These background intensities correlate well with a known stray light optical pathway. An example of the stray light background in the 854nm channel from June is below.  We note that this background is recorded after, and is not impacted by the installation of the external baffles discussed above.    

If we then subtract the background signal from all the individual spectra, prior to normalization, then we get the following modulation-normalized spectral shape:

There’s still some residual difference between the normalized spectra, but overall, the normalized spectra look much more spectrally constant. The resulting modulation curves similarly agree much better in overall contrast and uniformity. Ultimately the best way to deal with this issue is to remove the stray light with appropriate optical aperture stops and masking. Work on this topic is ongoing. The algorithm presented above is not a perfect solution. It is only intended to get data “good enough” at this point, and further tuning of the algorithm settings is necessary. You may notice that there are some line artifacts visible. If you do have any questions or if you see any issues with line signals, you are encouraged to ask (DKIST Help Desk.)

Efficiency Drop in 854 nm (Arm 3) & 397 nm (Arm 2)  Beam 2

A polarimetric efficiency drop with one of the two beams in both arms 2 and 3 has been noted.

  • 854 nm Beam 2 (Arm3) has anomalously low modulation efficiency (35% vs 50%). 397 nm Beam 2 (Arm2) also has reduced efficiency.  It is suspected that this is due to low polarization beam splitter contrast. Optical mitigation likely will be required, and modeling is ongoing. We note that subtraction of the intrinsic stray light (above) improved the modulation efficiency, but it remains at/below 38%.

ViSP Camera Artifacts During OCP 1.8 

An issue has been discovered that affects 397 nm data taken during OCP 1.8 (datasets covering Dec 27-30, 2022), and has also been seen in other wavelengths. The ViSP detectors (which are actively cooled) suffered from a condensation buildup which resulted in the pattern you can see as spots on the right-hand side of the detector (and zoomed in, inset left) in the gain image. These spots have such high central core values that they ruin the segmentation algorithm used to find the two hairlines. Without the hairlines being properly detected, the angle calculation used in determining the overlap of the two beams fails. While the routine for finding the hairlines can be (and is being) hardened against such occurrences, it should be noted that this artifact is also in the science data frames. The camera was subsequently allowed to warm to around 0 degrees C and the condensation disappeared. However, this in turn is likely to slightly increase the noise seen in the images.

A gain image in the 397 nm channel showing condensation effects. Inset, a zoomed-in image of the spots.


VBI Data Set Caveats

The following issues have been found/are being worked on with VBI datasets.

Metadata Issues

  • A wrong value is stored in the CRPIX[N] fits header keywords for proposals carried out in OCP 1.2 / 1.3 (February 2022 through April 2022). This should be corrected for runs from April 2022 onward.

Dataset Issues

  • We are working on understanding the response of the DKIST Wavefront Correction System (WFC) to varying atmospheric seeing conditions. The WFC system performance is still in the process of being optimized. The Fried parameter keyword AO___001 within your data set headers provides an estimate of the prevailing seeing condition. Due to technical limitations in the way the estimate is generated by the WFC system, the value provided can be misleading. Therefore, the reconstruction process occasionally fails even if a good Fried parameter is estimated. Furthermore, unrealistic Fried parameters (in the meter range) are estimated whenever the WFC system encounters conditions that are too severe for operation. In that case, complete image reconstruction is not attempted.

  • We have encountered unexpected technical issues with the VBI cameras leading to a variety of noise artifacts in the data. This includes an overall dynamic noise pattern in the images which is amplified by the reconstruction process, a vertical stripes pattern in the images, and increased noise at strong gradients in the images as seen in particular in high-contrast images. We have developed a variety of algorithms to improve the data quality. These issues continue to be approached from multiple angles to provide further improvements and solutions.

  • In a few rare cases, you might notice an overexposure in the G-Band and the Blue Continuum images which worsens during the observing sequence (as the sun rises). If there is a second observation sequence on the observing day, the exposure time will have been adjusted for this second run.

Using IDL to Read VBI Files

If you want to interact with DKIST data in IDL, you can do this currently using READ_SDO.PRO in SolarSoft. Please note that if you are reading in VBI files using READ_SDO, you will need to use the /USE_SHARED_LIB option.
e.g.

IDL> file = 'atst.ics.vbiBlue.dc.vcc.xfer.74814.100385-1.fits' IDL> read_sdo, file, index, data, /USE_SHARED_LIB  % Compiled module: READ_SDO. atst.ics.vbiBlue.dc.vcc.xfer.74814.100385-1.fits  ---------------------------------------------------------- | reading atst.ics.vbiBlue.dc.vcc.xfer.74814.100385-1.fits |  ----------------------------------------------------------

A dedicated READ_DKIST.PRO is being worked on, including a version that will work outside of SolarSoft, and will be available shortly.


Please don't hesitate to contact us if you have questions.

Alisdair Davey
DKIST Data Center Scientist
adavey@nso.edu

Alexandra Tritschler
DKIST Program Scientist for Operations
atritschler@nso.edu