Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated workplan (May 2023) towards a first alpha release #671

Open
valassi opened this issue May 26, 2023 · 3 comments
Open

Updated workplan (May 2023) towards a first alpha release #671

valassi opened this issue May 26, 2023 · 3 comments
Assignees

Comments

@valassi
Copy link
Member

valassi commented May 26, 2023

This is an updated workplan (as of May 2023) towards a first alpha release. It follows up on and replaces the previous workplan from December 2022 in #576, where several issues have been fixed, but some are still open, and in addition many new ones have appeared.

The plan is essentially that I presented at the dev meeting last Monday in https://indico.cern.ch/event/1288364/

Trying to put things in order (but I also indicate the numbers of #576)

Licensing etc (non technical blocker) - new with respect to #576

General resync of madgraph4gpu to upstream mg5amcnlo (blocker) - this was in point 2 in #576

Relocatable builds - this was part of point 3 in #576, even if not explicitly mentioned there

Handling of multiple P1/P2/... subprocesses (blocker for this common use case) - part of point 6 in #576

Madevent application cleanup (blocker) - this was in point 3 of #576

Cleanup of other build issues (~blocker for c++-only builds?) - new added June 4

Port post-generation patches upstream (blocker) - this was part of 2 in #576

Test the launch functionality (blocker) - this was point 5 in #576

Cross check handling of parameters (blocker) - this was point 4 in #576

Copy plugins to mg5amcnlo (~blocker: the final blocker step?) - new with respect to #576

Cleanup of color (high priority for physics results, but not a technical blocker) - this was point 1 in #576

Experiment integration (our final goal - to be tested both before and after the release) - ~part of point 6 in #576

Other physics validation issues (high priority for the experiments, not strictly technical blockers) - ~part of point 6 in #576

SM process-specific issues (high priority for the experiments, not strictly technical blockers) - ~part of point 6 in #576

BSM process-specific issues (varying, lower priorities) - ~part of point 6 in #576

@nscottnichols
Copy link
Contributor

@valassi I saw your comment here when I was syncing the sycl branch with the latest cudacpp changes. I am getting the correct value for nwf (at least for gg_tt) using self.matrix_elements[0].get_number_of_wavefunctions() in model_handeling.py. It could be because I added code in generate_process_files() to write CPPProcess.cc before CPPProcess.h.

@valassi
Copy link
Member Author

valassi commented Jun 3, 2023

@valassi I saw your comment here when I was syncing the sycl branch with the latest cudacpp changes. I am getting the correct value for nwf (at least for gg_tt) using self.matrix_elements[0].get_number_of_wavefunctions() in model_handeling.py. It could be because I added code in generate_process_files() to write CPPProcess.cc before CPPProcess.h.

Thanks @nscottnichols ! I opened #677 as a reminder that I could also try to move nwf from CPPProcess.cc to CPPProcess.h. This is low priority anyway - so no longer a blocker for the alpha release - because the main issue was moving nwf from src to P1, and this is done. It would be a nice future cleanup/improvement however.

@oliviermattelaer
Copy link
Member

I need also to focus on #867
to allow the integration of gpucpp within the 3.6.0 branch of MG5aMC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants