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

Generate coloramps.h directly rather than via "sed" on coloramps.inc #713

Closed
valassi opened this issue Jun 19, 2023 · 2 comments · Fixed by #742
Closed

Generate coloramps.h directly rather than via "sed" on coloramps.inc #713

valassi opened this issue Jun 19, 2023 · 2 comments · Fixed by #742
Assignees

Comments

@valassi
Copy link
Member

valassi commented Jun 19, 2023

Generate coloramps.h directly rather than via "sed" on coloramps.inc

This was introduced in MR #573 implementing #402.

As mentioned in #573 (comment)

By using brute force sed/awk I transformed coloramps.inc into coloramps.h in such a way that they have the same definition of icolamp. Assuming that the one in Fortran is correct (is it?!) then also the one in cudacpp is correct.

This is also related to #655: after the latest select_color changes, we no longer get the same LHE color in foratran and cudacpp.

Ideally, eventually we should be able to generate coloramps.h directly rather than via "sed" on coloramps.inc. This is also related to removing patchMad.sh in #656

valassi added a commit to valassi/madgraph4gpu that referenced this issue Aug 10, 2023
…amps.h fixes the LHE color mismatch in ggttgg (madgraph5#655), while also removing the need for the coloramps.h patch (madgraph5#713)
valassi added a commit to valassi/madgraph4gpu that referenced this issue Aug 10, 2023
valassi added a commit to valassi/madgraph4gpu that referenced this issue Aug 10, 2023
…colormaps madgraph5#655 and madgraph5#713 are fixed

(Some performance fluctuations, maybe generally a bit slower? but no clear pattern)

STARTED AT Thu Aug 10 03:29:39 CEST 2023
ENDED   AT Thu Aug 10 07:47:39 CEST 2023

Status=0

24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_eemumu_mad/log_eemumu_mad_d_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_eemumu_mad/log_eemumu_mad_f_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_eemumu_mad/log_eemumu_mad_m_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttggg_mad/log_ggttggg_mad_d_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttggg_mad/log_ggttggg_mad_f_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttggg_mad/log_ggttggg_mad_m_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttgg_mad/log_ggttgg_mad_d_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttgg_mad/log_ggttgg_mad_f_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttgg_mad/log_ggttgg_mad_m_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttg_mad/log_ggttg_mad_d_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttg_mad/log_ggttg_mad_f_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggttg_mad/log_ggttg_mad_m_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggtt_mad/log_ggtt_mad_d_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggtt_mad/log_ggtt_mad_f_inl0_hrd0.txt
24 /data/avalassi/GPU2023/madgraph4gpuX/epochX/cudacpp/tmad/logs_ggtt_mad/log_ggtt_mad_m_inl0_hrd0.txt
valassi added a commit to valassi/madgraph4gpu that referenced this issue Aug 10, 2023
@valassi
Copy link
Member Author

valassi commented Aug 10, 2023

This has been completed in MR #742.

@oliviermattelaer suggested to try and remove my patch that was recreating coloramps.h from coloramps.inc (#713), and use coloramps.h directly, using the results of his previous select_color changes. This turns out to fix the issue in color choices in ggttgg LHE files (fixing #655): a very simple change that fixes two issues at the same time.

@valassi
Copy link
Member Author

valassi commented Jun 28, 2024

Note the discussion in #873. I think that this MR #742 fixed the #655 issue for the wrong reasons, i.e. because it introiduced two bugs that cancelled each other ofr iconfig=1:

Now #873 should normally fix this whole situation...

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

Successfully merging a pull request may close this issue.

2 participants