-
Notifications
You must be signed in to change notification settings - Fork 33
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
Include mg5amcnlo in madgraph4gpu as a git submodule #752
Conversation
mkdir <top>/MG5aMC cd <top>/MG5aMC git submodule add https://github.com/mg5amcnlo/mg5amcnlo
cd <top> git submodule set-branch --branch gpucpp MG5AMC/mg5amcnlo (NB: the module name is MG5AMC/mg5amcnlo, you should not run this command with argument mg5amcnlo from directory MG5AMC) (NB: 'git config -l' shows no difference)
git submodule update --remote Submodule path 'MG5aMC/mg5amcnlo': checked out '941832b9b03213da8ab994427add396673820799'
… the mg5amcnlo submodule in this repo
…ories to $MG5AMC_HOME/../TMPOUT
…5amcnlo/PLUGINS after code generation
…er files showing directory names In proc_card_mg5.dat -output madevent CODEGEN_mad_gg_tt ... +output madevent ../TMPOUT/CODEGEN_mad_gg_tt ... In me5_configuration.txt -#mg5_path = /data/avalassi/GPU2023/MG5aMC/ghav-mg5amcnlo +#mg5_path = /data/avalassi/GPU2023/madgraph4gpuMOD/MG5aMC/mg5amcnlo In py3_model.pkl (binary files differ) NOTE: I also added gg_tt.mad/bin/internal/plugin_run_card which seems to be a new file? This is probably something added by OLivier after last week's discussions, it contains {'name':'cudacpp_backend', 'value':'CPP', 'include':False, 'hidden':False}
… by git submodules Note: they were pointing to branch.GIT = gpucpp commit.GIT = 941832b9b Note: 'git show b145ba4' gives Submodule MG5aMC/mg5amcnlo 1a13d8f53..941832b9b: That is to say, the submodule points to the same commit (by default in detached HEAD state, unless users checkout a specific branch)
…d for all of them)
…PP_OUTPUT when copying to mg5amcnlo
… all ok, no change except log
…- all ok, no change except log
…UTPUT - all ok, no change except log
…ing plugin as CUDACPP_OUTPUT - all ok, no change except log
I have discussed this briefly with @roiser and @hageboeck in person. There should not be any major issue. All CI tests passed, I will self merge. Thanks again to @hageboeck for all the ideas on which this is based! |
There is one situation where we would need to be careful, i.e. when switching the submodule to a another fork. E.g. I have checked out the
this will create a diff in the "outer" repository for the submodule link
--> we should be careful to never commit/push this link e.g. via a PR, otherwise this wrong link will end up in the upstream repository pointing to (in this case) my fork for the submodule |
Hi Stefan thanks. Ah ok now I understand what you mean. We had a misunderstanding between two cases.
|
…de new changes to cudacpp from MR madgraph5/madgraph4gpu#752)
Import new changes from madgraph5/madgraph4gpu#752
yes you are right, if the two branches "upstream" and "origin" are at the same stage the commit hash is also the same, so there won't be a problem The only possible problem left I see is if they diverge then we should understand if one does two PRs one for the submodule and one for the commit hash outside or we "adjust" the commit hash in a different way once the submodule PR has been merged.
no that's ok, no problem here. |
Hi, good, thanks for checking.
Hm I think that unfortunately we will need always two MRs anyway, one on madgraph4gpu and one on gpucpp. These are two different repos, I do not think we can combine change sto two repos in a single MR? If indeed we need two MRs. then I guess it is better to first merge mg5amcnlo and only later merge madgraph4gpu, as the latter contains the hash to the former, not viceversa. This is almost exactly what I had with my commit.GIT anyway. Sometimes I was making changes in mg5amcnlo gpucpp in my fork and create a MR (so the hash would be in my fork anyway) and change madgraph4gpu even if that commit of gpucpp was not yet merged. But we should try to avoid it. So I guess, ideally, first push/merge on mg5amcnlo gpucpp so that the commit hash is there, and then push/merge the reference to that hash in madgraph4gpu. Then sometimes there can be exceptions/deviations... |
Hi @oliviermattelaer @hageboeck @roiser @zeniheisser @Jooorgen
I have completed the inclusion of mg5amcnlo in madgraph4gpu as a git submodule.
This MR is ready to be merged... but please let me know if you have comments or would have liked some things differently.
This completes our "step 1" agreed last week
For info, what I personally did was the following
git submodule update --remote --merge
.See section "Working on a Submodule" in https://git-scm.com/book/en/v2/Git-Tools-Submodules
I am also progressing on step2, i.e. the move of the codegen plugin to a separate repo (the only tricky bit is I am keeping the commit history for that and will try to change the links to existing github issues to point to madgraph4gpu - and then making a few tests to understand how to continue porting codegen changes in existing MRs like HIP). It should be ready in one day or two I think.
Thanks
Andrea
PS I take it back slightly (see https://github.com/madgraph5/madgraph4gpu/pull/752/files)
So I guess that a new clone will checkout gpucpp and use the specific commit there? I will check