Profile C8 and Pythia

added Hadronic label

changed milestone to %air showers with pythia

changed the description

I have this error : what(): npz_load: Error! Unable to open file /home/afaure/Codes/CORSIKA/corsika/modules/data/Pythia/pythia8311_xsec/xs_2212_2212.npz!. Does it look familiar ? This file is not present in the repo

Oops nevermind I updated the submodules and it solved the problem

I have this error when running with Pythia on my lab cluster:

terminate called after throwing an instance of 'std::runtime_error'
  what():  CrossSectionTable: value out of bounds (lower limit)
Abandon (core dumped)

When I remove the -M Pythia8 flag the program crashes but I have no error message.

When running in local everything works.

Do you know where it's coming from ?

did you use the correct version of corsika-data ? and is the branch/commit the same? Is the threshold (-T) the same? Is the error appearing in the init phase or during the shower simulation? If it is during the shower then try to increase the threshold for pythia (-T). Recently there was a fix/hack introduced which means the threshold has to be 100GeV * A(of the heaviest target nucleus) which means 1.6TeV for pythia.

For corsika-data I ran a git pull --recurse-submodules --jobs=10 and I have :

git submodule status
 ab5f63b4ea3347f96d82a999c908af2b6475845e modules/conex/cxroot (heads/master)
 215b6b04c856cb8fa8d22047a533754ef1e72543 modules/data (remotes/origin/pythia_npz)

for both (except locally it's heads/master-2-gab5f63b instead of heads/master). The branch is the same in both local and cluster version (branch 710, I checked with git log that the last commits are the same).

For the threshold I put -T 100 for both. When I change to -T 1600 depending on the random seed it either throws the error or runs fine.

The error appears during the shower simulation with -M Pythia. Without the Pythia flag, in some cases the simulation runs fine, and in some it crashes without an error.

Fun

try 1.7 TeV :) I neglected the nucleon mass in the guess for the threshold

@gaudu is in the process of fixing the tables. You may want to wait for that. or go to really high energies (with appropriate cuts).
@gaudu did you see random crashes in your pythia runs?

When I remove the -M Pythia8 flag the program crashes but I have no error message.

you are running ./c8_air_shower --pdg 2212 -M Pythia8 -E 1e6 --emcut 0.01 --hadcut 0.3 --mucut 0.3 -T 100 without -M Pythia8 and it crashes straight away? thats new. I will have a look

Also if you only want to profile pythia I would cut away all EM particles. Otherwise the performance is mostly proposal+tracking

With 1.7TeV it also crashes sometimes depending on the seed

you are running ./c8_air_shower --pdg 2212 -M Pythia8 -E 1e6 --emcut 0.01 --hadcut 0.3 --mucut 0.3 -T 100 without -M Pythia8 and it crashes straight away? thats new. I will have a look

I think but I am not entirely sure, maybe I got mixed up. I can try and find a seed with which it happens

I cannot reproduce the crash without the -M Pythia8 flag so surely I got mixed up ! Sorry for the false alarm

@gaudu did you see random crashes in your pythia runs?

None of my showers crashed recently.

With 1.7TeV it also crashes sometimes depending on the seed

I used -T 4000 for my vertical proton showers at first, hence why I had no crashes I would guess

So should I use -T 1600 or -T 4000 for my profiling ?

How about you use 1 EeV primaries and set the hadron cut to 1 PeV (or something that gives a reasonable runtime)? and the emcut to the primary energy. That way you stay way from the problematic region (you still have to supply -T 100 ..). For reference I would be interested to see the same configuration with Sibyll :)

So you suggest I run ./c8_air_shower --pdg 2212 -M Pythia8 -E 1e9 --emcut 1e9 --hadcut 1e6 --mucut 0.3 -T 100 ?

You could also set --mucut=1e9. That way the time spent in corsika is minimal and no PROPOSAL is used.

Here is the profile for ./c8_air_shower --pdg 2212 -M Pythia8 -E 1e9 --emcut 1e9 --hadcut 1e6 --mucut 1e9 -T 100: The runtime was 11min.

Here is an interactive link : https://share.firefox.dev/3ZuiFrt (sorry for the mangled names, I will try to fix this for the next profilings).

I will try a more precise profiling of this case and I will compare with Sybill as well.

Hehe nice. All the secrets are revealed.. :)

Looks like a factor two speedup would be possible if Angantyr allowed simultaneous resetting of beam ID and energy..

Update : interactive profiling with demangled names

I tried with a higher sampling frequency (-F 100 instead of -F 10) and the hotspots are the same so the results I already posted are precise enough, we can use them

yes this looks good. Its also clear that the current runtime sink is inside Angantyr and it is an algorithmic problem. Which makes it easy to fix. At least easier than if all the pieces were slow or if the cause was the complexity of the problem.

Results for ./c8_air_shower --pdg 2212 -M SIBYLL-2.3d -E 1e9 --emcut 1e9 --hadcut 1e6 --mucut 1e9 -T 100 :

For 1 shower: click to expand, interactive link here

For 10 showers: click to expand, interactive link here

The longest processes in a Sibyll only simulation are the FLUKA and PROPOSAL initialisations

changed the description

Running the profile on ./c8_air_shower --pdg 2212 -M Pythia8 -E 1e9 --emcut 1e9 --hadcut 1e6 --mucut 1e9 -T 100 really removes any time in PROPOSAL while already minimizing as much as possible the amount of interactions between Pythia and CORSIKA. It looks like a witch hunt lol

If the profiling results show no issues on the Pythia side and/or our C8+P8 interface, what is the next thing we would need to investigate?

removed Hadronic Performance labels

added Hadronic Performance labels

changed the description

marked the checklist item Run perf record : as completed

Profile C8 and Pythia

Child items ...

Activity