| Summary: | Parallel world physics and optical physics | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | whit |
| Component: | processes | Assignee: | asai |
| Status: | RESOLVED INVALID | ||
| Severity: | critical | CC: | asai, gum, whit |
| Priority: | P5 | ||
| Version: | 10.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: |
Visualization showing the bug: photons get trapped in mirror becuase they don't see the front surface.
The proper behavior of the mirrors is obtained without registering the G4ParallelWorldPhysics No parallel world registered with parallel world registered |
||
Created attachment 366 [details]
The proper behavior of the mirrors is obtained without registering the G4ParallelWorldPhysics
*** Problem 1799 has been marked as a duplicate of this problem. *** Thank you for reporting your issue. I believe you also define optical processes. Could you please specify which optical processes you used and how you registered them? Kind regards, Makoto Could you please provide us a sample code that reproduces your issue? It would be best if it is reasonably simplified. Kind regards, Makoto Here is a git repo where you will find an example. https://github.com/whit2333/scint_test It works as expected but if you uncomment line 214 in ebl_1.cc, which registers the parallel world, the photons don't see the proper surface. https://github.com/whit2333/scint_test/blob/master/ebl_1.cc#L214 This seems to be process independent, that is, the bug shows up for cherenkov photons and scintillation photons. I don't see where you define a mirror? (In reply to comment #6) > I don't see where you define a mirror? I don't define a mirror indeed but you can see (if you visualize, ie run with no arguments) that the photons that should stop at the surface keep going. This indicates it is not a "mirror" problem but some sort of geometry navigation problem. Created attachment 371 [details]
No parallel world registered
Created attachment 372 [details]
with parallel world registered
(In reply to comment #6) > I don't see where you define a mirror? I have attached images of the two scenarios. What happens if you comment out the following two lines in G4OpBoundaryProcess.cc: // const G4Step* hStep = G4ParallelWorldProcess::GetHyperStep(); // if (hStep) pStep = hStep; Makoto? (In reply to comment #11) > What happens if you comment out the following two lines in > G4OpBoundaryProcess.cc: > > > // const G4Step* hStep = G4ParallelWorldProcess::GetHyperStep(); > > // if (hStep) pStep = hStep; > > > Makoto? When I did this and registered a parallel world the surfaces behave properly. I am guessing this hyper step is cause the stepper to miss the first surface seen by the photon. Shouldn't there be a check as to which step should be used instead of just using the hStep? Hi, The problem is understood. In your B1OpticalPhysics.cc, G4OpBoundaryProcess was registered as an ordinary desecrate process. It has to be defined as the very last process to be invoked for PostStepDoIt. Thus The code should read pManager->AddDiscreteProcess(fBoundaryProcess); pManager->SetProcessOrderingToLast(fBoundaryProcess,idxPostStep); Also, in your main(), B1OpticalPhysics should be registered to the physics list **AFTER** G4ParallelWorldPhysics, as both of them try to be the last process (and registered later wins to be the real last). With these modifications, optical photons stop properly at the boundary. Makoto (In reply to comment #13) Indeed, they both need to be last. Is there a good reason to not have every boundary process as be the last process invoked? That is, would there ever be a case where you would not want to have this > pManager->AddDiscreteProcess(fBoundaryProcess); > pManager->SetProcessOrderingToLast(fBoundaryProcess,idxPostStep); in the code? Shouldn't G4OpticalPhysics have the the correct process ordering so it can be used with a parallel world? Is there some basic problem why G4OpticalPhysics doesn't work with a parallel world (when properly registered with the physics list)? This way only one ordering can go wrong instead of two, which is what caused the confusion to begin with. G4ParallelWorldProcess has to be invoked after all the regular discrete processes but G4OpBoundaryProcess has to be invoked after G4ParallelWorldProcess. This is because G4OpBoundaryProcess needs to know about the material of the other side of the boundary and G4ParallelWorldProcess takes care of so-called layered mass geometry. I believe all the pre-packaged physics lists of optical physics have this SetProcessOrderingToLast. At the current situation, this ordering has to be controlled manually by the order of defining physics processes in user's main() or his physics list. We will study an alternative implementation to guarantee this ordering regardless of the user's code, but it needs some investigation. (In reply to comment #15) > I believe all the pre-packaged physics > lists of optical physics have this SetProcessOrderingToLast. I don't think this is true for the boundary process. See http://www.apc.univ-paris7.fr/~franco/g4doxy/html/classG4OpticalPhysics.html#e5479898ebc90d3a93df0e73c1c9d374 There are other processes that have SetProcessOrderingToLast but not the boundary process. > At the current situation, this ordering has to be controlled manually by the > order of defining physics processes in user's main() or his physics list. That is fine, it is pretty easy to make sure this has the right ordering. > We > will study an alternative implementation to guarantee this ordering regardless > of the user's code, but it needs some investigation. First, I think G4OpticalPhysics should be made to work when correctly registered last with the physics list, otherwise the user *must* roll their own optical physics leaving more room for confusion and mistakes. Cheers, Whit > I don't think this is true for the boundary process. See
> http://www.apc.univ-paris7.fr/~franco/g4doxy/html/classG4OpticalPhysics.html#e5479898ebc90d3a93df0e73c1c9d374
It seems you are referring to an obsolete code. That code should never work in multithreaded mode. It is obviouslt thread unsafe. It maybe not work even in the sequential mode of version 10. Please use our LXR.
Anyway, sorry for your inconvenience but currently aligning processes manually in right order is the only way to make both optical boundary process and parallel world process work properly.
|
Created attachment 365 [details] Visualization showing the bug: photons get trapped in mirror becuase they don't see the front surface. There is a bug when optical physics is included along with a parallel world physics. In this simulation the optical surfaces are only associated with the "real" world volumes and the parallel world volumes do not overlap with any of the relevant optical photon surfaces. Whenever the parallel world process is registered (second line of code below) with the modular physics list, the mirror reflections are messed up. The photons don't see the first surface (which is an elliptical mirror). They only see the back, then they bounce off the back from inside the mirror volume and internally reflect, getting trapped inside. They bounce around inside of the mirror instead of being reflected from the front surface. See the attached image. G4VModularPhysicsList * physicsList = factory.GetReferencePhysList("QGSP_BIC_LIV"); physicsList->RegisterPhysics(new G4ParallelWorldPhysics(paraWorldName,/*layered_mass=*/true)); However, when I do not register the G4ParallelWorldPhysics with the physics list, the optics work just as expect! That is, if I comment out the second line above in my main() function, the optics behave but, of course, the parallel world is not seen. Any help in resolving this bug is greatly appreciated.