search

CRPropa / CRPropa3

CRPropa is a public astrophysical simulation framework for propagating extraterrestrial ultra-high energy particles. https://crpropa.github.io/CRPropa3/
https://crpropa.desy.de
GNU General Public License v3.0
65 stars 66 forks source link

Interaction and source tags #407

Closed JulienDoerner closed 1 year ago

JulienDoerner commented 1 year ago

With this PR a new Candidate property called tagOrigin will be introduced.

This new feature can be used for two things.

The first is to distinguish which interaction processes produced the observed candidate. Therefore all interaction processes which can produce a secondary have their own interactionTag. This will be given for all produced secondaries and the user is able to customize the tag if the same interaction with different backgrounds, e.g. photonfields, is used.

The second application is the discrimination of different sources. In case that the sources follows the same spatial distribution or the distribution overlaps it can not be distinguished by the source position anymore. Therefore the new source feature SourceTag adds a unique tag to the candidate.

The tagOrigin can be added to the output as a separate column. For the header a comment with the default abbreviations for the interactions is added.

Also test for all interaction processes and also for the candidate get/set function and the source feature are included.

rafaelab commented 1 year ago

Hi @JulienDoerner Thanks for this PR. I think we all have been wishing for such a feature for a while. I haven't checked it yet, but I'm wondering something. My main concern is the possible performance hit that CRPropa takes every time a new candidate property is added. Since now all candidates will have an additional property, this will possibly increase simulation time. Or not? Have you checked this?

JulienDoerner commented 1 year ago

Hey @rafaelab The performance is the reason why I didn't use the custom property but writing a hard candidate property in line 49.

For comparing the runtime I took a extreme example with many secondaries. In my test simulation 1e4 iron nuclei with the energy of 1000 EeV are propagated over 100 Mpc. I take the PD and PPP both on the CMB into account and produce all secondaries.

The result of 50 repetitions can be seen here: runtime

The difference in runtime is here by about 3%. In other cases with less secondaries the performance impact becomes negligible.

lukasmerten commented 1 year ago

I think a three percent simulation time increase is a fair trade off for this feature. If you @rafaelab are also fine with that, we can try to merge this soon.

JulienDoerner commented 1 year ago

Thanks @lukasmerten for your comments, I corrected the typos and renamed the particle to candidate in the new features. But I think this could also be done for the other parts of the Candidate.h file. I would suggest to do this within the PR for the update of the documentation.

lukasmerten commented 1 year ago

Looks good to me now. If I do not hear anything different I will merge this tomorrow or on Friday.

lukasmerten commented 1 year ago

@JulienDoerner: One last thing. Can you add a note to the CHANGELOG please.

rafaelab commented 1 year ago

Thanks for the review, @lukasmerten I also finished testing it. I was afraid that there might be some errors because many modules were touched, but this is not the case. @JulienDoerner: just add this change to the CHANGELO, as Lukas suggested, and then it can be merged.

JulienDoerner commented 1 year ago

I added a comment in the change log. @lukasmerten can you take a look on the comment and merge afterwards?