Project

General

Profile

Feature #11522

'Global wire' coordinate within LArSoft geometry

Added by Michael Wallbank almost 5 years ago. Updated over 3 years ago.

Status:
Assigned
Priority:
Normal
Category:
Geometry
Target version:
-
Start date:
08/10/2017
Due date:
% Done:

27%

Estimated time:
(Total: 88.00 h)
Spent time:
41.00 h (Total: 45.00 h)
Experiment:
LArSoft
Co-Assignees:
Duration:

Description

For a few months now, the reconstruction I've been developing (for DUNE) has been in a 'global' TPC space, and I know that other reconstruction methods take a similar approach. Basically, this involves defining the wires across APA planes so that, within a drift volume, there is a single wire coordinate covering an entire side of of anode planes.

As an example, here is how I get this global coordinate for the DUNE 35t:

int cluster::BlurredClusteringAlg::GlobalWire(geo::WireID const& wireID) {

  /// Find the global wire position                                                                                                                                             

  double wireCentre[3];
  fGeom->WireIDToWireGeo(wireID).GetCenter(wireCentre);

  double globalWire = -999;
  if (fGeom->SignalType(wireID) == geo::kInduction) {
    if (wireID.TPC % 2 == 0) globalWire = fGeom->WireCoordinate(wireCentre[1], wireCentre[2], wireID.Plane, 0, wireID.Cryostat);
    else globalWire = fGeom->WireCoordinate(wireCentre[1], wireCentre[2], wireID.Plane, 1, wireID.Cryostat);
  }
  else {
    unsigned int nwires = fGeom->Nwires(wireID.Plane, 0, wireID.Cryostat);
    if (wireID.TPC == 0 or wireID.TPC == 1) globalWire = wireID.Wire;
    else if (wireID.TPC == 2 or wireID.TPC == 3 or wireID.TPC == 4 or wireID.TPC == 5) globalWire = nwires + wireID.Wire;
    else if (wireID.TPC == 6 or wireID.TPC == 7) globalWire = (2*nwires) + wireID.Wire;
    else mf::LogError("BlurredClusterAlg") << "Error when trying to find a global induction plane coordinate for TPC " << wireID.TPC;
  }

  return globalWire;

}

As you can see, this is as good as hard-coded in for the geometry for which it was developed. Other experiments are starting to use this code now and so this will begin to cause problems.

