The Structure of Light Curve Programs and the Outlook for the Future

This chapter reflects the authors' views on the structure of future light curve programs. It provides precepts for the structure of generic light curve programs and a preview of the coming decade with the goal of promoting further activities in EB research and light curve program development.

9.1 Structure of a General Light Curve Analysis Program

Nous avons changé tout cela (We have changed all that)

Commercially available hardware and software development packages have reached a quality that they allow the components of the light curve analysis problem to be incorporated efficiently into a stable and user-friendly program. These aspects of any general light curve analysis program (hereafter, GLCAP) include the following.

• the light curve models;

• capabilities of the least-squares solvers; and

• user-friendly front-ends.

Light curve models are most appropriately provided by astronomers. Least-squares solvers could be implemented by some astronomers but more commonly by mathematicians, computer scientists, or others with a keen eye for efficiency, an extensive knowledge of numerical analysis, and programming skills. The development of a front-end typically requires the expertise of software engineers rather than astronomers or mathematicians. Of course, many gifted individuals are capable of fulfilling more than one of these roles.

The three components of any GLCAP need to be linked appropriately. Although such a program does not yet exist, a GLCAP can be expected to emerge in the future. In order to maintain an open structure, it is likely that various experts will need to contribute to the physical model and to the means to achieve mathematical optimization. In such a distribution of labor, a framework and a number of well-defined interfaces will be needed. In the following subsections we suggest how the framework and the interfaces might be structured.

J. Kallrath, E.F. Milone, Eclipsing Binary Stars: Modeling and Analysis, Astronomy and Astrophysics Library, DOI 10.1007/978-1-4419-0699-1-9, © Springer Science+Business Media, LLC 2009

GLCAP itself should consist of several modules and major subroutines:

• module (DETPAR) controlling and invoking least-squares solvers;

• interface (F) to least-squares solvers;

• interface (DF) to compute derivatives required by the least-squares solvers;

• interface (FEI) passing the input from user-friendly front-end to vectors s containing all system parameters and CP, a vector containing all control parameters; and

• interface (FEO) passing the output back to front-end.

9.1.1 Framework of the Light Curve Models

GLCAP may contain several light curve models of different complexity. The analysis of eclipsing binary light curve data may start with a simple model assuming circular orbits and spherical stars. Now, when computer power is not the limiting factor, we might argue that the simple models have almost nothing to offer. Nevertheless, at least for a while, simple models are likely to be used in the context of teaching and by amateur astronomers, but also for deriving initial parameter estimates very quickly. These results can then be used in more realistic models based on Roche geometry. Each light curve model L should be coded in a module LCI which in turn is built up by several submodules. Generically, we will name it LC from now on and describe its structure, input, and output quantities.

The structure of GLCAP and also LC should be modular. That is, it should separate the computation of orbit quantities, component surfaces, radiative physics, eclipse effects, and special effects in modules. Modules are collections of subroutines, are subroutines themselves on a higher level, and they are part of the overall program GLCAP but might be stored in separate files. The computation of line profiles or the computation of the orbit might be considered as a module. Solving Kepler's equation would then be a subroutine in the orbital computation module. LC should not do any file reading or file writing. This task should be carried out by an I/O module. The input to LC would be in the form of multidimensional arrays:

• System parameters could be stored in the vector s containing all system parameters, viz., inclination, mass ratio, etc. There should be a standard mapping, defining, for instance, x1 <—> inclination i, 0° < i < 180°, x2 «—> mass ratio q, q > 0, x3 «—> temperature T1, T1 > 0, of component 1, x4 «—>____

Of course, not all elements of the vector s might be used in subroutine LC. Therefore LC would have a subroutine StoP which would map s to the vector p containing only the parameters needed by LC. This mapping could include scaling transforms as well as other features.

• Control parameters CP containing a variety of control parameters, e.g., specifying the atmospheric model to use, accuracy to stop iterations, etc. The output consists of the set {Lcal, RVcal,...} of light and radial velocity curves, and such other observables as polarization curves, spectral indices of various kinds, or even line profiles.

Telescopes Mastery

Telescopes Mastery

Through this ebook, you are going to learn what you will need to know all about the telescopes that can provide a fun and rewarding hobby for you and your family!

Get My Free Ebook


Post a comment