The SWAP Ground Segment current status and progress

The SWAP Ground Segment current status and progress Gareth Lawrence, David Berghmans, Christophe Marque, Bogdan Nicula (all ROB), Vladimir Slemzin (Lebedev Inst. Moscow)

Function of the SWAP Ground Segment • Turn the scientists’ planning into a coherent Science Plan in a language and format the spacecraft can understand, by relaying telecommands from Science Centre → Ground Station • Process the telemetry received from the spacecraft via the Ground Station to turn the packets of bits into images that a solar scientist can recognise

Location and Physical Setup of the Ground Segment • All Ground Segment hardware will be located within the SIDC at ROB within a secure office dedicated to operations hardware • 2 x dedicated workstations with identical OS and software setups, for redundancy • OS and software setups ‘frozen’ from before launch - only essential updates performed • Probable choice of OS: unix

Telecommanding • The Science Centre at ROB transmits an Instrument Operations Sheet (IOS) to the Redu ground station on a daily basis • IOS then transmitted from Redu to spacecraft • Redu has 4 daily contacts with spacecraft; normally one used for telecommanding but the second can conceivably be used in exceptional circumstances • Normally an IOS will cover a 3 -day period to cover unexpected circumstances

The SWAP IOS • A sequence of time-tagged configuration, acquisition and management commands • In total 30 unique parameters can be set; roughly 50: 50 split between exposure settings vs onboard processing (ie ‘before’ and ‘after’) • Image acquisitions can be defined and sent individually, or collectively via configurable onboard command table The SWAP IOS Reference Document is in prep. , to be made available online

Simplistic Sample IOS’s SWAP 12345 2006. 07 12: 34: 56. 789 2006. 06. 08 00: 00: 00. 000_Acquisition configuration_double sampling_30_0_0_1023_0_1_60_30_12 bits_0. 0 2006. 08 00: 01. 000_Data management_off_0_off_adaptive_0_0_jpeg_1_on_float_128_0_off_on_0_on 2006. 08 00: 02. 000_Specific acquisition SWAP 23456 2006. 07 12: 34: 56. 789 2006. 06. 08 00: 00: 00. 000_Acquisition configuration_double sampling_30_0_0_1023_0_1_60_30_12 bits_0. 0 2006. 08 00: 01. 000_Data management_cosmic rays_50_off_adaptive_0_0_jpeg_1_on_float_128_0_off_on_0_on 2006. 08 00: 02. 000_Table acquisition_0_100 which command, respectively, the capture of a single image and a sequence of images as defined by the onboard commanding table, having previously set the onboard processing parameters

A ‘Practical’ Sample IOS SWAP 34567 2006. 07 12: 34: 56. 789 2006. 06. 08 00: 00: 00. 000_Acquisition configuration_double sampling_30_0_0_1023_0_1_60_30_12 bits_0. 0 2006. 08 00: 01. 000_Data management_cosmic rays_50_off_adaptive_0_0_jpeg_1_on_float_128_0_off_on_0_on 2006. 08 00: 02. 000_Table acquisition_0_100 2006. 08 01: 40: 00. 000_Acquisition configuration_correlated double sampling_15_0_0_1023_0_2_15_0_12 bits_0. 0 2006. 08 01: 40: 01. 000_Data management_on_0_on_fixed_200_3500_jpeg_3_on_float_128_0_off_0_off 2006. 08 01: 40: 02. 000_Table configuration_4 10_15_0_0_511_2_15_0. 0_on_0 11_15_0_512_511_1023_2_15_0. 0_on_0 12_15_512_1023_2_15_0. 0_on_0 13_15_512_0_1023_511_2_15_0. 0_on_0 2006. 08 01: 40: 03. 000_Table acquisition_10_4 2006. 08 01: 42: 00. 000_Acquisition configuration_double sampling_15_0_0_1023_0_1_15_100_12 bits_0. 0 2006. 08 01: 42: 01. 000_Data management_cosmic rays_50_on_fixed_200_3500_lzw_0_off_float_0_8_on_on_0_on 2006. 08 01: 42: 02. 000_Table acquisition_0_100 which commands a ‘CME-watch’ sequence, then a quadrant subfield sequence, then a high-cadence rebinned CME-watch, always setting the onboard processing parameters accordingly

