Interfacing EvtCalc in FairShip

[mferril]

Vanilla implementation of the EventCalc LLPs decay event sampler in FairShip for inclusive final states.

Additions & modifications to master:

• FairShip/shipgen/EvtCalcGenerator(.cxx/.h)
• FairShip/macro/run_simScript.py
• FairShip/macro/convertEvtCalc.py

To do list (in order of priority):

• Including more LLP models ( Issue EvtCalc: add more LLP models #536 )
• Incorporating the event sampler code within FairShip ( Issue EvtCalc: Incorporating the event sampler code within FairShip #537 )
• Interfacing PYTHIA for hadronisation of final states with qq' ( Issue EvtCalc: Interfacing PYTHIA for hadronisation of final states with qq' #538 )
• Adding features to produce exclusive decays ( Issue EvtCalc: Adding features to produce exclusive decays #539 )
• Implementing systematic uncertainties in the production and decay calculations ( Issue EvtCalc: Implementing systematic uncertainties in the production and decay calculations #540 )

FYI @maksymovchynnikov

[olantwin]

A preliminary remark and a question:

• The history needs some cleaning up, we can do that once everything else is ready for review. Only the merge commit might be nice to remove already now.
• Which of the todo items would you consider necessary for the first version and which can we tackle later?

[olantwin]

First pass just reading over the code.

For testing this, could you please provide some example input files and instructions on how to use it?

[olantwin]

At the software meeting it was agreed that the todo items can be tackled later. @mferril, could you please open issues for them?

One thing that would be very nice to have would be some control plots for the expected output for some example channel and input file. Hopefully we can then gradually expand the collection to include more channels.

[olantwin]

@mferril @maksymovchynnikov Any updates?

At the software meeting it was agreed that the todo items can be tackled later. @mferril, could you please open issues for them?

[olantwin]

@yabezsh @anupama-reghunath, did you have a chance to have a look at the pull request?

Overall, the proposed changes are quite small, so we should be able to merge this pretty quickly.

[mferril]

@mferril @maksymovchynnikov Any updates?

At the software meeting it was agreed that the todo items can be tackled later. @mferril, could you please open issues for them?

Hi @olantwin , I have given this lower priority given some conflicting deadlines this week. I am planning to look at it later in the day/weekend. Thanks for understanding!

[olantwin]

Hi @olantwin , I have given this lower priority given some conflicting deadlines this week. I am planning to look at it later in the day/weekend. Thanks for understanding!

Ok, no worries! Good luck with the deadlines!

[olantwin]

@yabezsh @anupama-reghunath I'd really appreciate your feedback on your pull request, but will interpret continued silence as approval.

@mferril Could you please provide me a .dat file I can test this with? Apart from that this now looks to be in fairly good shape, and would be ready for automatic fixes, history rewriting etc.

[olantwin]

@mferril This also is still missing an entry in the changelog. I think an paragraph to introduce such a major new feature would be great, maybe with a link to your collaboration meeting presentation.

[mferril]

@yabezsh @anupama-reghunath I'd really appreciate your feedback on your pull request, but will interpret continued silence as approval.

@mferril Could you please provide me a .dat file I can test this with? Apart from that this now looks to be in fairly good shape, and would be ready for automatic fixes, history rewriting etc.

I have just shared with you the input .dat file. To test whether it works, we could think about adding in the future some unit-testing or similar.

Basic commands to launch:
python convertEvtCalc.py -f test_input.dat -o test_folder
then
python run_simScript.py --evtcalc -n 1 -o test_folder -f test_folder/test_input.root

[mferril]

@mferril This also is still missing an entry in the changelog. I think an paragraph to introduce such a major new feature would be great, maybe with a link to your collaboration meeting presentation.

@olantwin this has been changed in the last commit.

[olantwin]

@mferril This also is still missing an entry in the changelog. [..]

@olantwin this has been changed in the last commit.

Thanks! I'll take the liberty to slightly rephrase/reorganise it, but it provides the perfect amount of detail.

[olantwin]

@yabezsh @anupama-reghunath I'd really appreciate your feedback on your pull request, but will interpret continued silence as approval.
@mferril Could you please provide me a .dat file I can test this with? Apart from that this now looks to be in fairly good shape, and would be ready for automatic fixes, history rewriting etc.

I have just shared with you the input .dat file. To test whether it works, we could think about adding in the future some unit-testing or similar.

Basic commands to launch: python convertEvtCalc.py -f test_input.dat -o test_folder then python run_simScript.py --evtcalc -n 1 -o test_folder -f test_folder/test_input.root

Some observations:

1. When the output dir does not exist, the conversion script crashes. Might be worth creating it.
2. If the input file does not exist, the EventCalcGenerator crashes instead of exiting cleanly.

[yabezsh]

Hi @mferril ,
Thank you for the great work. I tested everything with the files provided and it worked smoothly on lxplus. The code looks good to me too.
I just have one ideological question. The first step is to convert the .dat file from EventCalc to the .root format, which will then be integrated into EventCalc. Will EventCalc be integrated into FairSHiP in the future, or will we use it as an external generator?
And the second question, the new physics particle now has pdg 999, do we plan to have different pdg codes for different models? Or how can we distinguish in the generated files what kind of model has been simulated?
Thanks!

[olantwin]

The first step is to convert the .dat file from EventCalc to the .root format, which will then be integrated into EventCalc. Will EventCalc be integrated into FairSHiP in the future, or will we use it as an external generator?

In my opinion EventCalc should be in a different repository, but ideally our simulation would call it directly without intermediate files. So close integration, and we could even consider maintaining/developing it in the collaboration, but I don't see any advantages and several disadvantages in including it within FairShip.

And the second question, the new physics particle now has pdg 999, do we plan to have different pdg codes for different models? Or how can we distinguish in the generated files what kind of model has been simulated? Thanks!

This is an issue to be fixed after this initial version. For most, no standard PDG codes exist, and using the geantino as we do currently is no long-term solution. In the short-term, we need to differentiate via bookkeeping, but adding new particles to the PDG database similar to what we do for HNL would be better.

@yabezsh I interpret your message as approval?

[mferril]

The first step is to convert the .dat file from EventCalc to the .root format, which will then be integrated into EventCalc. Will EventCalc be integrated into FairSHiP in the future, or will we use it as an external generator?

In my opinion EventCalc should be in a different repository, but ideally our simulation would call it directly without intermediate files. So close integration, and we could even consider maintaining/developing it in the collaboration, but I don't see any advantages and several disadvantages in including it within FairShip.

@yabezsh this is currently under discussion and no final decision has been made yet on the integration within FairShip. We are working to achieve exactly what @olantwin mentioned, which is an internal call to the generator (e.g. as you would call Pythia or any other MC tool). See also Issue #537 .

And the second question, the new physics particle now has pdg 999, do we plan to have different pdg codes for different models? Or how can we distinguish in the generated files what kind of model has been simulated? Thanks!

This is an issue to be fixed after this initial version. For most, no standard PDG codes exist, and using the geantino as we do currently is no long-term solution. In the short-term, we need to differentiate via bookkeeping, but adding new particles to the PDG database similar to what we do for HNL would be better.

Exactly, @olantwin explained it perfectly. Ideally we would issue separate PDG codes in the database for each LLP model we incorporate.

[yabezsh]

@mferril @olantwin ok, perfect. That's exactly what I meant, it would be good to be able to call EventCalc directly from FairSHiP so that the user doesn't have to search for .dat files or use EventCalc separately to generate files. Having it as a separate package is then much more practical.
then all is well from my point of view, i approve