cta-observatory / lst-sim-config

Repository to store configurations of MC simulations for LST (+MAGIC)
0 stars 1 forks source link

fixed some of the default parameters of MAGIC that were also overwritten by LST #38

Closed jsitarek closed 2 years ago

jsitarek commented 2 years ago

the new values are actually different than both the default and the LST values. The changed things are the camera shape (most probably not used at all, this is only used for ray tracing), pedestal variability and FADC gain variations (both things are not simulated in the standard MAGIC simulations) Also added input cards for the calibration laser to simulate MAGIC-like flatfielding events (not enabled by default)

orelgueta commented 2 years ago

the camera shape (most probably not used at all, this is only used for ray tracing)

Excuse me for jumping in again, but the camera shape, it's diameter and depth are used for shadowing also in normal simulations, not just in ray tracing. This means that the telescope transmission factor/function should include all shadowing from the structure, except the one from the camera. Please see section 5 in this document for details on how it is done for MST.

You can choose not to include the camera body explicitly in the simulation and add all shadowing to the telescope transmission function/factor, but in that case you should set the camera body diameter/depth to zero in order to avoid double counting.

jsitarek commented 2 years ago

thank you @orelgueta ! Since we do not include shadowing in our standard MAGIC simulations I set it to 0 also here. The difference is ~1 - 1.5%, one more of the small factors to lower the 30% mismatch :-).

orelgueta commented 2 years ago

Does this mean the telescope_transmission factor of 0.61 includes the shadowing from the camera? Or do you not want to include camera shadowing at all in order to get a better agreement with MagicSoft?

I am asking cause I want to know what we should do in our MAGIC simulations in Prod6.

jsitarek commented 2 years ago

Hi @orelgueta, telescope_transmission value was optimized with muons in MagicSoft chain, and since there is no actual shadowing computed there, all the actual shadowing goes into the telescope_transmission value automatically. In general I think whatever settings we converge on in this repository you can use by the way, in Prod6 will you have some default file for TELESCOPE 0 ? I think in Prod5 the settings for LST were loaded by default to all the telescopes. We had quite some problems with this, as not all the settings were overwritten for MAGIC. We will need to check that all the settings in the default file are acknowledged (either as correct, or not important, or modified) in the MAGIC simulations

orelgueta commented 2 years ago

OK, then we will set the camera diameter to zero for Prod6 as well.

Regarding the default values. We had issues with it before, but only when the software setup process was interrupted (connection issues on the grid) and the default LST values were taken for some of the telescopes. If everything works, this shouldn't happen. Anyway, Konrad added explicit default values for Prod6. You can see his setup in a file called CTA-PROD6-common.cfg. Unfortunately I cannot send you a direct link to it, but you can look at it easily if you download the latest testing version and extract the sim_telarray_config.tar.gz file.

kbernloehr commented 2 years ago

It seems that the telescope_transmission parameter is attempted to deal with two effects: a) the incomplete shadowing in sim_telarray b) the mirrors degrading over time Usually, the two parts are handled separately by 1) Using telescope_transmission for the ratio of geometric mirror area obtained from some code with complete shadowing over the (slightly larger) mirror area obtained with the incomplete sim_telarray shadowing. This part should not vary over time. 2) The mirrors degrading over time are best handled by the mirror_degraded_reflection parameter. If you have extra information on changes in the camera (window, light cones), that could go into camera_degraded_efficiency. Degradation determined from muon rings alone would usually mean to keep camera_degraded_efficiency=1.0 and put all the measured degradation into mirror_degraded_reflection. Flat-field events (LASER_EVENTS internal to sim_telarray or ff-1m generated events processed with BYPASS_OPTICS=1 (or 2) would only see the camera degradation factor but simulated muons would be affected by the product of mirror and camera degradation factors. That product also applies to the effective NSB pixel p.e. rate. If I am not mistaken, the telescope_transmission factor (the overall factor, independent of incidence angle) is not applied to the NSB pixel p.e. rates. Since the NSB rate drop over the FoV (mainly affecting 2M telescopes) includes effects of shadowing handled explicitely by sim_telarray and the extra effects only covered by the further telescope_transmission parameters (assuming the second parameter is 1), there is another parameter set (nsb_offaxis) to describe the combined effect (unless you want to set each pixel individually). To make the long story short: you can continue using telescope_transmission only, but the recommendation would be to split the factor into a ray-tracing-geometry factor and a degradation factor - where an equal product of the two factors should result in equal muon-ring intensity but not in equal effective NSB pixel p.e. rates.

jsitarek commented 2 years ago

thank you @kbernloehr for detailed explanations. the purpose at the moment is to be able to match the parameters between our standard MagicSoft chain and the sim_telarray simulations. We are still seeing some differences there and double checking everything, therefore at the moment it is best to keep it as simple as possible. Once we get the match we could then easily translate the paramters from different MAGIC analysis periods into sim_telarray language. We can then of course start exploiting the extra parameters in sim_telarray to separate the effects, but keeping the same net effect on the MCs.

jsitarek commented 2 years ago

I would like that we merge this PR, please let me know if somebody is against.