-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding Pythia 8.3.10 to chromo #174
base: main
Are you sure you want to change the base?
Conversation
Thanks for starting this! What about this cached directory? How big are the files? Does it cleanup/update itself? |
For each (projectile, target, energy) combination, you will produce three files:
For example, a proton boosted against a target of oxygen-16 at rest would produce files from the following sizes:
There is currently nothing in place for the files to cleanup or update themselves, since they are supposed to be generated once by Pythia (according to the user's settings) and kept for future runs using the same (projectile, target, energy) combination. I would need to check if the files are generated in the working directory of the user or in the /examples folder of their Pythia8 installation. |
We also don't have cleanup routines for the other cached files in place. For example if you update chromo and it needs to download a newer zip file from our server, the old one is not deleted, as far as I am aware. We should probably wipe the iamdata directory everytime a download of the zip file is triggered, which would do the correct cleanup automatically. |
@afedynitch @jncots This PR is failing on CI because we are don't have the new zip file for this Pythia8 version uploaded yet. Is it possible to add a new file without making a new release? Edit: actually it fails even before that because some build code expects that urqmd is in the model list. For development we took all the other models out. @gaudu could you please restore the file default_models.cfg to its original state? And commit? |
Yes, it's possible. @gaudu, please attach the file here if it's not too big |
The files are so small that I would rather prefer precomputing all of the common combinations and distribute these as binaries using our zip downloads. Otherwise testing on public workers may take too long. What do you think about this @gaudu & @HDembinski ? |
|
I would not mind generating few files if needed, it really never took that long for me. @afedynitch Could you provide the "common" (projectile, target, center-of-mass energy) combinations you would like to have run? |
@afedynitch @jncots You can ignore this, I independently created the zip and uploaded it to the right place. |
@afedynitch We can add some precomputed file to the Pythia8 zip file, for example those used in the unit tests, so that the unit tests run faster. However, we cannot cover all use cases of everyone, because we cannot predict how people use Chromo. Therefore, it is anyway needed to generate these cache files on demand. I see no issue with that and it is quite nice to have this functionality in place, as it speeds up Pythia8 a lot when you use it the second time for the same inputs. In practice that happens a lot. To elaborate why we cannot precompute everything: there is a large but countable set of input particles, but the cache files also depend on ECM, and that's a real number, so it is unbounded. |
Good news, the tests are all green, except an unrelated Sibyll23StarMixed failure.
This test also fails locally. @afedynitch @jncots How could it happen that this test was committed? We should never merge PRs with failing tests. In my opinion, this PR is a ready to be merged. Having the ability to simulate ion collisions with Pythia8 is a big improvement. Also thanks to the new caching, Pythia8 runs much faster. There are some issues with the cross section calculation that Chloe made me aware of, which should be tackled in another PR. What to precompute and to put in iamdata is also open, but we can iterate on that independently of this PR. |
For the record, locally on my computer also another test fails in addition to the Sibyll23StarMixed one:
|
Hi @gaudu, could you merge from main and see if the tests pass? We merged all of the features we wanted. |
Hi @afedynitch, I am still pretty new to git, just to make sure I understood you correctly. Does this mean I should merge my working branch (gaudu/chromo/pythia8310) into my main branch (gaudu/chromo/main) to see if the tests pass, and then you will go through the review of this PR? |
Ah, I see. please merge our main into the main of your fork. Then merge your main into your branch. This PR should then update automatically. Probably, you can merge our main directly into your branch but I remember having some weird problems doing this. If you succeed, then the conflicts message above should disappear. |
Oh, once you’ve done it, ‘install -e .’ locally and run ‘pytest -vv’. It should be better to run pytest locally after merging into your main to make sure that the errors you encounter later are not from your configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. Thanks for the progress. I left a couple of questions about things I’d like to understand better.
@gaudu @afedynitch I am trying to summarise the todolist for accepting this patch. Is this ok?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR is much improved and I'm happy with the featureset. The tests requrie a bit of work and still contain unfinished TODOs.
src/chromo/models/pythia8.py
Outdated
# Nuclei are supported in principle, but generation is very slow. | ||
# Support for more nuclei can be added with ParticleData.addParticle. | ||
_targets = _projectiles | { | ||
_targets = standard_projectiles | { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I've asked this already but what exactly is the reason for this explicit list and not just Nuclei()?
src/chromo/models/pythia8.py
Outdated
config.append("HeavyIon:SigFitDefPar = 10.79,1.75,0.30,0.0,0.0,0.0,0.0,0.0") | ||
if (kin.p1.A or 0) > 1 or (kin.p2.A or 1) > 1: | ||
config += [ | ||
# similar to MultipartonInteractions:reuseInit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here I'm struggling to follow the logic. If there is a file available for this combination of hA or AA, why is the caching switched off?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can find more information about this topic following this website (https://pythia.org/latest-manual/HeavyIons.html) and scrolling to the section for "Subcollision models".
It seems the default Pythia 8 settings, for the SubCollisionModel in Angantyr, is "HeavyIon:SigFitDefPar = 17.24,2.15,0.33,0.0,0.0,0.0,0.0,0.0"
. While the one, you highlighted in the code, might have been computed for another (heavy ion) run that I showed to Hans during a previous call (so most likely for negative pion boosted for 158 GeV/c onto a fixed carbon target using Angantyr).
src/chromo/models/pythia8.py
Outdated
@@ -161,28 +181,60 @@ def _cross_section(self, kin=None): | |||
diffractive_axb=st.sigmaAXB, | |||
) | |||
|
|||
# TODO use pythia.info.sigmaGen(i) for cross-sections including nucleus in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The text is somewhat difficult to follow. Is it possible to word it a bit better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can try to rephrase it here, or would you rather I try to modify the TODO itself in the code?
src/chromo/models/pythia8.py
Outdated
# to speed up subsequent runs | ||
cache_prefix = str( | ||
_cache_base_dir() | ||
/ "Pythia8" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the base directory be an optional parameter? If that would be possible then the cache files could be stored as part of the test suite and then nuclei could be tested much faster.
|
||
event = run_collision(2000 * GeV, "p", (4, 2)) | ||
assert event.pid[0] == 2212 | ||
@pytest.mark.parametrize("projectile", ("pi-", "K+", "p", "He")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use precomputed cache here? The tests with He take very long time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this linked to the four files you updated in your previous commit "Add reference files for Pythia8 with He projectile"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I meant that this test should use the cache files supplied with the binary data package in iamdata as @HDembinski suggested.
tests/test_pythia8.py
Outdated
m = Pythia8(evt_kin, seed=1, cache=True) # False | ||
config_lines = "\n".join(m._config) | ||
assert "MultipartonInteractions:reuseInit = 3" in config_lines # 0 | ||
# TODO Test for the cache file production for pp@10GeV when we have agreed on the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name choice is fine I guess, so the test can be completed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to implement a second part to the test where it asserts the path of the produced cache file, using the name choice made in pythia8.py, and the file size to be non zero to make sure the file is not empty.
tests/test_pythia8.py
Outdated
config_lines = "\n".join(m._config) | ||
assert "HeavyIon:SasdMpiReuseInit = 3" in config_lines # 0 | ||
assert "HeavyIon:SigFitReuseInit = 3" in config_lines # 0 | ||
# TODO Test for the cache file production for pHe@2TeV when we have agreed on the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. The name is fine. Regarding the caching request further up...I think that this test should be the only one generating and using the cache file. All other tests involving nuclei, should come with caches distributed.
These cache files should be in tests/Pythia8_caches/...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a slightly different opinion expressed in a comment below, I think the place for the natural place for these hard wired cache files is still in iamdata
I made few modifications in pythia8.py and test_pythia8.py recently which were unsuccessful at passing the macos and unbuntu tests at the step On another note, I would like to discuss where exactly we want to have/not have the cache files for (a) the tests, (b) the users? Mostly to know how to answer to @afedynitch comments:
|
I have been silent here for a while, but I kinda like the idea of making the cache directory a parameter. Since we anyway want to allow users to turn this feature off and instead of passing a boolean we might as well pass a string (the path) or On the other hand, I don't see a fundamental difference between these cache files that we generate ourselves and the hardwired ones that we distributed in |
I was not aware of the distribution of some default cache files within the binary package... in that case I agree that the natural place for these files to live is within the iamdata directory. |
|
||
event = run_collision(2000 * GeV, "p", (4, 2)) | ||
assert event.pid[0] == 2212 | ||
@pytest.mark.parametrize("projectile", ("pi-", "K+", "p", "He")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I meant that this test should use the cache files supplied with the binary data package in iamdata as @HDembinski suggested.
tests/test_pythia8.py
Outdated
cache_file_path = os.path.join( | ||
_cache_base_dir(), "Pythia8", "cache_2212_2212_10000.mpi" | ||
) | ||
assert os.path.exists(cache_file_path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a set of default cache files are provided in iamdata, this test would just check if these files are there or not. This has to be made sure that this test generates something that's not in the default files.
tests/test_pythia8.py
Outdated
assert "HeavyIon:SigFitReuseInit = 3" in config_lines | ||
|
||
cache_file_path = os.path.join( | ||
_cache_base_dir(), "Pythia8", "cache_2212_1000020040_2000000.mpi" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of these generated files are very simple. It would be better to actually compare the contents of the sigfit file by comparing open(fname,"r").read()
of the newly generated file with concrete content such as
1 2000 2000
18.3948
1.90724
0.357502
This would allow to track (partially) if cache files need updating after Pythia version updates or so.
# This test is very slow the first time when Pythia is computing | ||
# some cached results. Afterwards it runs super fast. | ||
ecm = 2000 * GeV | ||
event = run_collision(ecm, projectile, "He") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here the cache should be enabled using files distributed via the binary package in iamdata.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only a few items to go. Please also pull from the latest master after #189 is merged.
Sorry, I think I was not clear. Currently, we don't have cache files for the new mpi-stuff in the iamdata directory of Pythia8, but I think that's the place where we should put those cache that we want to use for our unit tests. If we go for that , we have to generate these files and then add them to a new version of the iamdata_v001.zip, and change our code that it finds them. What we have in there currently is a Pythia8 directory with data files that Pythia8 needs, like the information about particles known to Pythia8, etc. These are not strictly cache files, but data files that Pythia8 needs. I think that the new cache files would nicely fit in there, as they are also "data". This is analog to QGSJetII, where the corresponding iamdata directory essentially contains a huge binary cache file that QGSJetII can in principle re-create, but we never do that as it takes too long. |
…PI and HeavyIon runs.
…nmatched version numbers : in code 8.310 but in XML 8.308.
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…he file production using cache flag during init + tests
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
a1f18e2
to
882570e
Compare
Attempt to solve #171 with @HDembinski ⚡