SWAP Commanding Interface • Web-based, via a dedicated server at ROB • PHP-5(? -TBC) to input command sequence • JAVA pop-ups used to clarify display for initial visual inspection • CLIPS to check logic, both internally wrt to nominal ranges for SWAP commanding and cross-checking with LYRA for consistency • See Ch Marque/B Nicula, this meeting, for details

Telemetry • SWAP has 5 daily contacts with Redu for a total of 40 mins, with max. gap ~12 hrs • This gives inadequate telemetry for SWAP (though fine for telecommanding) • Likely 2 nd ground station: Svalbard, with ~one contact per orbit (duration TBC), which in principle should ‘solve’ the TM bottleneck • Svalbard can at present only receive science packets from SWAP, not ancilliary or housekeeping data

Reformatting Science Packets • Science packets are compressed packets of bits that need to be reformatted into individual arrays corresponding to solar disk images • These arrays need to be augmented with physical parameters to allow scientists to make sense of them both individually and in context • These parameters form the ‘header’ and are derived from the meta-, ancilliary and housekeeping data, also from the telecommanding and finally from the array • Calculating different sets of parameters for a given image correspond to different levels of processing for the dataset as a whole

SWAP Processing Pipeline • The initial dataset - called RAW - will simply arrange the 1 Kx 1 K array of photon counts and collect the exposure/onboard processing parameters, plus pointing/attitude data as quaternions, as header • The reformatter will be written in C and will utilise the CFITSIO package • RAW data will NOT be distributed • Science data will be derived from the RAW data and will be called QKL, LV 0, LV 1, etc. , depending on the level of processing. This will probably be done via a high-level data analysis software suite, e. g. IDL • Science data will be distributed to the community via a dedicated server at ROB

SWAP Processing Levels I • RAW - array of DN, plus commanded parameters and basic pointing. No additional processing applied and no parameters derived. Data not distributed • QKL (quicklook) - DN array but with pointing given in geocentric and heliocentric units and additional parameters required for processing and analysis provided. Since precise pointing parameters will NOT always be available in near-real time some interpolation will be necessary. These data are intended for space weather monitoring and will be made available within ~30 mins of transmission of the original packet to ROB, viewed preferably with the Solar Weather Browser (SWB)

SWAP Processing Levels II • LV 0 (level 0) - as QKL but with accurate pointing and attitude parameters derived from both the housekeeping data and via orbital three-line element (TLE) files processed by the SPICE package available from NASA-JPL. These data are intended for scientific analysis and will be made available within ~24 hrs of transmission of the original packet to ROB • LV 1 (level 1) - a photometrically calibrated dataset for ease of use by non-IDL users. These data will be delivered to ESAC after the end of the mission. Could conceivably correct for spacecraft roll.

Possible Additional SWAP Processing Levels/Data Products • LV 2(? ) - a LYRA-like time series of integrated total flux • SPW (spaceweather) - lists of space weather events, generated autonomously by near-real time analysis software • Filenames will be of type (swap_raw_20080101. 012345) swap_qkl_20080101. 012345 swap_lv 0_20080101. 012345 swap_lv 1_20080101. 012345 etc

Note: SPICE is a system developed to assist scientists/engineers with satellite based observations/operations. The basic element is a kernel file: • • • S- Spacecraft ephemeris, given as a function of time. P- Planet, satellite, comet, or asteroid ephemerides I - Instrument description kernel C- Pointing kernel, containing a transformation called the C-matrix E- Events kernel: mission activities, both planned and unanticipated SPICE can accept a wide variety of inputs (eg TLE’s, quaternions(? )) and can generate a vast amount of output. SWAP will use SPICE to generate pointing and attitude parameters in a variety of co-ordinate systems. A small number will be included in the Science Data Headers, the rest will be stored at the Science Centre and can be made available upon request. See http: //naif. jpl. nasa. gov/naif for further details.

