Implementation of binary ZDI code

The ZDI code of Hussain et al. (2000) described in the last section is capable of modelling single stars only. This is despite the fact that it was originally spawned from the DoTS code which can produce surface brightness maps of stars in binary systems. There are a number of reasons that the functionality of a binary star code was not incorporated into

Figure 5.4: The Stokes V LSD profile (pluses) of the Ap starγ Equ is plotted with the first derivative of its LSD Stokes I profile superimposed (solid line). The level of agreement shows that the weak field approximation (Eqn. 5.6) does indeed hold, at least for the field strengths of a few kG observed on γ Equ. Taken from Donati & Collier Cameron (1997).

the Hussain et al. (2000) code, e.g. the computational demands required to model both stars simultaneously. At the start of this project there were essentially two directions along which we could have proceeded. We could either change the ZDI code of Hussain et al. (2000) to model a binary system, or we could modify the latest version of the DoTS code to perform ZDI. After some consideration it was decided that the latter option would be the most efficient way to progress. The majority of the work was carefully propagating the additional magnetic vectors through many of the (over one hundred) subroutines that make up the DoTS code. The remainder of the work involved testing of the code which we describe in _§5.4.5 and 5.5. What follows is a brief outline of some of the notable changes made to DoTS to make ZDoTS.

DoTS was adapted to read-in and store maps of the three magnetic field orientations (radial, azimuthal and meridional) for both the primary and secondary star. An option was also included to generate synthetic magnetic spots, again for each type of field and each star. The code was also modified to read in separate Stokes V lookup tables, discussed in the last section, for each star. This is in addition to the Stokes I lookup tables which were already being loaded by DoTS. For ZDI we still need the intensity information in order to renormalise the Stokes V data.

At each observational phase (k) the Stokes V specific intensities are summed over the viewplane (described in the last section) for each pixel (i) on both stars in order to compute the total Stokes V contribution (V) to each velocity element (j) in the binary velocity range. This is performed for each field orientation (Hussain 1999):

Djk= X

[V(∆λijk, µik) cosθik(2fi−1)], (5.7) where V(∆λijk, µik) represents the Stokes V specific intensity. This has been calculated using linear interpolation from the lookup tables for the limb angle, µik, and shifted by the instantaneous line-of-sight velocity of the individual pixel, uik, (such that ∆λijk = ∆λj−λ0uik/c). The line-of-sight component for the field orientation is cosθik for image pixeliat phasek. (2fi−1) converts the filling factor stored between 0 and 1 to a number between -1 and 1 where 0 then represents no magnetic flux. This allows cancellation of opposite polarity magnetic regions. Normalisation is achieved using the Stokes I specific intensities for the immaculate stellar discs. Therefore when the two stars are in conjunction the resulting Stokes V spectra is modelled as the sum of all surface elements at that velocity on the viewplane grid.

Storing the specific intensities for both Stokes I and V for each pixel on each star is very expensive on computer memory. This is because the specific intensity profiles must span the entire velocity range of the binary orbit (i.e. they have the same dimension as the viewplane uaxis). Given that the instantaneous contribution from each surface pixel covers a very small range of velocities, this is very wasteful. Furthermore, a ZDI code needs to store all the intensities of all three magnetic vectors (the radial, azimuthal and meridional fields) for each surface element, therefore immediately tripling the memory demand.

The latest version of DoTS includes memory saving compression of arrays imple- mented by John Barnes. In the case of the local Stokes I intensity profiles, DoTS calculates the most ‘common’ value in the profile (the continuum) and stores this number. Then it finds the point where the profile first significantly deviates from this value and stores that index. Similarly, the code then works backwards from the end of the profile to find the index where the last value significantly differs. Therefore only a single value for the contin- uum needs to be stored, along with the indices of the start and end of the non-continuum parts of the profile. In the case of a binary system this represents a huge saving in com- puter memory. Initially it was thought that this would be more difficult to implement for Stokes V profiles due to the fact that they can be positive or negative. However, the fact that the Stokes V continuum generated in the lookup tables has a value of zero (to machine rounding tolerance) allows the same technique as outlined above to be used to compress the local Stokes V profiles. Without compression, to model the stellar surfaces of the HD 155555 binary system (in the next chapters) at a resolution of 2◦ _{per latitude} bin with 50 phases of observation requires in excess of 4 Gb of Random Access Memory (RAM). Given that when we consider differential rotation for HD 155555 (in Chapter 7) we need to model 106 phases, this is clearly not practical. Using the compression described above, however this can be achieved in less than 2 Gb of RAM.