Support #3549

running modules with same label

Added by Gavin Davies almost 8 years ago. Updated over 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
SSI Package:


We have been bitten by this particular feature (not sure it is a bug) for NOvA production.

Essentially we ran a module with the label "slicer" and process_name Batch.
A subsequent job also ran the same module with the same "slicer" label but process name LEMPre.
The Assns made with this particular module were only picked up by downstream modules from the second instance. The first instance is completely ignored by subsequent modules that use getByLabel("slicer",handle). This deemed anything processed with the first label inaccessible via Assns.

Correct me if I'm mistaken but at one time, if a user did this ART threw an exception about not being able to run a previously processed module?
I can solidify this with a concrete example of our exact issue if that is needed.

Perhaps this is a known feature but it is not a desired behaviour for the reason that one may inadvertently run the same module twice, perhaps in different process names as was the case here - not intentional. Perhaps we can discuss this further.


#1 Updated by Christopher Green almost 8 years ago

  • Category set to Navigation
  • Status changed from New to Feedback
  • Assignee set to Christopher Green
  • % Done changed from 0 to 90


This behavior is specifically allowed because of the stated desire to be able to produce, "new, improved" versions of a product that would be picked up in preference to the older data product where both are present. Otherwise an update product would always have to have a different module label and/or instance name, and the process name becomes redundant.

The exception-throwing behavior you describe occurs when one has a producer running in a job with process name X where the input already contains products produced with process name X.

I'm not sure what you mean by, "This deemed anything processed with the first label inaccessible via Assns." If you mean, "Can't access the contents of an Assns via Find{One,Many}{,P} specifying that as a reference collection," then that is incorrect. Have your module take an optional process_name configuration parameter. If it is present, us it (and the expected module label and instance name) to construct explicitly an InputTag, which will be passed to the FindOne constructor. The same is true of getByLabel(): if you specify an InputTag correctly constructed, getByLabel() will always find the correct product even if there are two with the same module label and instance name.

If your problem is other than as I have described, or my advice does not match your experience, please let me know.

#2 Updated by Christopher Green over 7 years ago

Gavin, is there anything else to do on this issue?

#3 Updated by Christopher Green over 7 years ago

  • Tracker changed from Bug to Support
  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100
  • Scope set to Internal
  • Experiment NOvA added
  • SSI Package art added

#4 Updated by Christopher Green over 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF