Dividing a Reconstruction Task among Several EDProducers

These are some general guidelines to keep in mind.

• If an intermediate product is interesting to no other EDProducer, it is probably best not to save the product in the Event.

• If an intermidate product is interesting to other EDProducers, but is trivial to reproduce, it may be best not to save the product in the Event (to save on Event size).

• Otherwise, it is probably best to save the intermediate product, either in the same EDProduct as the "main output", or perhaps in a different EDProduct than the "main output".

  If it seems best to save the product in its own EDProduct, then it may be best to move the algorithm that creates the product into its own EDProducer -- so that it can be invoked in other contexts, apart from the "other" task.

Use of temporary data

Are the initial 1D hits of interest to more than one use? If not, then the algorithm using them could just keep a collection (not an EDProduct-style collection; perhaps just a vector) of 1D hits, and work with these hits internally.

Our understanding is that, after making the 2D segments, the 1D hits are "polished". Furthermore, we understand that we want to save these polished hits.

Then a solution may be:

1. The reconstruction module makes 1D hits in a transient container.
2. The module then makes 2D hits from this input.
3. The module then polishes the 1D hits.

After all the work is done, the 2D hits, containing the polished 1D hits as internal data, would be put into an EDProduct and inserted into the Event.

The 2D segment class might look like:

class 2DSegment : public BasicRecHit {
 public:
  // implement the BasicRecHit interface, and also...
  vector<1DHit> const& hits() const { return polished_hits_; }
 private:
  // Contain those data needed to support BasicRecHit...
  AlgebraicVector parameters_;
  ...              // etc.  

  // Contain additional data
  vector<1DHit>    polished_hits_;
};

If many different classes contain the same data to support the BasicRecHit interface, then a "common data" struct which contains all these data may be useful.