KGeoBag deinitialization

[pslocum]

This is a small change that seems to help when running multiple Kassiopeia simulations inside one executable (e.g. when modeling pileup). Without this change, there appear to geometry spaces that persist across repeated Kassiopeia simulations, which causes the error multiple spaces registered for path ... . There may be a more suitable location for this change, but this one can be suggested as a starting point.

[richeldichel]

Thanks for this pull request, which looks like a fairly straightforward fix.
Did you observe this behavior anywhere else or does it just affect KGeoBag?

[pslocum]

Thanks for the reply. From the terminal output, it appears that only KGeoBag was affected. With the fix in place, we can run identical sequential Kassiopeia simulations inside one executable.

[richeldichel]

Okay! I have no objections to this small change and I also don't see a better way to solve it right now. So I will just go ahead and merge this.

[pslocum]

Thank you!

[pslocum]

After more testing, it appears that the above KGeoBag objects that are persisting across multiple simulations are also needed for rendering in VTK graphics. So while this fix has optimized pileup calculations, it unfortunately seems to cause missing KGeoBag objects in graphical VTK outputs.

[richeldichel]

Interesting. Do you change any geometry elements in these different simulations?

[pslocum]

Right, there were no other changes to the geometry elements when doing these tests.

One possible idea would be to move the fix from the above location ^ to a later time after the VTK objects have been rendered. However, that might not work in a case where VTK is never instantiated. I also tried moving the fix into KSRoot, but there it still interfered with VTK's access to the KGeoBag objects. Additionally, I tried to make the above fix dependent on the flag KASPER_USE_VTK, but this was not successful because I think it's really a question of whether VTK is instantiated, instead of whether VTK has been compiled.

[richeldichel]

I also have a different problem, namely that the KVTKWindow is started after the deinitialization so that I do not get any geometry elements displayed via Kassiopeia's vtk viewer. Hence, I think I need to revert this commit and we need to find a different solution.

I am assuming you are using the VTK writer to get a .vtp file for each simulation that can then be accessed separately?

[pslocum]

Thanks and yes, that is a good summary of the problem I am noticing - the KVTKWindow is started after the KGeoBag deinitialization. I assume that .vtp files would be similarly affected, but have not confirmed. In any case I agree that the commit here needs to be reverted in favor of a fix that can delete the KGeoBag objects, but without interfering with VTK's access to them.

…

On Wed, Jan 10, 2024 at 6:34 AM Richard S ***@***.***> wrote: I also have a different problem, namely that the KVTKWindow is started after the deinitialization so that I do not get any geometry elements displayed via Kassiopeia's vtk viewer. Hence, I think I need to revert this commit and we need to find a different solution. I am assuming you are using the VTK writer to get a .vtp file for each simulation that can then be accessed separately? — Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBROLXVROSQRJ4PXMHA3DYNZ4EPAVCNFSM6AAAAABA2MJPWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBUGY3TQMBWHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>