MAGIC ST.03.17 branch and request of simulations

[jsitarek]

Following some discussion with @moralejo @rlopezcoto @Voutsi we partially converged on the way how to generate different analysis periods within lst-sim-config

sim_telarray will have one branch per each set of analysis settings (i.e. MAGIC Analysis period times LST settings) the current sim-telarray branch should be renamed (e.g. to sim-tel_LSTProd2_MAGICST0316)

For the upcoming ST.03.17 production I prepared branch sim-tel_LSTProd2_MAGICST0317 The LST-1 settings have not been modified it in.

@moralejo , @rlopezcoto: if you want to change the branch name please let me know (or do it directly yourself), also if in the end the LST-1 trigger settings should be updated please also let me know.

@Voutsi, after the previous point is settled we should make a release from this sim-tel_LSTProd2_MAGICST0317 branch, maybe sim-tel_LSTProd2_MAGICST0317_v1.0 ? and use this release to generate the test and generate proton and gamma training samples as well as gamma test samples for the March 2022 observations of Crab, repeating here the nodes that will be needed:

Train Zd Az:
[[ 30.39  266.36 ]
 [ 52.162 277.616]
 [ 37.661 270.641]
 [ 44.927 274.284]
 [ 23.161 260.74 ]
 [ 16.087 251.91 ]]
Test Zd Az:
[[ 32.059 248.1  ]
 [ 52.374 301.22 ]
 [ 47.952 270.   ]
 [ 37.814 270.   ]
 [ 10.    248.12 ]
 [ 23.63  259.26 ]
 [ 52.374 240.   ]
 [ 43.197 262.71 ]]

[rlopezcoto]

@moralejo , @rlopezcoto: if you want to change the branch name please let me know (or do it directly yourself), also if in the end the LST-1 trigger settings should be updated please also let me know.

thanks @jsitarek! branch name sounds good and the trigger settings I think it is better if we stick to the ones we currently have.

[Voutsi]

Hi @jsitarek ,

so since we stick to the current trigger settings for LST, I guess we are good to go with tagging the branch sim-tel_LSTProd2_MAGICST0317. If yes, please let me know (or release it yourself if you want). I have some jobs in the queue, but I think I can start with the simulation by the end of the week. It will not take long.

the current sim-telarray branch should be renamed (e.g. to sim-tel_LSTProd2_MAGICST0316)

Here I am a bit sceptical: we are using currently the tag sim-telarray-lst-magic-prod2-v1.4 for the production. The used tag is saved in a configuration file for each produced node. So in that case we will have 2 simtel tags with the same configuration? Or I misunderstood something here?

[moralejo]

The proposed naming for the ST0317 simulations looks ok to me, but renaming the previous ones would be confusing I think. Any strong reason for that proposal, @jsitarek ?

[jsitarek]

Hi,

I created the sim-tel_LSTProd2_MAGICST0317_v1.0 release. I explicitly did not check marking this release as latest, just in case if would interfere with any of the regular LSTProd2 generations, but nevertheless I still see it with this tag latest in github. Downloading the tarball with the release files it seems that it is ok, but since it was the first time I did a release it would be great if @Voutsi could have a second look. Afterwards, @Voutsi can you run those train and test runs what are mentioned above with those new settings? You can put them for the moment in some tentative directory, and once we check the Crab analysis with them, and also decide what to do with the rest of the sources from this period we move them into the final location.

Concerning the renaming of ST0316 settings: please note that there are different "named" things: the branch name from which the release can be made, the actual release and also the tag of the release. Branch you can rename for sure and this is what I propose to do. The release names and tags I'm not sure if can be renamed and either way for the reasons previously mentioned I'm not sure if this is worth it.

