Project

General

Profile

Meeting (03/25/13)

Participants:

Anne Ealet
Paolo Franzetti
Bianca Garilli
Martin Kuemmel
Julien Zoubian

Simulation : global plane for performances

Challenge for December 2013

  • wide survey simulation: 25deg2
  • deep survey simulation: 1deg2
  • computation time scale: 1 week (on the largest computer we'll get... TBD)

Plane

  • Provide configuration files with cosmic (March)
  • Orientation of the telescope (April)
  • PSF wavelength depend:
    • one zeemax-like PSF (April)
    • decide parametrization for wavelength depend (May)
    • implement (June)
  • Source profile (September)
  • 0 and 2 order (October)
  • Detector noise map (November)
  • PSF: spatial variation if we get enough informations (?)
  • Get more realistic transmission (?)

Further development of aXeSIM

RAM consumption

  • The RAM consumption of the beam simulations itself should be moderate, since the beams are computed serially (disp_util.c/comute_disp()), hence there is only one beam in RAM at a time.
  • If there is too much RAM consumption, then why?
    All direct images are stored, may be too much?
    All high-res spectra are stored, may be too much?

Actions

Parallelization

  • using python packages "multiprocessing" and "Queue" such that every core simulates a single image?
  • using openMP to parallelize via one of the loops e.g. in disp_util.c/comute_disp()?

Issue:

Action

Kahan summation

Action:

PSF variations

  • The PSF should be allowed to vary as a function of different independent variables, such as:
    • x-position
    • y-position
    • wavelength
      Also it should be allowed to give the PSF at a variable pixel scale.
  • A couple of things need to be defined:
    • the variation scheme(s)
    • a format to store the variation scheme in a file
    • an interpolation method to evaluate the PSF at the grism image center.

There are definitely various ways to get this into TIPS.
Also the implementation strategy may critically depend on the inputs and how TIPS is used.
The PSF and its wavelength dependence at the chosen pixel sampling needs to be known at the aXeSIM level.
I would expect the wavelength dependence of the PSF to be rather smooth (need to ask Eric?), which could be expressed as a pixel-wise second order polynomial.
The PSF dependency on the xy space would certainly be more complex, perhaps third order in both, x an y.
However the evaluation of the position dependency needs not to be in the inner grism simulation part of aXeSIM, but could be done in a preparatory step, maybe even outside of aXeSIM in the TIPS/python part.
For extended objects the intrinsic object shape needs to be folded with the actual PSF.
That would then also imply that extended objects are always given with their intrinsic shape.
In total, it should be known whether it is possible to give extended objects always with their intrinsic shape.
Alternatively extended objects could be given with a minimum PSF folded, and then a position dependent broadening could be convolved into the objects.
The way to describe the position dependence may also depend on the knowledge of that variation.
The PSFEx way to map the xy dependency may not be the worst idea, especially since these variations might be measured on the NIS images and then transferred to NISP.

Action

Build system

  • The build system of aXeSIM is now indeed very old and should/could be redone.
    Should a different technique (scons, gmake) be employed?

Action