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)
- 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¶
- 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?
- Serial (and multiple) access to the spectra and the images [Martin]
- To be explore if needed: reduce the number of spectra in focusing only on the science sources.
Other sources (background) would be define with a template, redshift and magnitude. [Julien]
- 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()?
- for parallelization in python see test with pp:
- Parallelize the c code with openmpi [Julien]
- Maybe using Kahan summation (http://en.wikipedia.org/wiki/Kahan_summation_algorithm) when the beam contributions to the pixels in the slitless image in order to avoid numerical errors.
Should not be too complicated to implement.
- Check if it is difficult to implement [Martin]
- The PSF should be allowed to vary as a function of different independent variables, such as:
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.
- oversampled PSF [Martin]
- convolution source model [Martin]
- TIPS: manage source model [Julien]
- The build system of aXeSIM is now indeed very old and should/could be redone.
Should a different technique (scons, gmake) be employed?
- dipsutils? [Julien]