You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The MC part of the AOD producer workflow
`o2::aodproducer::AODProducerWorkflowDPL` and
`o2::aodmcproducer::AODMcProducerWorkflowDPL` is refactored to use
functions from namespace `o2::aodmchelpers`. The helpers are
- `updateMCCollisions` which takes in the `MCEventHeader` and writes to
the `o2::aod::McCollisions` table.
- `updateHepMCXSection` which takes the `MCEventHeader` and writes to
the `o2::aodHepMCSections` table. This uses the predefined key
constants as defined in `o2::dataformats::MCInfoKeys`
- `updateHepMCPdfInfo` similar to `updateHepMCXSection` above
- `updateHepMCHeavyIon` similar to `updateHepMCXSection` above
- `updateParticle` uses information from an `o2::MCTrack` and writes it
to the `o2::aod::McParticles` table
- `updateParticles` loops over `o2::MCTrack` objects and calls
`updateParticle`.
These functions, in particular `updateHepMC...` uses the functions
- `hasKeys` which checks if the `MCEventHeader` has any or all of the
keys queried.
- `getEventInfo` gets auxiliary information from the `MCEventHeader` or
a default value.
For the `o2::aod::HepMC...` tables: Depending on the policy parameter
passed to the `updateHepMC...` functons, these tables may or may not be
updated.
- If the policy is `HepMCUpdate::never` then the tables are never
updated.
- If the policy is `HepMCUpdate::always` then the tables are _always_
updated, possibly with default values.
- If the policy is `HepMCUpdate::anyKey` (default) or `HepMCUpdate::allKeys`, then
the decision of what to do is taken on the first event seen.
- If the policy is `HepMCUpdate::anyKey`, then if _any_ of the needed
keys are present, then updating will be enabled for this and _all_
subsequent events.
- If the policy is `HepMCUpdate::allKeys`, then if _all_ of the needed
keys are present, then updating will be enabled for this and _all_
subsequent events.
Note that the availability of keys is _not_ checked after the first
event.
That means, if the criteria isn't met on the first event, then
the tables will _never_ be update (as if the policy was
`HepMCUpdate::never`).
On the other hand, if the criteria was met, than the tables _will_ be
update an all events (as if the policy was `HepMCUpdate::always`).
Note the slightly tricky template `TableCursor` which allows us to
define a type that correponds to a table curser (which is really a
lambda). This template could be moved to `AnalysisDataFormats.h` or
the like.
The applications `o2-aod-producer-workflow` and
`o2-aod-mc-producer-workflow` have been updated (via their respective
implementation classes) to use these tools, thus unifying how the MC
information is propagated to AODs.
The utility `o2-sim-mctracks-to-aod` (`run/o2sim_mctracks_to_aod.cxx`)
has _also_ been updated to use these common tools.
Both `o2-aod-mc-producer-workflow` and `o2-sim-mctracks-to-aod` has been
tested extensively. `o2-aod-producer-workflow` has _not_ been tested
since it is not clear to me how to set-up such a test with limited
resources. However, since the changes _only_ effect the MC part, and
that part is now common between the two `o2-aod-{,mc-}producer-workflow`
applications, I believe there is no reason to think that it wouldn't
work.
fmt::format("{}{}", requestContext.considerSnapshot ? "load to memory" : "retrieve", fromSnapshots.at(i) ? " from snapshot" : ""));
1695
1704
if (requestContext.considerSnapshot && fromSnapshots.at(i) != 2) {
1696
1705
saveSnapshot(requestContext);
1697
1706
}
@@ -1773,6 +1782,9 @@ void CcdbApi::loadFileToMemory(o2::pmr::vector<char>& dest, const std::string& p
1773
1782
if ((isSnapshotMode() || mPreferSnapshotCache) && localHeaders->find("ETag") == localHeaders->end()) { // generate dummy ETag to profit from the caching
1774
1783
(*localHeaders)["ETag"] = path;
1775
1784
}
1785
+
if (localHeaders->find("fileSize") == localHeaders->end()) {
0 commit comments