If we do not touch anything for the LSTProd2 (+ST0316) branch,release,tag and let's say that some more months and some more settings will pass, we might be using completely different settings for both MAGIC and LST-1, while still having "sim_telarray" branch with a "simple" name suggesting that those are the current settings. And on the other hand if at that time we want to come back to those old settings and generate some missing node of LSTProd2(+ST0316) production we would need to remember that branch "sim_telarray" and tag "sim-telarray-lst-magic-prod2-v1.4" is for ST0316 settings.

Also, I think we are probably misusing a bit the tags, because we create one for every release.

[Voutsi]

Hi @jsitarek ,

sure I will check and launch the production of the nodes.

Branch you can rename for sure and this is what I propose to do.

I see, I misunderstood then. Of course is perfectly fine to rename the branch.

And on the other hand if at that time we want to come back to those old settings and generate some missing node of > LSTProd2(+ST0316) production we would need to remember that branch "sim_telarray" > and tag "sim-telarray-lst-magic-prod2- v1.4" is for ST0316 settings.

Branch sim_telarray is not suppose to be frozen, it is where the active development should take place. So ideally any improvements/corrections should be merged there so sim_telarray branch has always up to date settings.

We never used branches for the production, because this would destroy reproducibility. The tag used for the production of each node is explicitly written in the config file used, which is saved in the node. I see your point that the name of the used tagged is not semantically very useful (ST0316 settings is not reflected in the name) but I am afraid changing the name of the tag (or continue the production with an identical tag named differently) should not be an option cause it will create more confusion than help...

[jsitarek]

Hi @Voutsi

Branch you can rename for sure and this is what I propose to do.

I see, I misunderstood then. Of course is perfectly fine to rename the branch.

And on the other hand if at that time we want to come back to those old settings and generate some missing node of > LSTProd2(+ST0316) production we would need to remember that branch "sim_telarray" > and tag "sim-telarray-lst-magic-prod2- v1.4" is for ST0316 settings.

Branch sim_telarray is not suppose to be frozen, it is where the active development should take place. So ideally any improvements/corrections should be merged there so sim_telarray branch has always up to date settings.

hmm, if we follow this scheme, than we should fork a ST0316 branch from the current sim_telarray branch, and then merge the recent ST0317 branch into the general sim_telarray branch.

We never used branches for the production, because this would destroy reproducibility. The tag used for the production of each node is explicitly written in the config file used, which is saved in the node. I see your point that the name of the used tagged is not semantically very useful (ST0316 settings is not reflected in the name) but I am afraid changing the name of the tag (or continue the production with an identical tag named differently) should not be an option cause it will create more confusion than help...

I agree, it would be a mess having two names for the same settings.

[rlopezcoto]

hi @Voutsi , the tags you are currently using are the ones defined here: https://github.com/cta-observatory/lst-sim-config/tags right? We could also for example create tags from specific branches to allow for reproducibility

[Voutsi]

Hi,

right?

yes.

We could also for example create tags from specific branches to allow for reproducibility

Yes, this is how I proceed now with the simulations of these nodes.

hmm, if we follow this scheme, than we should fork a ST0316 branch from the current sim_telarray branch, and then merge the >recent ST0317 branch into the general sim_telarray branch.

In general if the branch in question is not, e.g. for some special study, we should merge it to sim_telarray. So every time we want to create a new branch, we branch it from sim_telarray and thus we are sure it contains all the latest reviewed updates.

[Voutsi]

Hi @jsitarek ,

the production finished. You can find the test files at:

/fefs/aswg/data/mc/DL0/LSTProd2/TestDataset/sim_telarray/ST0317

and the training files at:

/fefs/aswg/data/mc/DL0/LSTProd2/TrainingDataset/GammaDiffuse/dec_2276/sim_telarray/ST0317

and respectively for protons. I had a look and the production and it seems ok, please let me know if you observe something weird.

One thing, in case you use some automated tools for processing the files, now the directory with data is named output and not output_v1.4 as usual (this v1.4 has been inherited from the past where we wanted to store simtel files with various trigger settings, and v1.4 was the tag with the most updated settings)