SWAP Data Processing/Analysis • As is now conventional with solar physics data analysis, SWAP analysis software will be written in IDL and incorporated within, and distributed via, the Solar Soft. Ware (SSW) hierarchy (see http: //www. lmsal. com/solarsoft for details) • In particular a routine swap_prep. pro will be written to ensure that SWAP images are processed correctly to optimise scientific return • The ‘normal’ suite of routines will be provided: definition of ‘normal’ TBD via splinter • See the presentation of A de Groof, this meeting, for details; see also presentation of P Gallagher from SCSL 1 at http: //www. issi. unibe. ch/teams/SCSL/Meeting 1/Gallagher. ppt for an object-oriented approach

SWAP Science Data FITS Headers See SWAP FITS Header Reference Document (GRL, Nov 2006; available online or at this meeting SIMPLE = BITPIX = NAXIS 1 = NAXIS 2 = T / SWAP data will always be SIMPLE FITS format 16 / Short integer (2 bytes/word) 2 / Number of axes 1024 / Number of columns 1024 / Number of rows The keywords in bold font above are all required FITS keywords [1, 5]. SIMPLE is a logical (either T or F) keyword specifying whether the file conforms to basic FITS standards; SWAP data will always be SIMPLE = T. BITPIX states the number of bits per pixel and can take values 8, 16, 32. . . so although SWAP data will be 11 or 12 bits/pixel it is given as 16. The next 3 keywords indicate the number of axes plus number of pixels along each of those axes: all SWAP images will have two axes and most images will be 1024 x 1024 pixels

DATE-OBS= '2008 -01 -01 T 01: 23: 45. 678' / UTC at spacecraft TIME-OBS= '01: 23: 45' / Derived from DATE-OBS DATE = '2008 -01 -01' / Date of file creation DATASRC = 'Redu' / Redu or Svalbard, the active GS DATE-OBS denotes both the date and time at which the image was taken (see [4] for details of standard formats). TIME-OBS contains just the time. Historically, DATE-OBS did not always contain the time information so TIME-OBS was added, and TIME-OBS has since become a familiar and widely used keyword so it is retained here. Note also that the time in DATE-OBS is given to several decimal places (TBD) while TIME-OBS is either rounded or truncated. DATE refers to the date of FITS file creation and will often differ from the date part of DATE-OBS due to telemetry delays, level of processing etc. DATASRC refers to the receiving ground station, which will initially be either Redu (Belgium) or Svalbard (Norway). ORIGIN = 'ROB-SIDC' / Both QL and LZ data processed at ROB TELESCOP= 'PROBA 2' / Satellite name INSTRUME= 'SWAP' / Instrument name OBJECT = 'Full EUV Sun, 17. 5 nm'/ Object of observation WAVELNTH= 175 / 175 = Fe IX/X FILTER = 'Al' / SWAP filter DETECTOR= '1 Kx 1 K CMOS' / SWAP detector Initially all data will be processed at the Solar Influences Data analysis Centre (SIDC) at the Royal Observatory of Belgium (ROB) but it is forseen that eg at the end of the mission a fully photometrically calibrated archive will be held at ESAC, Madrid. Following convention, TELESCOP and INSTRUME denote, respectively, the names of the mission (PROBA 2) and observing instrument (SWAP) while OBJECT and WAVELNTH describe the target of observation and observation wavelength - here the full Sun observed in extreme-ultraviolet at 17. 5 nm. Note that for historical reasons the wavelength is given in Angstrom rather than nanometres. The instrument's FILTER and DETECTOR are also described.

OBS_MODE= 'Sun-centred Full FOV'/ S-C FFOV or Special Operations OBS_PROG= 'Nominal' / Nominal/Offpointed/CME-tracking/Subfield/etc EXPTIME = 10. 000 / [s] (commanded, no shutter delay) acc. TBD EXPMODE = 'NDR' / Non-destructive/destructive readout FILENAME= 'swap_qkl_20080101. 012345' / TBC, see note below SWAP will have two observational modes given by OBS_MODE: Sun-centred Full Field of View, and Special Operations. Essentially this means 'Normal mode' vs 'Something Different'. More detailed information is given in OBS_PROG, the observing program. Whenever OBS_MODE is S-C FFOV then OBS_PROG will be Nominal, while an OBS_MODE of Special Operations can involve one of many OBS_PROGs - but never Nominal. Examples of possible OBS_PROG are: Offpointed, CME-Tracking, Subfield, Calibration. The integration time is given by EXPTIME and since SWAP does not have a shutter then this figure should be very accurate. If it is found to be inaccurate then the most accurate exposure time will be calculated from the image and given in EXPTIME, rather than including a correction factor. Two distinct exposure modes are possible: non-destructive readout and destructive readout; thus EXPMODE will be either NDR or DR, indicating whether or not correlated double sampling has been used to enhance the signal-noise ratio. The format of FILENAME, the name of the file that the header and image are written to, is presently TBC, but is likely to take the form swap_qkl_YYYYMMDD. HHMMSS. (For subsequent datasets following additional processing, 'qkl' will be replaced by, eg, 'lv 0' or 'lv 1' to denote Level_0 and Level_1 data. )

BSCALE = 1. 000 / } Will take different values BOTH BZERO = 0. 000 / } for LZ (calibrated) data FLT BUNIT = 'counts/pixel' / DATAMIN = 0 / Array min. val. DATAMAX = 4096 / Array max. val. Quicklook data will be INT arrays and will need to be processed via eg IDL using the parameters contained in the headers. It is envisaged that at the end of the mission a photometrically calibrated archive could be provided. To avoid storing these images as large FLT files, a multiplicative factor BSCALE and an additive factor BZERO will be calculated, to enable each array value to be represented as Vint. The true value of each pixel would then be Vint*BSCALE+BZERO. For all other images BSCALE and BZERO will be 1. 000 and 0. 000. BUNIT is the unit of the data: counts per pixel for every image. DATAMIN[MAX] refer to the minimum and maximun data values within the file. The values given here are sample based on the full dynamic range of a 12 -bit image. Note that for a future dataset of calibrated images both the maximum and minimum values will still be INT rather than FLT and will need to be used in conjunction with BSCALE and BZERO. SOLAR_R = 302. 62 / [pixels] Photospheric radius, SWAP pixels SOLAR_B 0= 6. 68 / [deg] Solar B-angle HGLT_OBS= 6. 68 / [deg] s/c heliographic lat. HGLN_OBS= 0. 00 / [deg] s/c heliographic lon. <0. 003 deg CAR_ROT = 2061. 00 / Carrington rotation at earth (Jan 08) DSUN_OBS= 149877163960. 39 / [m] s/c distance from Sun SOLAR_R and SOLAR_B 0 denote the photospheric radius and B 0 angle for a given date and time as viewed from the spacecraft. The heliographic latitude HGLT_OBS is the same as SOLAR_B 0 but the latter is retained for the same reason as TIME-OBS. CAR_ROT refers to the Carrington rotation during which the image was taken, while DSUN_OBS is the distance between Sun and observer; note that it, like all distances, is given in metres, since FITS uses MKS units strictly.

