Projet

Général

Profil

YoGA Ao features » Historique » Version 13

Julien Brule, 18/06/2012 15:16

1 1 Julien Brule
h1. YoGA Ao features
2
3
The YoGA_Ao library contains routines to simulate the whole process of image formation through the atmosphere, a telescope and an adaptive optics (AO) system. Following [[ the YoGA Philosophy ]]  YoGA_Ao is designed around a double-sided API: a Yorick API (called hereafter high-level routines) and CUDA-C API accessible to the interpreter through Yorick wrappers (called hereafter advanced routines).
4
5
There are two ways to use YoGA_Ao, either through the GUI or through the command line possibly using predefined scripts. The following description is valid for both ways but is probably more relevant to command line users. The main difference between the GUI and the command line interface is the way the simulation parameters are imported. In the latter case, the simulation parameters are centralized into a parameter file (.par). Examples of .par files are given in the data/par directory and can be used as templates. The high-level API contains a dedicated routine to read the parameters from this file and import them in the simulation environment.
6
7 12 Julien Brule
[[YoGA Ao features#List-of-features|List of features]]
8 13 Julien Brule
* [[YoGA Ao features#Simulation-geometry|Simulation geometry]]
9
* [[YoGA Ao features#Turbulence-generation|Turbulence generation]]
10
* [[YoGA Ao features#Wavefront-Sensing|Wavefront Sensing]]
11
* [[YoGA Ao features#Image-formation|Image formation]]
12 12 Julien Brule
[[YoGA Ao features#List-of-routines|List of routines]]
13 13 Julien Brule
*[[YoGA Ao features#High-level-routines|High-level routines]]
14
*[[YoGA Ao features#Advanced-routines|Advanced routines]]
15 1 Julien Brule
16
h2. List of features
17 4 Julien Brule
18
Each API comes with a set of structures concentrating the configuration parameters for the simulation as well as various data used for computation and diagnostics. For the Yorick API, the list of structures can be found in the file yoga_ao_ystruct.i. Concerning the CUDA-C API, please refer to the file yoga_ao.cpp. Available features include:
19
20
* Kolmogorov-type turbulence generation over an arbitrary number of layers with arbitrary properties.
21
* Shack-Hartmann wavefront sensing including Laser Guide Stars (LGS)
22
* Short and long exposure imaging under the turbulence
23
24
h3. Simulation geometry
25
26 6 Julien Brule
The main parameter that drives most of the choices for the simulation geometry is the Fried parameter r0. Typically, for an adequate sampling, the equivalent size of the pixels we use to simulate the turbulent phase screens should be less than half r0. To ensure a good sampling, in YoGA_Ao, r0 is simulated on about 6 pixels. This ratio defines the size of the "quantum" pixels and thus the size of the phase screens to simulate (as compared to the telescope size). From this screen size, the full images size is defined, taking into account the sampling required for imaging.
27 4 Julien Brule
28
As an example, in the case of an ELT, the linear size of the phase screen support (and thus of the pupil) is of the order of 1.5k to 2k pixels. This means that the linear size of the image will be at least 4k (for a minimum Shannon sampling). This is a very large number which will imply heavy computations.
29
30
To cope for these various requirements we can define 3 different pupils: 
31
32
* the large pupil (called ipupil) defined on the largest support (4kx4k in our previous example) more than half of which being 0
33
34
* the small pupil (spupil) defined only on the pupil size (2kx2k in our previous example) most of it being 1
35
36
* the medium pupil (mpupil) defined on a slightly larger support: typically 4 additional pixels as a guard band on each size. This guard band is useful for manipulations on phase screens like raytracing. This is also the actual size of the ground layer phase screen.
37
38
The image below helps to understand the various pupil sizes. White is the pupil, green is the support of spupil, blue the support of mpupil et black the support of ipupil.
39
40 6 Julien Brule
!https://dev-lesia.obspm.fr/projets/attachments/download/570/pupil.png!
41 1 Julien Brule
42 6 Julien Brule
All these pupils are contained in arrays accessible as internal keywords of the following geom structure available from the Yorick API : 
43
44
<pre>
45
<code class="c">
46
struct geom_struct
47
{
48
   long  ssize;       // linear size of full image (in pixels)
49
   float zenithangle; // observations zenith angle (in deg)
50
   // internal keywords
51
   long  pupdiam;     // linear size of total pupil (in pixels)
52
   float cent;        // central point of the simulation
53
   pointer _ipupil;   // total pupil (include full guard band)
54
   pointer _mpupil;   // medium pupil (part of the guard band)
55
   pointer _spupil;   // small pupil (without guard band)
56
   ...
57
};
58
59
</code>
60
</pre>
61
62
some keywords have not been reported. Please check yoga_ao_ystruct.i for more details.
63
64
In this structure pupdiam (the diameter in pixels of the pupil is considered as an internal keyword). Two other structures contain the rest of the configuration parameters : 
65
66
<pre>
67
<code class="c">
68
struct tel_struct
69
{
70
    float diam;        // telescope diameter (in meters)
71
    float cobs;        // central obstruction ratio
72
};
73
</code>
74
</pre>
75
76
<pre>
77
<code class="c">
78
struct loop_struct
79
{
80
    long  niter;      // number of iterations
81
    float ittime;     // iteration time (in sec)
82
};
83
</code>
84
</pre>
85
86
There is one high-level routines to init the geometry with only one parameter: the pupil diameter in pixels. 
87
88
<pre>
89
<code class="c">
90
func geom_init(pupdiam)
91
    /* DOCUMENT geom_init
92
      geom_init,pupdiam
93
      inits simulation geometry, depending on pupdiam
94
      the linear number of pixels in the pupil
95
    */
96
97
</code>
98
</pre>
99
100
101
102
103
104 1 Julien Brule
h3. Turbulence generation
105 6 Julien Brule
106 7 Julien Brule
The turbulence generation is done through the process of extruding infinite ribbons of Kolmogorov turbulence (see [[Model Description]]). An arbitrary number of turbulent layers can be defined at various altitude and various fraction of r0, wind speed and directions (in the range 0°-90°).
107
108 6 Julien Brule
<pre>
109
<code class="c">
110 7 Julien Brule
struct atmos_struct
111
{
112
    long    nscreens;    // number of turbulent layers
113
    float   r0;          // global r0 @ 0.5µm
114
    float   pupixsize;   // pupil piwel size (in meters)
115
    pointer dim_screens; // linear size of phase screens
116
    pointer alt;         // altitudes of each layer
117
    pointer winddir;     // wind directions of each layer
118
    pointer windspeed;   // wind speeds of each layer
119
    pointer frac;        // fraction of r0 for each layer
120
    pointer deltax;      // x translation speed (in pix / iteration) for each layer
121
    pointer deltay;      // y translation speed (in pix / iteration) for each layer
122
};
123
124
125 6 Julien Brule
</code>
126
</pre>
127
128 7 Julien Brule
The phase screens size is computed in agreement with the system components. The positions of the various targets (imaging targets or wavefront sensing guide stars) in the simulation define the required field of view and thus the size of the altitude phase screens.
129 6 Julien Brule
130 7 Julien Brule
To create a dynamic turbulence, the phase screens are extruded in columns and rows. The number of rows and columns extruded per iteration is computed using the specified wind speed and direction. Because extrusion is an integer operation (can't extrude a portion of a column), additional interpolation is required to provide an accurate model (with non integer phase shifts). In YoGA_Ao, a combination of integer extrusion and linear interpolation (in between four pixels) is used for each layer. The phase is integrated along specified directions across the multiple layers with the positions of light rays being re-evaluated for each iteration and screen ribbons being extruded when appropriate. This explains the need for a guard band around the ground layer phase screen as light rays can partly cross the pupil pixels depending on the iteration number.
131
132
The overall turbulence generation is done on the GPU and rely on a C++ class:
133
134
135 6 Julien Brule
<pre>
136
<code class="c">
137 7 Julien Brule
class yoga_tscreen
138 6 Julien Brule
</code>
139
</pre>
140
141 7 Julien Brule
This object contains all the elements to generate an infinite length phase screen including the extrusion method. All the screens for a given atmospheric configuration are centralized in another class:
142 6 Julien Brule
143 7 Julien Brule
144
145 6 Julien Brule
<pre>
146
<code class="c">
147 7 Julien Brule
class yoga_atmos
148
149 6 Julien Brule
</code>
150
</pre>
151
152 7 Julien Brule
In this object phase screens can be added dynamically thanks to the use of a map of yoga_tscreen This has many advantages the first of which being the indexation: screens are indexed by altitude (float) and the use of iterators greatly simplifies the code.
153
154
The corresponding Yorick opaque object is: 
155
156 6 Julien Brule
<pre>
157
<code class="c">
158 7 Julien Brule
 static y_userobj_t yAtmos
159 6 Julien Brule
</code>
160
</pre>
161
162 7 Julien Brule
and there are several Yorick wrappers to manipulate this object:
163
164 6 Julien Brule
<pre>
165
<code class="c">
166 7 Julien Brule
extern yoga_atmos;
167
    /* DOCUMENT yoga_atmos
168
       obj = yoga_atmos(nscreens,r0,size,size2,alt,wspeed,wdir,deltax,deltay,pupil[,ndevice])
169
       creates an yAtmos object on the gpu
170
    */
171 6 Julien Brule
</code>
172
</pre>
173
174
175
<pre>
176
<code class="c">
177 7 Julien Brule
extern init_tscreen;
178
    /* DOCUMENT init_tscreen
179
       init_tscreen,yoga_atmos_obj,altitude,a,b,istencilx,istencily,seed
180
       loads on the gpu in an yAtmos object and for a given screen data needed for extrude
181
    */
182 6 Julien Brule
</code>
183
</pre>
184
185
186
<pre>
187
<code class="c">
188 7 Julien Brule
extern get_tscreen;
189
    /* DOCUMENT get_tscreen
190
       screen = get_tscreen(yoga_atmos_obj,altitude)
191
       returns the screen in an yAtmos object and for a given altitude
192
    */
193 6 Julien Brule
</code>
194
</pre>
195
196
<pre>
197
<code class="c">
198 7 Julien Brule
extern get_tscreen_update;
199
    /* DOCUMENT get_tscreen_update
200
       vect = get_tscreen_update(yoga_atmos_obj,altitude)
201
       returns only the update vector in an yAtmos object and for a given altitude
202
    */
203 6 Julien Brule
</code>
204
</pre>
205
206
<pre>
207
<code class="c">
208 7 Julien Brule
extern extrude_tscreen;
209
    /* DOCUMENT extrude_tscreen
210
       extrude_tscreen,yoga_atmos_obj,altitude[,dir]
211
       executes one col / row screen extrusion for a given altitude in an yAtmos object 
212
    */
213 6 Julien Brule
</code>
214
</pre>
215
216
217 7 Julien Brule
Additionally there is a high-level routine to initialize the whole structure on the GPU from Yorick:
218 6 Julien Brule
219 7 Julien Brule
<pre>
220
<code class="c">
221
func atmos_init(void)
222
    /* DOCUMENT atmos_init
223
       atmos_init
224
       inits a yAtmos object on the gpu
225
       no input parameters
226
       requires 2 externals + 2 optional : y_atmos and y_geom + y_target and y_wfs
227
       y_atmos  : a y_struct for the atmosphere
228
       y_geom   : a y_struct for the geometry of the simulation
229
       y_target : a y_struct for the targets
230
       y_wfs    : a y_struct for the sensors
231
       creates 1 external :
232
       g_atmos : a yAtmos object on the gpu
233
    */
234 6 Julien Brule
235 7 Julien Brule
</code>
236
</pre>
237 6 Julien Brule
238
239
240
241 1 Julien Brule
h3. Wavefront Sensing
242 6 Julien Brule
243 7 Julien Brule
Wavefront sensing is done in two steps: first compute the Shack-Hartmann sub-images including diffraction effect and noise and then from these images, compute the centroids. The overall model is described here [[Model Description]].
244 6 Julien Brule
245 7 Julien Brule
The pixel size requested by the user for the sub-apertures images are approximated following a rather robust approach to cope for any kind of dimensioning. We used an empirical coefficient to set the simulated subaps field of view (FoV) to 6 times the ratio of the observing wavelength over r_0 at this wavelength. This provides sufficient FoV to include most of the turbulent speckles. The same empirical coefficient is used to define de number of phase points per subaps as 6 times the ratio of the subaps diameter over r_0. This ensures a proper sampling of r_0. From this number of phase points we compute the size of the support in the Fourier domain. The "quantum pixel size" is then deduced from the ratio of the wavelength over r_0 over the size of the Fourier support. Then the pixel size actually simulated is obtained using the product of an integer number by this quantum pixel size as close as possible to the requested pixel size.
246
247
The wavefront sensor model description is stored in the following Yorick structure. 
248
249 6 Julien Brule
<pre>
250
<code class="c">
251 7 Julien Brule
struct wfs_struct
252
{
253
  long  nxsub;          // linear number of subaps
254
  long  npix;           // number of pixels per subap
255
  float pixsize;        // pixel size (in arcsec) for a subap
256
  float lambda;         // observation wavelength (in µm) for a subap
257
  float optthroughput;  // wfs global throughput
258
  float fracsub;        // minimal illumination fraction for valid subaps
259
  
260
  //target kwrd
261
  float xpos;      // guide star x position on sky (in arcsec) 
262
  float ypos;      // guide star x position on sky (in arcsec) 
263
  float gsalt;     // altitude of guide star (in m) 0 if ngs 
264
  float gsmag;     // magnitude of guide star
265
  float zerop;     // detector zero point
266
  
267
  // lgs only
268
  float lgsreturnperwatt;  // return per watt factor (high season : 10 ph/cm2/s/W)
269
  float laserpower;        // laser power in W
270
  float lltx;              // x position (in meters) of llt
271
  float llty;              // y position (in meters) of llt
272
  string proftype;         // type of sodium profile "gauss", "exp", etc ...
273
  float beamsize;          // laser beam fwhm on-sky (in arcsec)
274
...
275
};
276
277 6 Julien Brule
</code>
278
</pre>
279
280
281
282 1 Julien Brule
h3. Image formation
283
284 6 Julien Brule
<pre>
285
<code class="c">
286 7 Julien Brule
struct target_struct
287
{
288
  long    ntargets;  // number of targets
289
  pointer lambda;    // observation wavelength for each target
290
  pointer xpos;      // x positions on sky (in arcsec) for each target
291
  pointer ypos;      // y positions on sky (in arcsec) for each target
292
  pointer mag;       // magnitude for each target
293
};
294 6 Julien Brule
</code>
295
</pre>
296
297
298
299
300
301 4 Julien Brule
h2. List of routines
302 8 Julien Brule
303 1 Julien Brule
h3. High-level routines
304 8 Julien Brule
305 1 Julien Brule
h3. Advanced routines
306 6 Julien Brule
307
308
<pre>
309
<code class="c">
310 7 Julien Brule
extern _GetMaxGflopsDeviceId  //get the ID of the best CUDA-capable device on your system
311 6 Julien Brule
</code>
312
</pre>