I propose a new method (I don't believe such a method exists) in the geometry service which would return this 'global' wire number. It could take a geo::WireID (like my method above does) and then deal with all the specifics of plane and TPC as I do, but also taking experiment into account.

I'm happy to help out with any necessary code writing if we agree this is something which should be put into the geometry. Thanks!

NeighbourWirePlanes.odg (13 KB) NeighbourWirePlanes.odg Representation of wires from neighbouring TPCs (ODG) Gianluca Petrillo, 11/09/2016 06:43 PM
NeighbourWirePlanes.svg (69.1 KB) NeighbourWirePlanes.svg Representation of wires from neighbouring TPCs (SVG) Gianluca Petrillo, 11/09/2016 06:43 PM

Subtasks

Task #17427: Add geometry infrastructure for support of global wire coordinatesFeedbackTingjun Yang

Task #17429: Design and implement global wire coordinate feature.AssignedMichael Wallbank

Associated revisions

Revision 44c2d062 (diff)
Added by Gianluca Petrillo over 3 years ago

New algorithms to partition cryostat into drift volumes.

This includes data structures describing the partition and a unit test
(and also another unit test that is currently a placeholder).

This work contributes to issue #11522.

Revision 677ec8c2
Added by Gianluca Petrillo over 3 years ago

Merge branch 'feature/gp_Issue9818' into develop

Merging the first part of work for issue #11522 (may also be useful for
issue #9818).

History

#1 Updated by Lynn Garren almost 5 years ago

  • Status changed from New to Feedback

We will come talk to you about this.

#2 Updated by Gianluca Petrillo almost 5 years ago

  • % Done changed from 0 to 10
  • Estimated time set to 4.00 h
  • Experiment LArSoft added
  • Experiment deleted (-)

Mike and I have talked about the definition of this global coordinate.
His reference implementation has a few specific features:

  • it ignores the gap between TPCs only when dealing with the collection wires
  • it does "align" on the same global wire coordinate wires from different TPCs that are in the real detector a bit staggered (by a fraction of wire pitch) because not aligned
  • it returns a rounded, integral value representing the coordinate (or distance) from a specific reference wire, which varies according to the drift volume

I have asked him to consider an implementation that instead:

  • is simpler and uses global coordinates as base for the global wire coordinate; the reference is the same for all the planes
  • the absolute value of global wire coordinate will be different by an offset with respect to Mike's current implementation
  • the relative difference between global wire coordinates still reflects the distance between the wires but its unit is not the wire pitch, but real world units (cm)
  • the relative difference between global wire coordinates is in real space: includes the gaps on all planes (with the effect that no hit will fall in some specific coordinates)

In practice, the suggested implementation is a simple distance of the wire from an hypothetical wire on the same plane that passes through the global coordinate origin (or, more precisely, crosses the x axis: the x coordinate is discarded in all the implementation we considered).
As a side note, care should be taken to make sure that an increasing wire number matches an increasing global wire coordinate, or, if this is not a requirement, to clearly state it.

The global wire coordinate being in cm rather than in wire units is a feature that we did not recognize during our discussion. The implementation I propose shows it, and to have wire pitch unit instead the assumption should be made that the planes on all TPCs have the same pitch.

#3 Updated by Gianluca Petrillo over 4 years ago

Pandora might also be interested in having such a feature.
Tyler Alion suggests that a simple implementation might be to collect all TPCs whole wire planes share the same x coordinate and merge their volumes.
This somehow connects with the issue of LArSoft/pandora interface needing detector-specific code to communicate the geometry to pandora.

Previous discussions pointed out that for algorithms to effectively use this new space, they should allow for "fractional" wire number coordinates and they might need to redefine the step to get to the next wire, that might be larger that 1 (TPC gaps) or smaller (non-aligned wires).

#4 Updated by Michael Wallbank about 4 years ago

Apologies for letting this get lost in the redmine void. I am happy to return to this issue now and discuss a resolution.

I'm not sure I agree with Gianluca's description of how it could be implemented. The idea was to use a coordinate with units of wire number since this concept is already used in existing algorithms. At least in the reconstruction I've written, we work in the wire/tick space and this makes sense within a given TPC -- the extension to multiple TPC volumes is therefore simple and code wouldn't have to be rewritten. I agree with many of your issues with this but would rather find a workaround in the context of using a coordinate system based on wire number rather than non-integer distances.

All wires on the same plane have the same pitch, regardless of TPC, so this isn't an issue. I like the suggest of Tyler's to simply merge all the volumes for wires which share an x coordinate (I see this as the software equivalent of electrically connecting the wires between APAs as is the case in SBND!). Could we think along these lines?

As I mentioned in my recent email to Katherine, if we discuss this and agree on a solution, I'm more than happy to write an initial implementation on a feature branch in larcore (or wherever) and present it to others for comments.

#5 Updated by Erica Snider about 4 years ago

Hi Mike,
I'm a bit confused. The idea as it was introduced was to have a unified space across TPC's in which to do pattern recognition by combining wire coordinates. In a single TPC, integer wire numbers are perfectly fine because the spacing is completely uniform. Once you cross TPC boundaries, however, that uniformity is lost because of the offset between adjacent APAs. If you simply continue using the wire number in the next TPC incremented by Nwires from the previous one, then you end up with apparent topological discontinuities across boundaries that threaten to undo the benefit of moving to a combined coordinate space. You can fix this by going into a non-integer wire-number space. Conceptually, nothing is changing in the algorithms, except to allow the pitch to be different from unity at APA boundaries.

Am I missing something here?

Erica

#6 Updated by Gianluca Petrillo about 4 years ago

Adding the number of wire (Nwires) does not work, just because there are coordinate ranges where wires from two TPCs are overlapping. Think of the U view, where the first wire on the second TPC falls roughly at the same coordinate as the last long wire from the first TPC.
I stress roughly, because in general it's almost sure that all wires of one TPC will have coordinates with a common fractional offset (e.g., 0.2) with respect to the wires from another, just because even in the ideal case, the TPCs are aligned, their wires are not.
Curiously, the truth of the statement that wire pitches are uniform (within a single plane spanning multiple TPCs) depends on the definition or wire pitch (and in particular, how you define the pitch between wires on different TPCs).
I attach a silly scheme to show what I mean. You can argue whether to call the distance between the wires in TPC 0 and 1 "wire pitch". More relevant is the information whether that distance is important when reconstructing, and how often.

#7 Updated by Erica Snider about 4 years ago

I think we're all saying the same thing. My statement about adding the number of wires was just an ansatz to point out that wire pitches are not uniform when considering multiple APAs, even if they are within a single APA, which is exactly what is pictured in your diagram. (Thank you for that!) I'm sorry if I wasn't making myself clear.

The pitch between wires on different APAs I think only matters at the boundary, since the wires never actually overlap. This is the origin of my statement about allowing the "pitch" to be different at the boundary. (And if this does not make sense, then just know that the diagram correctly depicts this situation I'm talking about here too.)

Finally, I think we previously agreed that defining a global wire coordinate makes sense (hence this ticket), so we just need to agree on how to do it.

Erica

#8 Updated by Michael Wallbank about 4 years ago

Thanks both for your time discussing this. I understand it's not a straight forward as I would like it to be!

I think I understand what points Erica; I wasn't proposing just increasing the wires number by Nwires (refer to my code in the original ticket), instead I was finding this non-integer wire number but then returning an int. One thing that isn't clear from the snippet I posted initially (maybe I've added this since) is I actually return std::round(globalWire), explicitly rounding the wire to the nearest int. If I'm understanding correctly, the only thing that you would change here is to return a float rather than the int?

The only reason I'm using ints is because I apply the blurring and clustering on the hit map with discreet ranges (i.e. lower_wire_blurred = wire - blurwire; lower_wire_blurred < wire + blurwire; ++lower_wire_blurred -- if this makes sense!) and I'm not sure conceptually in my head what changing these wire numbers to floating points would change. Maybe nothing, or it may present other problems. I need to think a bit more about this.

Now I've clarified what I'm actually doing, do you still think it makes sense to consider these values as non-integers, Erica? There may be a small systematic offset across a boundary but it's not going to be more than half a wire pitch (~2.5 mm in DUNE) so I doubt that'll impact the reconstruction. I get what Gianluca's saying with the drawing but, as I say, I doubt this will affect things much... Please argue with me though -- I'm happy to be told I'm wrong!

#9 Updated by Katherine Lato almost 4 years ago

  • Status changed from Feedback to Assigned
  • Assignee set to Michael Wallbank

#10 Updated by Michael Wallbank almost 4 years ago

Hi all again. I think we agreed a month or so ago that this is something we'd like to have implemented in LArSoft somehow. Do we think it would be best to have a chat about this to try to move things along a bit faster? I'm happy to arrange a Skype meeting at some point, I'm sure it won't take long to discuss.

Once we've agreed on a plan of action I'll get it done (aware this ticket has been open for nearly a year now!)

#11 Updated by Erica Snider over 3 years ago

Erica and Gianluca met with Mike to discuss the detailed definition of the global wire coordinate, whether it represented a useful concept within LArSoft more generally, what functionality within the geometry sub-system would be required in order to support using it, and how construction mis-alignments might affect all of that.

The general conclusion was that it would be useful to provide support within the geometry given the number of detectors that could make use of it, that the functionality required involved defining a detector-dependent mapping from a wire ID to a global wire coordinate, and that the algorithm should take into account mis-alignments by using the average wire position in define the global wire coordinate. An assumption going in is that the mis-alignments will be small compared to the wire pitch.

Gianluca will provide a detailed written description of proposed functionality, including how opposing drift volumes for an APA would be handled and the handling of any other known special considerations, and what, if any, inverse mappings should be provided. We will then iterate on that description until agreement is reached, the move forward as appropriate.

It might also be useful to consider how this picture might change should mis-alignments turn out to be comparable to or large compared to the wire pitch.

Erica

#12 Updated by Gianluca Petrillo over 3 years ago

I have started doing some preliminary geometry coding to group the TPCs necessary for the definition of a drift volume.
The code is new and currently disconnected from the GeometryCore service provider.
I pushed it in develop branch (larcorealg) with its unit test.

I would like to know also from Robert Sulej, who requested us a similar feature, his usage model, so that a proper infrastructure and interface can be developed.

#13 Updated by Gianluca Petrillo over 3 years ago

  • % Done changed from 10 to 30

#14 Updated by Robert Sulej over 3 years ago

I added Alexander, Dorota and Leigh.

We are working on a few things:

- Alexander's CVN for nu_e selection, trying to see if it could be improved if the single image off an even is spaning over all involved tpc's

- started to use such image representation of ADC in PMA tracks validation, now supporting it only at the level of track in single tpc

- if the feature is available, it could be useful for the event display, e.g. ProtoDUNE online or DQM one as examples of immediate use, but in general the current LArSoft's way of displaying single tpc is a very inconvinient for DUNE/ProtoDUNE events

- I think other detectors (ICARUS) should profit in the same way.

Thanks for coming back to this!
Robert

#15 Updated by Robert Sulej over 3 years ago

One more pieces of information: it may be useful to know the "plane coordinate" as it is now, and the offset required to convert to the "global wire coordinate".

#16 Updated by Katherine Lato over 3 years ago

Note, broke this into two subtasks to make it easier to track who was doing what.

Also available in: Atom PDF