(3 in pipeline) - runcard fixes, multi-backend gridpacks, python/bash profiling in tlau

[valassi]

This is a WIP PR with fixes and studies in generate_events

It includes a possible fix for #947

[valassi]

As suggested by @oliviermattelaer the fix for #947 is moved to mg5amcnlo/mg5amcnlo#125

[valassi]

The fix for #947 has been stripped off in #949 (which can be merged now)

This has been rebased over it and remains in WIP

[valassi]

I removed the link to #947 (this was fixed in mg5amcnlo/mg5amcnlo#125, submodule was updated in PR #949)

[valassi]

Hi @oliviermattelaer as discussed via email.

This is N=3 in the pipeline I would like to merge.

I changed this to target the N=2 makefiles branch for easier reviewing, but I would then merge it against master once approved.

Can you please tell me if this looks ok? Thanks
Andrea

[valassi]

(Note: this also addresses #700 but I did not manage to link it yet)

[oliviermattelaer]

Point by Point review

multi backend gridpacks (cudacpp_bldall runcard)

No problem on that one, but maybe why including it by default in the run_card?
If you have a comment:

 WARNING! The following cudacpp runcards are experimental! Users should normally change only the cudacpp_backend card ***

Would it make more sense to not display them at all (or in a independent hidden block "simd_advance"?)
-> to be discussed

add cudacpp_helinl and cudacpp_hrdcod runcards for HELINL=1 and HRDCOD=1 modes

• Same comment as above
• comment on the default_setup() need to be changed from a question to an assertion
• maybe good to add the comment field for those?

rename the FPTYPE runcard as cudacpp_fptype

This is delicate since this is going to break retro-compatibility of the code which we have to preserve.
So we either have to not do this change (which is ok) or do it but add a mechanism preserving retro-compatibility.
-> to be discussed

instrument gridpacks with time profiling of the python/bash orchestrator (this is only in my "tlau" tests for the moment, eventually it can be moved in mg5amcnlo, but for the moment it is there so I can use it and further develop it)

I do not see any change in the codegen directory so I guess that you edit manually a .tmad directory, which is fine since those directory needs anyway to be remove from the repo.

Global Comment

Touching the patch, should be avoid as much as possible, do you want to add new handle in the template?
Or do you want to do it? Would be nice to avoid to touch that makefile in such a way...

[valassi]

Hi @oliviermattelaer thanks :-)

I will reply later. For the moment I moved back to draft in any case while working on the base PRs

[valassi]

Hi Olivier thanks for the comments :-)

Maybe easiest to have a short zoom when you have time tomorrow or another time.

In short

• As you prefer for the visibility of the cards. I find it nice to have them in the cards, because this way it's easy to add a comments for users about which options are available. But I do not know how users use runcards enough to judge. Maybe there is some other way to document which cards are available and which options are available for each card.

• As you prefer for floating_type, ok for me to keep it that way. I thought cudacpp_fptype was more consistent, but I really do not care much. I had not thought that backward compatibility was an issue.

• Thanks for accepting the concept of multi backend gridpacks and of python profiling.

• Your comment about "deault_setup" I have not understood. To be discussed.

• About "Touching the patch, should be avoid as much as possible, do you want to add new handle in the template?", I guess you mean that we should go in the direction of what I did for driver.f in Allow patching header/initialise/finalise in driver.f mg5amcnlo/mg5amcnlo#148. My answer is yes, eventually I'd like to do that, but I have not done it here. For the moment the only thing I am trying to do is to NOT INCREASE the stuff in patch.P1 and patch.common. Thanks to various changes you did we reduced this to three files (SubProcesses/makefile, driver.f, matrix1.f), and with what I did fro driver.f I plan to also get rid of driver.f. Then yes we should also get rid of the patch for makefile. I would just do this later... but if you prefer, I will try to get rid of these three first thing (probably after CHEP).

Apart from this:

• I have merged the two base PRs
• So I have updated this PR accordingly
• And I changed its base to master as now it is the lowest level in my "pipeline"

Lets dscuss the other points above by zoome (or just reply here in the meantime), tomorrow.

Thanks! :-)
Andrea