cta-observatory / lst-sim-config

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

First cleaning pass for LST-MAGIC-PROD2 config #20

Closed mexanick closed 2 years ago

mexanick commented 2 years ago

@voutsi can you please try a dummy run with this configuation. Note: entry point for sim_runner changed to array.cfg

jsitarek commented 2 years ago

Hi @mexanick,

I have some technical problem with the review, so let me write the comments directly here. I think the idea about the cleaning of the input cards was to remove the PROD tags, but not the whole name. For example you renamed ref_LST_2020-04-23.dat to mirror_reflectivity.dat, which I think is somewhat confusing, because the file name does not say if this is for LST1 or MAGIC. In addition this file already exists in sim_telarray, so I think it is best to keep using this name (unless something was changed in the file).

similarly with the file: transmission_lst_window_No7-10_ave.dat

there is still some configuration repeated between (CTA-PROD4)-pmt.cfg and LST1.cfg, e.g. discriminator_pulse_shape

Voutsi commented 2 years ago

Hi @mexanick ,

I submitted few jobs, they run smoothly. Only issue is that I cannot set the same observation level as in Corsika (2199m). Sim_telarray looks for the file atmtrans$(OBS_LEVEL)_1_3_0_0_0.dat We have in our configuration the file atm_trans_2158_1_3_0_0_0.dat, so I sent these test jobs with obs. level 2158. Does anyone know where to find or create this file? Else we should probably contact Konrad or some other expert.

maxnoe commented 2 years ago

I think you can just rename the file, there shouldn't be a any difference on the last 50m, especially since it is included in the range and the actual position of LST and MAGIC did not change, just the reference observation level.

moralejo commented 2 years ago

I think you can just rename the file, there shouldn't be a any difference on the last 50m, especially since it is included in the range and the actual position of LST and MAGIC did not change, just the reference observation level

But it would be misleading to rename the file, if it is calculated for 2158 m. Why not obtain the one for the new reference altitude? (closer to the actual telescopes' altitude)

jsitarek commented 2 years ago

I think you can also specify the absorpion file directly in the command line of sim_telarray: -C atmospheric_transmission=... @maxnoe while I also think there is little difference in the absorption at the last 50 m, I do not think the actual telescope position is taken into account when computing the absorption in sim_telarray

mexanick commented 2 years ago

ok, I can revert the reflectivity file name back, however I don't like it to be attached by name to a certain telescope (being MAGIC or LST) and would rather have a telescope position in the name, according to the position in the array (i.e. for LST1 + MAGIC1 + MAGIC2 these three files could be mirror_reflectivity_tel{1,2,3}. What do y'all think?

mexanick commented 2 years ago

considering command-line passing of parameters: it can be done, but I'm strongly in favor of placing all static parameters in the configuration files for a better traceability. Without that one should keep not just the config files but also exact commands given to launch the simulation in order to be able to reproduce it.

jsitarek commented 2 years ago

Hi @mexanick

If it is just this github project the naming _tel[123] would be fine, but I can imagine that the settings from this LST production will get later on in general CTA productions, and possibly be also copied into the sim_telarray directories. And for this reason I would strongly recommend not to change the file names already present in sim_telarray.

About the -C option, sure I agree with you, it is better to keep all the settings in the config files (and normally those optioncs can be specified either via config file or via command-line) . I've just meant that there is a specific option that can be overwritten. There is also a consistency check in sim_telarray that the array altitude and the transmission file are consistent, this might need to overriding.

The cleanest solution is of course to have the absorption model for the same height. From the information in the file it seems that they are made with MODTRAN code, but I do not know who was generating them. If somebody produces the new file I can also make a quick check comparing with the old altitude model using those test files that I did for MAGIC telescopes model.

jsitarek commented 2 years ago

Hi @mexanick,

any update on this naming? @moralejo said today during the MAGIC+LST1 call that he wants to start the sim_telarray still this week.

Voutsi commented 2 years ago

Hi @mexanick,

any update on this naming? @moralejo said today during the MAGIC+LST1 call that he wants to start the sim_telarray still this week. Hi,

@mexanick is not around this week. Apart of the naming, did we converge on the atmospheric absorption file? In the meanwhile, if we don't start with sim_telarray today or tomorrow, the corsika production of all 19 grid points very probably could be finished this weekend.

mexanick commented 2 years ago

Ok, I've retrofitted _LST suffixes to the file names to reflect they belong to LST configurations. Details of the relevant configurations are in the comment section in each corresponding file. The merging conflicts are also resolved. If there's no objection, this can be merged and tagged for the test production

moralejo commented 2 years ago

Hi @Voutsi, regarding the absorption file, @jsitarek will contact Konrad to find out how to proceed.

mexanick commented 2 years ago

Hi @moralejo , @Voutsi , at the moment the absorption file is sourced from the main sim_telarray distribution and is not present here. I think for the intermediate test we can tag (with corresponding release note) and run as is, if there's no other objections on the configuration content. Then, as you said above, we will probably find some other issues to fix and will just produce a new tag where we will include the new absorption file. If this sounds ok to everyone, please approve the PR and we will proceed.

mexanick commented 2 years ago

@moralejo @maxnoe if no objection, I will merge this PR at 14:30 CET

moralejo commented 2 years ago

@moralejo @maxnoe if no objection, I will merge this PR at 14:30 CET

Please go ahead, apologies for the late reaction. #23 can be addressed in another PR, right?

Voutsi commented 2 years ago

Thanks, I will start the sim_telarray simulation of the proton samples for zd < 30 setting only the command-line parameters below:

[sim_telarray.preprocessor]
NUM_TELESCOPES = 3
NO_STEREO_TRIGGER = 1
power_law = 2.68

[sim_telarray.telescope]
telescope_phi = 180.000
telescope_zenith_angle = 6.000 # commonly named θ

[sim_telarray.global_parameters] altitude = 2199 random_state = 'auto' show = 'all' # Show all parameters at the beginning of each job

moralejo commented 2 years ago

Hi @voutsi, please wait, have you checked #23 ? Sorry for that late change, but we only learnt about that this morning.

Voutsi commented 2 years ago

Sorry, I hadn't checked, I will wait then

moralejo commented 2 years ago

Hi, can you do the change suggested there? It is simply to modify the value of telescope_transmission and add the mirror_degraded_reflection parameter

mexanick commented 2 years ago

@Voutsi You can do this change easily and issue a new, 1.1 tag/release Also, please put show = 'all' as a first of the global parameters. This is important to reflect the changes in the printout

Voutsi commented 2 years ago

@mexanick , @moralejo 1) Sure I can make the change proposed at #23. 2) show = 'all' : I was under the impression it should go last. I will try verify it.

