Add in photometric data to minimization process

[bkloppenborg]

SIMTOI should be able to minimize over photometric data in addition to OI data. A proposed implementation method:

1. Add a container object to store arrays of photometric data, along with wavelength information. Generically a [ID, lambda, [(jd, val, err), ..., (jd, val, err)]] would be sufficient.
2. Add new code to the GL widget to permit the number of OI and photometric data sets to be distinguished.
3. Add iterator code to minimization engines to do something like is listed below
4. Add method to open photometric data files and route them to the correct data list.

set model parameters

for data_set in oi_data
    set time
    render models
    get chi | get log Z | get chi_array

for data_set in photometric_data
   for (jd, val, err) in data_set
       set time(jd)
       render_models(lambda)
       get flux
       compute chi | compute log Z

Combine OI and photometric error values and return to the regular minimization code.

[bkloppenborg]

Remember, when liboi simulates the flux, it simply adds up the pixel brightness levels. It does not know anything about the intrinsic brightness. We need to add some normalization information to the data so chi values are computed correctly.

[bkloppenborg]

The above solution is a solution, but I think the following is better. Lets completely abstract away the types of data from the minimizer's knowledge. This way, the minimizer can simply call GetChi() (which would return the error function (x_i - x(theta)) / sigma_i) and a GetError() function (which would return an array of sigma_i's). Then, the minimizer would be responsible for forming its own cost function (i.e. chi-squared, log_evidence).

In this scheme the public functions of the CL_GLThread would be:

GetChi()
GetChi(data_type)
GetChi(data_type, data_id)
GetErrors()
GetErrors(data_type)
GetErrors(data_type, data_id)
ModelAdd(...)
ModelDelete(...)
ModelsSetTime(...)
ModelsSetParams(...)
ModelsRender(framebuffer_target)

The CL_GLThread would probably just be a container object holding the models, data containers (IO, photometric, RV, polarization, etc.) and having exclusive access to OpenGL. The data containers would be responsible for evaluating GetChi according to the data they store. This means they will need to hold their own OpenGL, liboi, and/or other memory objects.

Access to the models will have forced serialization via. a std::recursive_mutex. This way once an object acquires the mutex (say by an externally exposed GetLock function), the object can run OpenGL operations and/or change model parameters without affecting the other objects.

[bkloppenborg]

Completed prior to merge bf007d44e3c7408ddfd5d367e8a28dc53a550fee.