Chromo release 0.4

[jncots]

This is a PR towards chromo's 1.0 release. I hope it should be quick. There are a couple of issues.

• The biggest current issue is #127. It is a problem for the source code, but wheels should work. This should be ignored for this release.
• There is a small bug #163 which I will fix.
• Licenses:

  DPMJet/PhoJet -> Anatoli Fedynitch
  EPOS -> Tanguy Pierog and Klaus Werner  (permission of  usage)
  Sibyll -> Felix Riehn (permission of usage)
  QGSJet -> Sergei Ostapchenko (permission of usage)
  UrQMD-3.4 - ?
  Sophia - ?
  Pythia6 - ?
  Pythia8 - GPL2.0

  Anatoli suggested to put 3 permissions to corresponding source code directories. I guess license.txt with something like:

Sibyll- Redistribution Notice

This software is distributed as part of "Chromo" with the permission of the original author. Please refer to the original license for terms and conditions. No warranty provided.

should be fine.

What else should be done for release?

[jncots]

The above fixes #163 + tests.

[jncots]

Preliminary versions of licenses have been added as described above.

[afedynitch]

I added a couple of (hopefully) trivial commits. The summary is:

• In CMake, detect Ninja and don't pass -cpp flag since Ninja always cpps stuff, what results in double preprocessing and massive trailing ' character warnings in comments, slowing down compile time
• I extended the lists of supported projectiles to what was before in impy. There is no easy algorithmic way to add these and that's why the lists became longer
• I merged the trivial changes from the gamma_p branch for pythia8 photon support. I actually was working on gamma-gamma, which requires a specialized kinematics class that doesn't calculate lab kinematics, is WIP, and not merged here.
• Support was added for development versions of SIBYLL, in the same way as it is there for development DPMJETs

Hope that's it.

[HDembinski]

@afedynitch Regarding the version number 1.0, please see #165 why I argue against going for a 1.0 at this point.

1.0 means you have a stable product with a stable API, while 0.x indicates that the API is not finalized yet. Our API is not fixed yet.

[afedynitch]

@afedynitch Regarding the version number 1.0, please see #165 why I argue against going for a 1.0 at this point.

1.0 means you have a stable product with a stable API, while 0.x indicates that the API is not finalized yet. Our API is not fixed yet.

Oh, I totally agree with that. It will be changed. But since there is an interface change in kinematics between the pypi and even the current main, we should bump it up to 0.4. There are also now some additional changes that would justify upping the minor version.

I'm looking into #160 now, and there are some warnings in test about decays in PHOJET & DPMJET, which shouldn't be there. All of these models can decay the same stuff as PYTHIA6, since this is what is used for decays.

I would prefer getting the final state stuff unified, it is quite important. Then merge it into main, and rebase of FF this PR onto the latest main. Target time is for this one is some time next week, since we removed the --pre flag from the poster ;).

[afedynitch]

So in principle, this seems complete. We should try to finalize the #169 PR, and possibly #167, and merge those before proceeding here.

[jncots]

Dear @HDembinski, @afedynitch, we currently have 6 open PRs that are nearly ready for merging.

Proposed Merging Order:

• [x] Sibyll* - Approved ✅

  • Added the Sibyll23Star model.
  • Included cross sections.

• [x] Test of Final State - Ready for Merging ✅

  • Addressed fixes for PhoJet and DpmJet stable/unstable settings.

• [x] Unified Treatment of Beam Particles - Review Required ❗

  • Enables reading/writing to HepMC files.

• [x] Pythia8 Afterburner - Review Required ❗

  • Validated if particles requested for decay have indeed been decayed, decaying undecayed particles

• [x] Stop F2PY Caching - Review Required with Unresolved Conversations ❗

  • Resolved issues related to f2py pyf file generation.

• [x] Chromo Release 0.4 PR - To be Closed After All the Above

[jncots]

@HDembinski, while working on #170 I noticed that it would be good to have the following changes in graphviz and HepMC:

• graphviz don't show loops, i.e. multilple particles cannot originate from one vertex and then merge to another. If such situation occurs, then only there first particle is displayed, all other are missing
• HepMC accepts indexing starting from 1 and breaks down if 0 appeared in history. Now to_hepmc3 adds +1 to all mothers and daughters. I remember that you wrote somewhere that you could change indexing in hepmc starting from 0.

Should I submit both of these issues to Hepmc github?

[HDembinski]

graphviz don't show loops, i.e. multilple particles cannot originate from one vertex and then merge to another. If such situation occurs, then only there first particle is displayed, all other are missing

If I remember correctly, this is not only an issue with graphviz but already with HepMC3, which models the event as a directed acyclic graph, so loops are not supported. I think it is unfixable and we need a workaround, as before. So far I used the workaround to remove all the preshower history when converting from a Pythia event to HepMC3. Is there an issue with this workaround after your changes?

[HDembinski]

Should I submit both of these issues to Hepmc github?

I will fix the indexing issue in pyhepmc now, no need to add an issue. I cannot fix the other thing with the cyclic graphs, so it won't help to add an issue there.

[jncots]

Is there an issue with this workaround after your changes?

The problem with cyclic graph appears in Phojet and Dpmjet. As a workaround, when conversion to hepmc occurs, only the beam and final particles are used. I hope that we will figure out how to write the whole history later.

[HDembinski]

The problem with cyclic graph appears in Phojet and Dpmjet. As a workaround, when conversion to hepmc occurs, only the beam and final particles are used. I hope that we will figure out how to write the whole history later.

This is worse than the workaround I use for Pythia. In Pythia, I only have to remove the preshower information, which is acceptable, because as an experimentalist you cannot exploit this information. The decay history of short or long-lived particles is kept, however, which one frequently needs as an experimentalist. It would be great to keep the decay history in DPMJet / PhoJet as well.

[jncots]

This is worse than the workaround I use for Pythia.

I agree. I will try to fix it.

[afedynitch]

Dear @HDembinski, @afedynitch, we currently have 6 open PRs that are nearly ready for merging.

Proposed Merging Order:

• [ ] *Sibyll - Approved** ✅ ....

The order is fine. Please start merging one by one

[HDembinski]

@jncots A release of pyhepmc with the required extension is currently running https://github.com/scikit-hep/pyhepmc/releases/tag/v2.13.0. If all goes well, it will be online on PyPI in about an hour. To use it in chromo, you need to use the new keyword fortran=False wherever you call the GenEvent.from_hepevt method.

[jncots]

@jncots A release of pyhepmc with the required extension is currently running https://github.com/scikit-hep/pyhepmc/releases/tag/v2.13.0.

@HDembinski, excellent! Thank you.

[HDembinski]

@jncots There were some issues with the release job due to outdated CI action scripts, but now the updated pyhepmc package is available on PyPI. https://pypi.org/project/pyhepmc/

[jncots]

@HDembinski do we need python3.8 on Linux? If yes, then https://pypi.org/project/pyhepmc/2.13.2/#files doesn't have version for python3.8 and it should be added.

[jncots]

@afedynitch, do we need to fix #177 and #178 for the release?

[afedynitch]

@afedynitch, do we need to fix #177 and #178 for the release?

Does or prevent HEPMC+RIVET from functioning?

[jncots]

Does or prevent HEPMC+RIVET from functioning?

No, HEPMC+RIVET works fine. For Phojet there is no history, but it is not so critical. For Dpmjet intermediate particles has wrong energies, so they are end up in HEPMC.

[afedynitch]

Does or prevent HEPMC+RIVET from functioning?

No, HEPMC+RIVET works fine. For Phojet there is no history, but it is not so critical. For Dpmjet intermediate particles has wrong energies, so they are end up in HEPMC.

Ok, then this is not critical for this release. We’ll do it in the next release.

I’ll go through the review a bit later today, so we can merge this soon

[afedynitch]

Overriding @HDembinski review, because the main criticism was directed toward version 1.0. Now it’s 0.4, so should be fine