Comments (6)
Simon actually suggested exactly what I had suggested at the reconstruction meeting :) Including the number 10 to add. Great minds and all that.
Not a coincidence, just decided to write the github issue before you!
We will have to develop tests alongside this to make sure it works as expected for various generators and maybe request some changes to the HepMC code too.
from afterburner.
Do I undrstand correctly, that what you want is to copy all beam and final state particles at their vertexes prior to applying beam effects and store them with custom codes (like 14 and 11 in your example)?
A bit of a problem I am seeing here is that we should not only care about 4 and 1 codes as depending on generators in the very general case we have to care about everything to keep HepMC event consistent and openable. HepMC presents event as a connected graph. Unfortunately, if you break the structure of the graph in a non intended by HepMC way (with ZERO documentation about it) you may have problems. When something is broken that way, HepMC may save the resulting event without any warnings, but eventually one would have problem reading the event or, what is even worse, it will be read, but particles and vertexes will not match with what was written.
from afterburner.
Maybe @kkauder can comment on this as I know he had also pretty extensive experience on HepMC and its pitfalls.
from afterburner.
If we assume that we shouldn't break the graph and copy everything. Hm... Adding 100 may look more natural. Having 100 as unstable particle, 101 as stable, 104 as beam etc.
from afterburner.
Simon actually suggested exactly what I had suggested at the reconstruction meeting :) Including the number 10 to add. Great minds and all that.
I'll say, if we go this route, let's brainstorm just a tad bit more to see if there's anything else we'd like to encode in this number. All generators I'm aware of stay well below 100, so something like orig + 10 + 100 * (some code) + 10000 * (some other code)
could work. Could allow something like identifying background sources without having to use the vertex status code
from afterburner.
Oh, and yes, 100 as the base offset is better and more easily interpreted. Thinking a bit more about my previous comment, 1000+ may or may not work. It's not legal HepMC-wise, but may work anyway. Best not to depend on it though and if we want to encode more, make a less readable but legal construction that squeezes status codes somewhere below 200
from afterburner.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from afterburner.