202nd ROOT Parallelism, Performance and Programming Model Meeting

→ Europe/Zurich
32/S-C22 (CERN)

32/S-C22

CERN

17
Show room on map
Stephan Hageboeck (CERN), Vincenzo Eduardo Padulano (CERN)
Zoom Meeting ID
66227961514
Host
Stephan Hageboeck
Useful links
Join via phone
Zoom URL

ROOT PPP 03.09.2026

  • [Stephan]: Are the RNTupleProcessor classes polymorphic?

    • Yes
  • [Stephan]: when you create a combined processor, do you need to give ownership of the input processors to the combined one?

    • Yes, all constructors accept std::unique_ptr. This is done to avoid inconsistencies while processing events (the driver of the loop is the "main" processor (i.e. the leftmost one in the combination)).
  • [Martin]: How many columns can you join on?

    • Up to four
  • [Philippe]: Do you have a clone/copy mechanism?

    • Not yet
  • [Philippe]: The current processor number, or the equivalent in TChain is used for two completely different purposes: one is to detect a file transition, the other is to know which is the current file if the user want to do something different depending on that.

    • For the first case, that's an internal thing now and doesn't need to be public, the second one could be a use case
    • [Jakob] but the underlying item is not a file now, it's another processor, so the semantics are unclear.
  • [Philippe] what is the difference between GetCurrentEntryNumber and GetNEntriesProcessed?

    • For now, nothing. But for example in MT scenarios they could be different
    • [Vincenzo] or also if we allow sparse reading
  • [Jakob] I think we should start with all private interfaces except those for which we have evidence that it's necessary

  • [Philippe]: Having to advance an iterator for a million events is more expensive than the user telling us they want to go to entry one million, in the latter case we can just skip entire files.

  • [Jakob/Stephan]: Maybe not loading random entries but advancing by more than one entry sounds like an important feature.

    • [Stephan] your iterator could accept an integer such that calling std::advance on it could make it jump by that number.
  • [Vincenzo]: What happens with BindRawPtr?

    • This introduces some unsafety.
    • [Vincenzo]: could we also have a std::shared_ptr interface?
    • [Jonas]: depends on what use case we want to cater, shared_ptr may have some benefit
  • [Vincenzo]: how thorough is the tracking of fields in the datasets of the internal RNTupleProcessorEntry? For example, I have two chains and I join them together. A certain column x is present now in a file of the left chain and then in a file of the right chain

    • [Philippe] the use case defined above may actually exist, we have seen this in TTree.
    • [Vincenzo] I believe with a carefully crafted set of join and chain combinations, this could work with the RNTupleProcessor but only if we relax the requirement of the auxiliary dataset prefix
    • [Florine] I'll get to that later, but also I don't like anything about this use case.
    • [Jakob] I would at least note it down, maybe it's an advanced use case but doesn't sound completely crazy to me.
  • [Stephan]: naming of the kUseAuxPrefix flag, maybe we can change it to something more clear to users

    • Like kRequireAuxPrefix
    • [Jonas] For example kLazyNameMatching
  • [ Jonas] coming back to that situation above, should we check in all processors or just in the first set?

    • Currently it checks only in the first RNTuple, maybe we can add a deep search?
    • [Jonas] I'm worried about the fact that if you specify the prefix, for that case the order doesn't matter
    • [Jakob] Couldn't we have something like an alias definition or a rename definition? For this particular processor instance, that field is called something else
    • Whats the benefit?
    • [Jakob] I'm wondering if we could have a more general interface that lets us as a side effect disambiguate better.
    • [Stephan] I don't see how the renaming would make things safer.
    • [Jakob] For these advanced use cases, we should avoid designing API such that it forbids the use case altogether.
  • [Stephan] Checking name conflicts sounds like you have to check the entire chain a priori, can you do it on file change?

  • [Vincenzo] I wanted to ask for a clarification about the use case, my understanding is this is done for when the user expects a certai column name to be there, irrespectively of whether there are multiple joins, or whether there was a previous processing that led to merging fields and having one RNTuple on disk with the column already available

    • Yes
  • [Jonas] For final point 4, that also includes persistifying join table?

    • At some point, it's a separate point I didn't include.
    • [Philippe] persistifying the table is "trivial"
    • Not sure if it is
There are minutes attached to this event. Show them.
    • 16:00 → 16:30
      Discussion on the RNTupleProcessor 30m
      Speaker: Florine Willemijn de Geus (CERN/University of Twente (NL))