Project

General

Profile

Feature #10539

Make FindOne<ProdB> work whether the association was made with or without metadata

Added by Tingjun Yang about 5 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Category:
I/O
Target version:
Start date:
10/14/2015
Due date:
% Done:

100%

Estimated time:
40.00 h
Spent time:
Scope:
Internal
Experiment:
LArSoft
SSI Package:
art
Duration:

Description

Dear artists,

We have a feature request about association. Currently if an association was made without metadata, we need to do the following to retrieve it

FindOne<ProdB>(Handle<ProdAColl> const &,
               Event const &,
               InputTag const &);

If the association was made with metadata, we need to do the following:
FindOne<ProdB, Data>(Handle<ProdAColl> const &,
                     Event const &,
                     InputTag const &);

It would be convenient if FindOne<ProdB> can be used to get association made with metadata. Of course the metadata will be ignored in this case.

Here is one user case. We plan to make hit-track association with metadata. But there is a lot of code in larsoft that retrieve hit-track association through FindOne or FindMany without specifying metadata. If the above feature is implemented, we do not need to change the existing code to make it work with the new association.

Thanks,
Tingjun

History

#1 Updated by Christopher Green about 5 years ago

  • Tracker changed from Support to Feature
  • Category set to I/O
  • Status changed from New to Accepted
  • Estimated time set to 40.00 h
  • SSI Package art added
  • SSI Package deleted ()

This is an eminently sensible request, and we have a sketched-out conceptual solution.

#2 Updated by Christopher Green about 4 years ago

  • Description updated (diff)
  • Status changed from Accepted to Feedback
  • Assignee set to Christopher Green
  • Target version set to 2.06.00
  • Experiment LArSoft added
  • Experiment deleted (-)

During the preliminary analysis of this issue, we have a couple of scenarios (thus far) that might cause ambiguity when reading older files:

Scenario A

Module labeled L1 writes an art::Assns<A, B> with instance name I1 in process X, while in later process Y, a module also labeled L1 writes an art::Assns<A, B, D> with instance name I1. What happens if a subsequent module in the same or a later process requests an Assns<A, B> with input tag L1:I1, either directly, or via a request for a FindXXX<A> or FindXXX<B>?

Our preferred resolution of this ambiguity would be that the data product from process Y would be selected. However, this is a change in behavior from previous and current versions of art, where the data product from process X would be selected.

Scenario B

Module labeled L1 in process X writes an art::Assns<A, B> with instance name I1, and an art::Assns<A, B, D> with the same instance name, I1. If a subsequent module in the same or a later process requests an Assns<A, B> with input tag L1:I1 (directly or otherwise), what should happen?

Our preferred resolution of this question would be that the art::Assns<A, B> would be selected at the expense of the art::Assns<A, B, D>. This is in fact the same behavior as previous and current versions of art.

Requested feedback

Please let us know whether the suggested solutions are acceptable to you. Note that other behaviors could be programmed, including the testing for and warning of the conditions above. It's possible that the tests required might add an overhead over and above the default behavior, however.

#3 Updated by Tingjun Yang about 4 years ago

Hi Chris,

Thanks for the suggested solutions. They sound good to me but I would like larsoft experts (e.g. Gianluca) to comment on this.

To me, if some code is requesting Assns<A,B>, it would make sense to return Assns<A,B>, if that is not available, return Assns<A,B,D>. If neither is available, throw an error.

Tingjun

#4 Updated by Christopher Green about 4 years ago

Gianluca has been added to the watch list, and we will explicitly request his input via email.

For us, the biggest worry is that we get consistent matching behavior when products are in the same file but different processes. We feel that someone putting an Assns<A, B, D> into the event could reasonably expect it to supersede an earlier Assns<A, B>. The simple rule would be that a match from the current process is returned when available; the requested behavior is for an Assns<A, B, D> to match when an Assns<A, B> is called for, and special cases tend to lead to complications and erroneous assumptions.

#5 Updated by G2Muon G2Muon about 4 years ago

About the previous comment - my recommendation is that if there are two candidates, distinguished only by process name, then the behaviour should be to require a process name or throw an exception. I would not try to guess which of the other solutions others might think is the natural default.

#6 Updated by Rob Kutschke about 4 years ago

... about the last comment - it was really from me( kutschke). I was logged into redmine as G2Muon (Adam shared it with me ages ago ....)

My apologies for the confusion.

#7 Updated by Marc Paterno about 4 years ago

The standard procedure to find a product, when a process name is not provided, looks at the product type and the specified module label (and instance name if provided). If exactly one matching product is found "in the current process" (which means produced by a module in the current process), it is returned. If there is more than one matching product, an exception is thrown. If there are no matching products, then the process history is consulted, and we effectively walk back in time through earlier processes, looking for a process in which there is one match (yielding success) or in which there are multiple matches (again, an exception throw). If no matching product is found in any process, the result is an exception (if getValidHandle is being used) or an invalid Handle (of getByLabel is being used).

If a process name is provided, then only that process is searched.

The documentation in the workbook is consistent with this, but does not describe the whole issue; I believe it is a later planned-but-not-written exercise that would go into these details. The details are most important in re-reconstruction scenarios.

#8 Updated by Rob Kutschke about 4 years ago

I intended my initial comment to be limited to a request for an ambiguously specified data type - not as a request for a change to the present behaviour for all requests. I see now that I did not make that clear.

Suppose I have a file with
Assns<A,B,D> current process
Assns<A,B> older process

What should happen on a request for Assns<A,B> with no process name specified? Did I mean that I want any product usable as Assns<A,B> with the usual rules about the current process being the default? Or did I mean that I want the type Assns<A,B> exactly, without regard to process name.

Because art has no way of knowing which request you meant, it should throw an exception.

On the other hand, if the event contains only one of these two data products, then there is no ambiguity and art can return an answer.

Or do you consider this creating a special case?

#9 Updated by Marc Paterno about 4 years ago

Our proposal is for the case you describe:

1. Assns<A,B,D> created in the current process
2. Assns<A,B> product in the input file, as it must be if created in an older process

would be that a lookup of Assns<A,B> would find the Assns<A,B,D>, because it would be considered "a match". This is a change in behavior, because currently that is not considered as a match.
This is like all current behavior in one way, and unlike in another. It is like current behavior because it is returning the match from the most recent process in which one is found. It is unlike current behavior in that the match is not for an identical type. However, since Assns<B,A> is a different C++ type than Assns<A,B>, yet satisfies the same lookup, it is already the case that the lookup rules for Assns are special. We are proposing an extension of the specialness, to include a lookup of Assns<A,B> matching an object of type Assns<A,B,D>.

#10 Updated by Gianluca Petrillo about 4 years ago

Reading through, I can't find a reference to what happens on a request of art::Assns<A, B> when only art::Assns<A, B, D1> and art::Assns<A, B, D2> with the same input tag are available from the same process.
I would assume an exception will be thrown.

#11 Updated by Kyle Knoepfel almost 4 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

Analogous improvements to gallery have not been scheduled.

#12 Updated by Kyle Knoepfel almost 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF