MetaInfo for get commands

At least getUnfHist doesn't add itself to the metainfo. It should do so.

Isn’t the tree saved? (With 0 entry)

added Needed? label

added to epic &3

Yes but the getUnfHist command isn't added to the metainfo:

(CMSSW_12_4_0) mourelou@naf-cms16:/nfs/dust/cms/user/mourelou/darwin/data/mumugamma$ printMetaInfo M9_applyNormFactor/DYJetsToMuMu/getUnfHist.root /dev/stdout
Warning: you are overwriting "/dev/stdout"
...
history
{
     ...
     "submit M8_applyPhotonCSEV/DYJetsToMuMu/applyPhotonCSEV /nfs/dust/cms/user/mourelou/darwin/data/mumugamma/M7_applyPhotonID/DYJetsToMuMu M8_applyPhotonCSEV/DYJetsToMuMu/ /nfs/dust/cms/user/mourelou/darwin/Darwin/tables/Egamma/Photon_CSEV_UL18.root -j 32 -f -s"
     "parallel M9_applyNormFactor/DYJetsToMuMu/applyNormFactor /nfs/dust/cms/user/mourelou/darwin/data/mumugamma/M8_applyPhotonCSEV/DYJetsToMuMu M9_applyNormFactor/DYJetsToMuMu// 0.000667244429 -j 32 -f"
}
...

removed Needed? label

added To Do label

added changepatch typesoftware labels

added upstreamDarwin label

Since we now have TTree friends, we could abuse of this technology and make TTree friends in getters without any new branch. This would still give access to the original trees interactively when opening the file and allow to use the exact same tools...

Interesting idea, this also means we could run getDimuonSpectrum on the unfolded output with guaranteed consistency. The "empty" trees would still need to be Fill()ed once for every event.

There is one potential drawback, which is running on a folder that has both the actual trees and the output of some get command. We'd then get duplicated events without warning, while I think it simply crashes currently.

Interesting idea, this also means we could run getDimuonSpectrum on the unfolded output with guaranteed consistency. The "empty" trees would still need to be Fill()ed once for every event.

Right. To avoid confusion, can we rather put the tOut->Fill() statement in the Looper, so that we would rather "remove" it (visually speaking) from the other commands? Fill()ing the tree in an apply* command is obvious. I'm not sure that continue statements would prevent from filling the tree, though, thus skimmers will keep the total number of events (proposed solution: just empty all collections).

Ok, this possibly solves the cases of "primary" getters (the ones that run on a n-tuple), but there are also "secondary" or "indirect" getters (the ones that run on the output of a primary getter), where there is no event loop. There are two cases to consider:

1. A sequence such as getJetResponse, fitJetResponse, fitJetResolution. In this case, it would be good to clone the tree, but I'm not sure to see how to proceed. Perhaps it is as simple as calling TTree::CloneTree() with the total number of entries after deactivating all branches, but this is so far pure speculation.
2. Two sequences joining, such as getUnfHist (for both real and simulated samples), followed by unfold and getUnfPhysDist. I think that the solution from the first case should work too, but certain print* commands will only see the first of the trees.

There is one potential drawback, which is running on a folder that has both the actual trees and the output of some get command. We'd then get duplicated events without warning, while I think it simply crashes currently.

Flow looks for a TTree named events. I would simply propose to rename the tree.

Also need to consider the hadd behavior.

Perhaps an easier way is to have an InputChain function somewhere that reconstructs the chain, pulling the necessary data from the MetaInfos.

Also need to consider the hadd behavior.

Not sure what you are exactly thinking about.

Perhaps an easier way is to have an InputChain function somewhere that reconstructs the chain, pulling the necessary data from the MetaInfos.

One may want to combine samples of different origins together.

Ok, but hadding samples of different origins is not good from the point of view of the MetaInfo, so perhaps we should forbid it...

Not sure what you are exactly thinking about.

hadd -f getDimuonSpectrum.root getDimuonSpectrum/*.root

-> the tree in getDimuonSpectrum.root needs to refer to all input trees of the getDimuonSpectrum/*.root.

One may want to combine samples of different origins together.

Fine, tag them with a label... e.g. GetInputChain("data"), GetInputChain("MC") for unfolding.

So given all the complications introduced by this proposal, I think it should be handled in another issue to avoid derailing this one (further).

So given all the complications introduced by this proposal, I think it should be handled in another issue to avoid derailing this one (further).

I would probably call that issue "MetaInfo for get commands". So let's continue here.

-> the tree in getDimuonSpectrum.root needs to refer to all input trees of the getDimuonSpectrum/*.root.

That's exactly why I suggested to change the name: then in case of hadd or cmd dir/*.root, the same events are not double-counted.

closed

moved to Proto/Darwin#82

mentioned in issue #162