Opened 15 years ago
Closed 5 years ago
#45 closed task (duplicate)
Validate and improve Multiple Interaction Code
Reported by: | Juergen Reuter | Owned by: | boschmann, sschmidt, kilian |
---|---|---|---|
Priority: | P2 | Milestone: | v4.0 |
Component: | core | Version: | |
Severity: | normal | Keywords: | Multiple interactions |
Cc: |
Description (last modified by )
The MPI code attached to the main WHIZARD is not yet functional or working...
Change History (11)
comment:1 Changed 15 years ago by
Owner: | changed from kilian to boschmann, sschmidt, kilian |
---|
comment:2 Changed 14 years ago by
Milestone: | v2.1.0 → v2.1.1 |
---|
comment:3 Changed 13 years ago by
comment:4 Changed 13 years ago by
I have committed some real non-dummy muli modules to revision 3429. muli is not complete and does not yet do anything, but most downgrades and workarounds are common to all modules, so I do hope to not encounter new problems.
comment:5 Changed 13 years ago by
One more large commit (3458) was done today. All relevant multiple interactions code is shoveled to muli now, so muli is really generating multiple interactions, but not all parts of the code are enabled at the present.
There is one more regression: One gfortran workaround fails to work in muli, although I have tested it in a small program. But it works fine with nagfor, so I can run WHIZARD including muli.
I still have to enable all old code and have to add some new features for the interleaved algorithm.
comment:6 Changed 12 years ago by
Milestone: | v2.3.0 → v2.2.0 |
---|---|
Priority: | P3 → P2 |
We set up a new branch branches/interleaved which contains the MPI code (a.k.a. muli) which finally compiles again from revision r3860 on.What has to be done is to do a proper setup in the configure/m4 infrastructure, check for the compilers, translate the docu into English and integrate it into the proper WHIZARD docu environment. BIGGEST PROBLEM: What about the dependence on CUDA!? I surely do not want to have this inside WHIZARD. Can we do this with VAMP?
comment:7 Changed 12 years ago by
Description: | modified (diff) |
---|---|
Summary: | Attaching the Multiple Interaction Code to the main WHIZARD → Validate and improve Multiple Interaction Code |
With r3937 the MPI code of Hans has been attached to the main WHIZARD, but it's not yet functional (Cuba dependence!), and there seem also to be some problems with color reconnections in hadronization reported by SS. How do we proceed?
comment:8 Changed 10 years ago by
Milestone: | v2.3.0 → v3.0 |
---|
comment:10 Changed 7 years ago by
Milestone: | v3.0.0 → v4.0 |
---|
comment:11 Changed 5 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Transferred to Gitlab Issue 325.
This is the actual status of my multiple interactions merge into WHIZARD:
Sebastian and me have had some time to discuss our interleaved algorithm in april 2011 at the Monte Carlo meeting in Hamburg. We decided that MI without shower doesn't make much sense, so we set up a new branch "interleaved". It contains a new source dir "muli" which is an acronym for multiple interactions. This is where I am going to insert my MI code. I chose this name because Juergen told me that such names should be longer than two characters. Then again mpi would be equivocal to message passing interface.
Sebastian and me have set up some interfaces and some dummy procedures. Our branch looks abandoned since then, but in fact it is by no means abandoned. I am working out a way to convert my standalone code to the interleaved branch all the time in my working copy.
The problem is this:
I have got two versions of my standalone code, one for nagfor and one for gcc. As soon an gcc 4.6.0 was released, I started to finally downgrade the code to a subset of features that can be used by both compilers. Last week I happily removed the last blocking feature and was looking forward to commit a first real, non-dummy module. But, as always, I immediately stumbled upon new bugs both in nag and in gcc.
So starting with a nag compatible standalone code in autumn 2010, I got to some muli code that is not compatible to any compiler at all. I will do what I have always done in the past three years, I will sent in bug reports and meanwhile try to find some workarounds.
Outlook:
I am still confident of committing some code in near future. This code will initially be only compatible to the latest revisions of nagfor and gcc. Since my latest bug reports to gcc only addressed features which are officially supported by gcc 4.6, there is some hope that the patches will be applied to the 4.6 branch.