Voutsi commented 2 years ago

Hi, I have started the simulations. The simulations are running but there few warnings that might require attention

  1. home/georgios.voutsinas/ws/AllSky/run_directory/sim_runner/tmp/MAGIC1.cfg (67): Could not include file 'CTA-PROD4-pmt_MAGIC1_test.cfg'.

  2. An effective focal length of 2930.565000 cm for a nominal focal length of 1697.000000 cm is not plausible. Reset to zero. This affects the MAGIC telescopes.

  3. Concerning again the atmosperic transmission file: renaming is not solving the problem. If there is inconsistency between the altitude parameter and the altitude used for the atmospheric file, sim_telarray crashes. I set the altitude to 2158, then of course I get the following warning Warning: Telescope simulation set up for 2158 m site altitude but shower simulations are for 2199 m.

If you have some feedback on the issues, it will be welcomed, thanks

moralejo commented 2 years ago

Hi, I have started the simulations. The simulations are running but there few warnings that might require attention

  1. home/georgios.voutsinas/ws/AllSky/run_directory/sim_runner/tmp/MAGIC1.cfg (67): Could not include file 'CTA-PROD4-pmt_MAGIC1_test.cfg'.

No ifra about that one.

  1. An effective focal length of 2930.565000 cm for a nominal focal length of 1697.000000 cm is not plausible. Reset to zero.

That is mixing MAGIC and LST configurations - weird! Is there a missing setting in MAGIC (effective focal length) and the LST one is taken as default?

  1. Concerning again the atmospheric transmission file: renaming is not solving the problem. If there is inconsistency between the altitude parameter and the altitude used for the atmospheric file, sim_telarray crashes. I set the altitude to 2158, then of course I get the following warning Warning: Telescope simulation set up for 2158 m site altitude but shower simulations are for 2199 m.

No idea about that one either, sorry! @jsitarek, was it not possible to create the file for the right altitude?

maxnoe commented 2 years ago

@moralejo @Voutsi the name of the file was unchanged in the config after removing the CTA-PROD4 prefix, fixed in #25

Voutsi commented 2 years ago

Thanks for the fix, I will create a new tag and relaunch the simulation. Concerning the atmospheric transmission, I will keep at the moment "altitude = 2158 "

Voutsi commented 2 years ago

Or maybe better wait to understand the issue with the focal length

maxnoe commented 2 years ago

The MAGIC configs have no effective_focal_length:

❯ rg "^(effective_)?focal_length"
MAGIC2.cfg
26:focal_length        = 1697     % Effective focal length for camera.

MAGIC1.cfg
26:focal_length        = 1697     % Effective focal length for camera.

LST1.cfg
27:focal_length        = 2800                                      % Nominal focal length [cm]. Effective focal length is 2930.6 cm based on optical ray-tracing.
28:effective_focal_length = 2930.565                               % Only to be used for image analysis. No effect in simulation itself.

So I guess this is why it is taken from LST

Voutsi commented 2 years ago

Thanks @maxnoe So do I understand well that in that case is harmless and therefore can resume production?

Concerning the atmospheric transmission file, I see that MODTRAN is commercial software, I am afraid from my side can't do anything in short term.

maxnoe commented 2 years ago

So do I understand well that in that case is harmless and therefore can resume production?

I am not sure of the implications. We should probably give a proper effective focal length for MAGIC, if only to avoid this warning?

orelgueta commented 2 years ago

I hope you don't mind that I jump in here.

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.

validate_optics_LST-_eff_flen

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