MAGIC effective focal length

[maxnoe]

Originally posted by @orelgueta in https://github.com/cta-observatory/lst-sim-config/issues/20#issuecomment-1055409017

The effective focal length is not necessary for the simulations, you can simulate without it. It was added as an input parameter in order to be in the output simulation file for the analysis later (as I am sure you remember @maxnoe).

However, it is quite useful to have, so I suggest you add it. I used your MAGIC 1 config file and the gammasim-tools package to run a quick ray-tracing simulation and derive the effective focal area of MAGIC 1 (I assume it's the same for MAGIC 2). The results I got are in the plot below and the attached ECSV file (the eff_flen column is the relevant one).

The average effective focal length I got is 1720.6 cm. Based on the focal length you set in the config file, it seems to be in the right ball park. I am sure MAGIC experts can say for sure.

By the way, the comment next to the focal length in the config file says that that is the effective one, is that true? If so, then my calculation is not correct and that parameter should be changed to the nominal focal length rather than the effective one.

ray-tracing-North-LST--d10.0-za20.0_validate_optics.txt

[jsitarek]

Hi @orelgueta, @maxnoe @moralejo

The focal length of MAGIC should be indeed 1697 (i.e. the telescopes are designed for 17m, but since they are focused not to infinity but to 10km height there is 3 cm difference, I hope it goes in the correct direction EDIT: I checked in reflector and the files say 1697 so should be fine).

In MARS analysis we use a factor of 1.0713 to correct for the average shift of the images due to (coma) aberration, I think it is exactly the same factor, so effective_focal_length = 1818.0 which is however much larger than what Orel got

[moralejo]

Indeed, 1721 / 1697 is just 1.014 MAGIC has f/D = 1 so the aberration must be larger than for LST, which has f/D ~ 1.22. For LST Konrad had calculated an effective / nominal ratio of 1.047, so for LST it indeed has to be way larger than 1721 cm

[orelgueta]

Indeed something in the calculation went wrong. sim_telarray also assumes internally an effective focal length of 1828.29:

Internally assumed effective focal length is 1828.29 cm for an approximate f/d of 0.984 based on nominal focal length of 1697.000000 cm and diameter 1718.5 to 1862.0 (-> 1725.1) cm.

I will check what went wrong and report back, but anyway you should simply set the effective_focal_length parameter to the one you use in the MARS analysis so it is available in the output simulation files.

The focal length of MAGIC should be indeed 1697 (i.e. the telescopes are designed for 17m, but since they are focused not to infinity but to 10km height there is 3 cm difference, I hope it goes in the correct direction EDIT: I checked in reflector and the files say 1697 so should be fine).

You should actually set the focal length to the design value of 17m and then add the focus offset to the focus_offset parameter. In fact, that is already done, you set the focus_offset to 2.93 cm

focus_offset = 2.93 % 1./(1./1697.-1./10.e5) - 1697. (focusing at 10 km distance)

so I suggest you change the focal_length and the dish_shape_length to 17m.

[jsitarek]

there is something strange in this formula, 1./(1./1697.-1./10.e5) - 1697. gives 2.88 and not 2.93, and either way it should use 1700, so 2.89. I will correct those. Those values will affect slightly the PSF, but hopefully the effect will not be very strong

EDIT: for effective one I will also use a bit larger number i.e. 1700.*1.0713 = 1821.2.

[jsitarek]

I checked the effect on the PSF matching, there is hardly any effect at all, so there is no need to retune the numbers at the moment since the PR is also merged I'm closing the issue

[maxnoe]

Is it understood why the values calculated by @orelgueta using the ray tracing were off?

[orelgueta]

Yes and no. We realised that in our simulations, as the image from the star moves with the off-axis angle, it does not move along the x axis as we expected. It also shifts along the y axis. When we originally calculated the effective focal length, we only looked at the distance along the x-axis, which resulted in an underestimation of the effective focal length. When we calculate the effective focal length using the radial distance instead, we get the expected result.

The problem is, we don't know why this shift along the y axis happens. We are investigating it now. It happens with LST and MST-NectarCam, but not with FlashCam (which is quite strange since the camera is not actually used in the simulation).

I will definitely report back here once we are sure what the reason is.

[maxnoe]

The problem is, we don't know why this shift along the y axis happens. We are investigating it now. It happens with LST and MST-NectarCam, but not with FlashCam (which is quite strange since the camera is not actually used in the simulation).

A difference that comes to mind is that NectarCam and LSTCam have a camera / pixel rotation value, FlashCam does not. Might this be related?

[orelgueta]

Yeah, that was (is?) my guess, but the pixels are not supposed to be used anywhere in the simulation, so it shouldn't be the cause.

[jsitarek]

just a wild guess, but maybe some mess with the transformation of the azimuth angles between the different coordinate systems? The difference was actually very large, so I think the spot must have moved more in the Y direction than in X, if you do compute the shifts in both direction and make an atan of them what angle do you get? Maybe it will tell us from where it comes from

[orelgueta]

An issue with the transformation would be strange because then it would happen with all telescopes, not just some of them.

The shift in the y direction wasn't larger than in x (see image below for LST). The other issue is that Konrad's simulations and ours do not yield exactly the same result, so the first thing to do is to figure that out. I must say this issue is a somewhat of a lower priority right now though. We will definitely get to the bottom of it before we start any actual productions, but it might wait a couple of weeks before we look at it more seriously.

[maxnoe]

Looking at that image: Is the focal length calculated from the center of that circle? If yes: is that really more correct?

[orelgueta]

No it isn't. The circle is the D80. The effective focal length is calculated from centroid (mean of all photons along an axis).

[orelgueta]

The issue was indeed the rotation of the camera in LST, NectarCam and MAGIC. It wasn't expected because the pixels are not used in the simulation, but apparently their coordinate system is used (without taking care to rotate it). This issue was never seen and wasn't a worry because usually ray-tracing simulations are done with a dummy single-pixel camera. We used the full camera this time and ran into an unexpected issue. In the future, the rotation will be taken into account also for ray-tracing simulations as well.

Going back to the MAGIC calculation, the effective focal length as a function of off-axis angle is shown in the plot below. A more reasonable average value of 1829.1 cm is derived now. It's probably not worth changing the value Julian set, but for completeness I figured I will post this update.

[kbernloehr]

Just a bit of an explanation of the apparent rotation: The IMAGING_LIST file entries are always in the pixel coordinate reference frame, that is as given in the CAMERA_CONFIG_FILE, where the pixels have their native shapes and checking for proper pixel hits is more straight-forward. Now the camera should not matter for the purpose here - after all we want to compare with a CCD camera looking onto a passive screen or such. For that reason, and because I wanted to include SCT ray-tracing without compiling a version for that man pixels, my PSF ray-tracing usually sets a dummy 1-pixel camera, with no rotation. Now, sim_telarray includes the rotation angle with the generated file and an up-to-date 'rx.cc' compensates for the rotation in calculating image centroids and r.m.s. values of the PSF in (camera reference-frame) x/y.

When actually using the camera pixels, including detection efficiency, beware of gaps between pixels. For the SST, for example, there are module gaps right along the x and y axes. An attempt to calculate the PSF with full camera efficiency, a worthwhile effort because of all the angular dependence of the camera window etc., suffers from a large fraction of the light falling into the gap and only the tails of the PSF getting into any pixels.