CTYPE 1 = 'HPLN-TAN' / Helioprojective longitude (Solar-X) CTYPE 2 = 'HPLT-TAN' / Helioprojective latitude (Solar-Y) CUNIT 1 = 'arcsec' / Units along X-axis CUNIT 2 = 'arcsec' / Units along Y-axis CRPIX 1 = 512. 00 / [pixels] Sun center x, SWAP pixels CRPIX 2 = 512. 00 / [pixels] Sun center y, SWAP pixels CRVAL 1 = 0. 00 / [arcsec] Value of X-axis at CRPIX 1 CRVAL 2 = 0. 00 / [arcsec] Value of Y-axis at CRPIX 2 CDELT 1 = 3. 00 / [arcsec] Pixel scale x (fixed) TBC CDELT 2 = 3. 00 / [arcsec] Pixel scale y (fixed) TBC CROTA 1 = 0. 00 / }[deg] Rot. X[Y]-axis about CROTA 2 = 0. 00 / } normal to image plane This group of keywords describes the relationship between the detector and target. CTYPE 1[2] describe the nature of the images - the projection of the solar disk - and the units (arcsec) are given in CUNIT 1[2]. CRPIX 1[2] give the pixel indices of the reference point – the Sun’s centre - and CRVAL 1[2] give the value of this point in the units defined by CUNIT 1[2]; in the example here the solar disk is assumed to be perfectly centred on the detector. The plate scale of the SWAP detector is given by CDELT 1[2] while the rotation of the axes (in this case, two) about the direction normal to the image plane is given in CROTA 1[2]. Since the two image axes are perpendicular, only CROTA 1 is strictly needed but CROTA 2 is retained here, for consistency. Note that since PROBA 2 is in LEO and has only one startracker onboard, it must perform a full 360 degree roll per orbit. This will be done via a series of large angle rotations rather than continuously rolling, and the value will be given in CROTA 1[2] for each image.

