feat(records): add LHCb Run2 ntuples B2JpsiK#3777
feat(records): add LHCb Run2 ntuples B2JpsiK#3777tiborsimko merged 1 commit intocernopendata:masterfrom
Conversation
| "run_period": [ | ||
| "2016" | ||
| ], | ||
| "stripping": { |
There was a problem hiding this comment.
Note that I had to take out "line" here, because strict metadata checking was not allowing it. We'll have to exchange data model in the cernopendata-portal repository to add it, and then release a new version of the portal. This takes time and can be done later.
There was a problem hiding this comment.
I think I just modeled this after our hackathon example. But that is all good with me, thanks!
| { | ||
| "checksum": "adler32:72da1c95", | ||
| "size": 92561, | ||
| "uri": "root://eospublic.cern.ch//eos/opendata/lhcb/CollisionNtuples/OPENDATA.LHCB.EBYF.C7OY/outputs/knowledge-graphs/Btree.html" |
There was a problem hiding this comment.
I have added also the knowledge graph output to the request. Does it make sense?
OT1H, it is nice for people to be able to visualise production configuration upfront?
OTOH, perhaps I should leave them out, since knowledge graphs are kind of "outputs" strictly speaking, and we may in the future amend the graph generation so they may look different?
There was a problem hiding this comment.
Hmm good, thinking, they may be subject to change, so maybe we should leave them out? Honestly I am fine with either option.
There was a problem hiding this comment.
OK taking them out...
| }, | ||
| { | ||
| "abstract": { | ||
| "description": "Data from proton-proton (pp) collisions collected by the LHCb experiment filtered to produce ntuples." |
There was a problem hiding this comment.
BTW here and elsewhere the description seems a bit cut. Can you complete the sentense mentioning B -> J/psi K and such?
Compare the current version:
with what we had for the hackathon:
There was a problem hiding this comment.
I don't have a great physics motivation for choosing this channel other than it being well understood and what I am using for my analysis.
I would just edit to say "filtered to produce ntuples for exploring $B^{\pm}
\to J/\psi (\to \mu^{+} \mu^{-}) K^{\pm}$ decays."
| "url": "https://lhcb-opendata-guide.web.cern.ch/ntupling-service/" | ||
| }, | ||
| { | ||
| "description": "First LHCb Open Data and Ntuple Wizard Workshop", |
There was a problem hiding this comment.
Instead of linking to the workshop, shall we add to the usage example instead? https://github.com/reanahub/reana-demo-lhcb-run2-b2jpsik (Or perhaps in addition to?)
There was a problem hiding this comment.
I think we should add it in addition. Feel free to list it before the workshop.
| ], | ||
| "magnet_polarity": "MagUp", | ||
| "methodology": { | ||
| "description": "<p>These ntuples were produced from the LHCb Open Data Ntupling Service user request 175. Please see the input configuration files <a href=\"/record/93909\">here</a>.</p>" |
There was a problem hiding this comment.
BTW one important remark. Request 175 was done on the DEV ntupling service, so it does not fully make sense in the PROD service. It could happen that there will be another request 175 on PROD in the future, which will be different from this one.
Shall we try to enumerate the requests based on Analysis Productions merge request IDs, which are unique regardless of whether people arrive from DEV, QA or PROD? That might be safer... But also users might wonder how this "magic" number came to be, since they don't really see it on the web interface request lists.
There was a problem hiding this comment.
I see your point. Using the Ana Prod MR ID is fine with me. As far as I can tell, we just added this number in as a way of keeping track for ourselves.
| "number_files": 4, | ||
| "size": 95312 | ||
| }, | ||
| "doi": "10.7483/OOPENDATA.LHCB.EBYF.C7OY", |
There was a problem hiding this comment.
I have added DOI only for the umbrella request so far. Do we want to add a different DOI to each dataset coming out of this request? Would they be citeable separately?
There was a problem hiding this comment.
Personally I think adding a DOI for the umbrella request would be enough. I suppose in cases with requests that span across multiple datasets there may be a use case for citing them separately, but I am not sure if we should worry about that. Having a DOI for the request still covers the requirement for citing the data.
tiborsimko
force-pushed
the
lhcb-run2-ntuples-b2jpsik
branch
from
8361f46 to
e5fb4da
Compare
tiborsimko
force-pushed
the
lhcb-run2-ntuples-b2jpsik
branch
3 times, most recently
from
860eb6b to
a6f6f09
Compare
tiborsimko
force-pushed
the
lhcb-run2-ntuples-b2jpsik
branch
from
a6f6f09 to
1fe539a
Compare
2 participants
No description provided.