Add camera sub-class

[Didou09]

Implement camera subclass from Datastock

2 implementation possibilities:

• As a brand new class from DataStock
• Inherited from Plasma2D

The latter makes more sense for inversions, which combine a 2d mesh and a camera, so it makes sense to have everything integrated in the same class => Will be implemented as a subclass of Plasma2D

A camera subclass should go along with an aperture subclass

Thoughts:

• I propose to define a camera a set of an arbitrary number of pixels that share:

  • an identical shape (i.e.: all pixels should be defined by a flat contour, and the contour, taken in pixel centered-coordinates is the same for all pixels)
  • a common set of apertures
  • a common set of other optical systems (i.e: CrystalBragg)

• A camera can be of type:

  • 2d (all pixels stand in the same plane, forming a 2d ordered arrangement, a grid), typically represents a real-life 2d camera (e.g.: PILATUS)
  • 1d (arbitrary non-ordered arrangement), typically represents any set of diodes belonging to the same diagnostic, used for tomography for example.

The main reason for this distinction is that the user will want to plot the signal as 2d images for a 2d camera, and a curve vs pixel/diode index for any other arrangement.

• A camera can be associated with any number of aperture instances, they can represent slits, holes between PFCs...
• A unique CrystalBragg can be associated to a camera

The main addition of camera and aperture with respect to more simple LOS-approximation is that we will start computing Etendues and throughput, taking into account finite beam width...

@cjperks7, @adriendaros, I will implement this, but please feel free to comment according to your needs and thoughts

[cjperks7]

Hey Didier, my immediate thought would be including quantum efficiency vs. photon energy/response functions. Something to think about is would these curves be stored in the code (i.e. for common detectors like PILATUS2/3) or would the user need to supply these.

Something that I've been thinking about more relevant down the line for SPARC's XRAY is using the tomography in Tofu for measured data. I don't know if you're already doing something like this for WEST's XICS system. Figured it would be easiest to stick with. From my experience with the code that processes C-Mod's XICS system data, you need to deal with removing dead pixels and have to be aware of poor relative calibration between submodules on a detector. These may be features you'd want to keep in mind. (btw you asked about basis for the inversions in this code before and it's the standard pixels/voxels)

[Didou09]

Thanks @cjperks7 ! => will include quantum efficiency, per pixel, as a tabulated curve to be provided by the user (default ones will be available from tofu). => We already have a complete data treatment for XICS data on WEST, which is almost entirely available in tofu, @adriendaros is currently learning how to use it, but in a nutshel, it: - allows to define a minimum Signal / Noise threshold to filer-out irrelevant pixels - mask any arbitrary groups of pixels out - allows to define a minimum fraction of relevant pixels for a spectrum (i.e.: horizontal line of pixels) to be valid - allows to fit a multi-gaussian spectrum with exponential bremmsstrhalung and with multiple constraints (e.g.: same shared width for all lines or define groups of shared width, or amplitude, or shift...) - automatically perform a 2d fit of the whole image

I don't think we'll have to deal with poor relative calibration between module because modern PILATUS detectors are integrated as all-in-one detectors which I think was not the case for ALCATOR (where individual separated modules were used). But I'll keep your advice in mind in case it turns out necessary.