SC_X 0 = 0. 00 / [arcsec] s/c yaw SC_Y 0 = 0. 00 / [arcsec] s/c pitch SC_ROLL = 0. 00 / [deg] s/c large-angle rotation HEEX_OBS= 119317272000. 00 / [m] s/c heliocentric earth ecliptic x HEEY_OBS= -90700288000. 00 / [m] s/c heliocentric earth ecliptic y HEEZ_OBS= -103131000. 23 / [m] s/c heliocentric earth ecliptic z GSEX_OBS= 50000. 00 / [m] s/c geocentric solar ecliptic x GSEY_OBS= 530000. 00 / [m] s/c geocentric solar ecliptic y GSEZ_OBS= 600000. 00 / [m] s/c geocentric solar ecliptic z These are the positional parameters of the spacecraft in various coordinate systems. The World Coordinate System (WCS) keywords [6, 7] have been used to make SWAP data as compatible as possible with other missions and data analysis frameworks (eg, STEREOSECCHI [8], SDO, VSO, Solar. Monitor, Solar. Soft [9]). The spacecraft yaw, pitch and roll are described in SC_X 0, SC_Y 0, SC_ROLL. Note that SC_ROLL is an older keyword that predates CROTA 1[2] (see above) but it is retained for the same reasons as TIME-OBS. The X-, Y- and Z- components of the spacecraft's position in Heliocentric-Earth-Ecliptic (HEE) and Geocentric-Solar-Ecliptic (GSE) coordinates are given. Positional data in a variety of coordinate systems/formats will be routinely calculated per image using the SPICE [10] software suite from NASA-JPL. These data will be stored both as SPICE kernels and in a database at the science centre, and can be made available via the science centre upon request.

P 1_X = P 2_X = P 1_Y = P 2_y = OFF 1_PIX= OFF 2_PIX= OFF 1_ARC= REBIN = 1 / First X-pixel read out 1024 / Last X-pixel read out 1 / First Y-pixel read out 1024 / Last Y-pixel read out 0 / [pixels] Mag. of X-offpoint, FLT 0 / [pixels] Mag. of Y-offpoint, FLT 0. 000 / [arcsec] Mag. of X-offpoint, FLT 0. 000 / [arcsec] Mag. of Y-offpoint, FLT 1 / Onboard rebinning factor, INT 1 or 2 The image relative to the detector and electronics is summarised here. The first and last pixel indices read out in the X and Y directions are given in P 1[2]_X[Y]; for most SWAP images these will be 1 and 1024 along both axes. For the cases when the satellite is offpointed the extent to which the centre of the solar disk is displaced from the centre of the detector is given, both in numbers of pixels and arcsec, in OFF 1[2]_PIX[ARC]. In the case of large offpoints where the sun is completely off the detector, a CHAR flag 'Off Image' will appear in OFF 1[2]_PIX; the degree of offpoint in arcsec will still be given in OFF 1[2]_ARC. Some images will be rebinned onboard and the rebin factor is given in REBIN; 1 means no rebinning, 2 means rebinning to 512 x 512.

OFFSET = 0. 000 / Detector bias, FLT GAIN = 1. 000 / Detector PGA gain, FLT RECODE ='YES' / Onboard 8 -bit recoding, CHAR YES/NO RECMIN = 0 / Lower limit for Fixed Recoding Table, INT RECMAX = 4096 / Upper limit for Fixed Recoding Table, INT N_CME_TR= 30 / #images in CME tracking sequence, INT COMPRESS= 0 / 'Compression Index', INT 0. . 5 (see note) MISS_PIX= 0 / Number of missing pixels, INT This is a series of processing keywords that will be needed to render and manipulate the images. OFFSET is the bias that must be subtracted from each image and is and calculated for each image. GAIN is controlled by a programmable gain amplifier and will generally be 1. 0, but can be set to one of four pre-defined values. Most SWAP images will be recoded to 8 -bit versions onboard before relay and then restored to their full bit-depth on the ground so RECODE is YES or NO; if true then the minimum and maximum values used in the recoding table are given in RECMIN and RECMAX. SWAP is capable of switching to automatic CME tracking and when it does so the number of images in a given tracking sequence is stored in N_CME_TR. COMPRESS refers to the "Compression Index" of the image (see note below) and takes the value 0 for no compression and 5 for the most compressed images. MISS_PIX gives the number of missing pixels; it is equivalent to the more familiar notion of missing telemetry blocks, but in most SWAP images these missing pixels will not necessarily form neat blocks, due to onboard processing etc. HISTORY Version 1. 0, 2008 January 01 END See SWAP FITS Header Reference Document (GRL, Nov 2006; available online or at this meeting

blank

SWAP Science Data Image Processing Gareth Lawrence, David Berghmans, Christophe Marque, Bogdan Nicula, Vladimir Slemzin with contributions by Anik de Groof (KU Leuven), Huw Morgan (IFA, Hawaii) Guillermo Stenborg (NRL; NASA-GSFC)

SWAP Data A comparison of EIT 17. 1 nm and SWAP 17. 5 nm images FOV: 45 arcmin 2. 36 R 1. 67 R FOV: 54 arcmin

SWAP Deep Coronal Imaging • Mainly due to the difference in focal length the solar disk in a SWAP image will be ~20% smaller than in a simultaneous EIT image; thus SWAP will image correspondingly more of the extended corona • SWAP will routinely run ‘paving campaigns’ via offpoint to build up mosaics of the extended EUV corona, even overlapping the LASCO-C 2 Fo. V • In addition, off-pointing to track CMEs out to the LASCO-C 2 Fo. V is anticipated • Standard EIT processing techniques do not render the extended corona well so alternative methods should be considered for the standard processing of SWAP images

GOES 13 -SXI Deep Coronal Mosiacs Above: original, and Left: wavelet-enhanced

Wavelet-enhanced EIT Image EIT images reveal a wealth of detail in the off-limb region when the original is decomposed into distinct regions and multi-scale wavelets used (movie courtesy G Stenborg)

Normalising Radial Graded Filter (NRGF) Another method of highlighting structure and dynamics in the deep corona by treating the on-disk and off-limb regimes differently and optimising their respective parameter sets (movie courtesy H Morgan)