Updated PDVD geo

[lpaulucc]

This new ProtoDUNE-VD geometry includes the following features:

• Fixed cathode X-arapucas' positions to match beam pipe placement
• Inclusion of anode plate on top/below of the 3 wire planes for backgrounds. This is included together with the cathode switch on. Currently the material of this plate is set to vm2000 so that no additional geometry (ReflAnode) is needed to obtain optical fast simulation (see PR).
• Placement of cathode resistive meshes individually for lighter visualization
• J. Soto: Fixed PMTs' positions to match installation placement
  A change in the cathode position has been noticed on v4 (the base geo used for these changes) with respect to v2 (not sure about v3) so that it is no longer at X=0 but at X=-20 cm. This also changed the CRPs' positions in the geometry. @wenqiang-gu would you be able to identify which geometry has been used for the wirecell setup so it can be identified if this change should be reverted or not?
  Also, the distance of the beam plug with respect to the cathode should be checked. In the current geometry (v4/v5), these positions are:
  BeamSpot_x =-36.58, BeamSpot_y =109.02, BeamSpot_z =-277.41
  TPC Origin : (20, 1.13686837721616e-13, 149.65)
  Beam Plug position x=202.745856257036 y=238.779338015429 z=-236.979338015429
  I am still evaluating some TPC overlaps that apeared when I moved the Arapucas
  = Overlap ov00002: volCryostat/volTPC1_0 overlapping volCryostat/volTPC2_0 ovlp=5.5
  = Overlap ov00003: volCryostat/volTPC1_0 overlapping volCryostat/volTPC2_0 ovlp=5.5
  = Overlap ov00004: volCryostat/volTPC1_0 overlapping volCryostat/volTPC2_0 ovlp=5.5
  = Overlap ov00005: volCryostat/volTPC1_0 overlapping volCryostat/volTPC2_0 ovlp=5.5
  , which makes no sense, so under investigation.
  The overlaps with the beam pipe remain:
  = Overlap ov00000: volCryostat extruded by: volCryostat/volBeamPlIIUSCap_0 ovlp=195.539
  = Overlap ov00001: volCryostat extruded by: volCryostat/volBeamPlIIMod_0 ovlp=192.02

[wenqiang-gu]

• J. Soto: Fixed PMTs' positions to match installation placement
  A change in the cathode position has been noticed on v4 (the base geo used for these changes) with respect to v2 (not sure about v3) so that it is no longer at X=0 but at X=-20 cm. This also changed the CRPs' positions in the geometry. @wenqiang-gu would you be able to identify which geometry has been used for the wirecell setup so it can be identified if this change should be reverted or not?

In the wirecell configuration (dunereco/DUNEWireCell/protodunevd/), it still assumes the cathode centers are located at X=0.

We can update the wirecell configuration if needed. Do we understand the actual position?

[lpaulucc]

@wenqiang-gu thank you for the answer. Can you also confirm the drift lenght in the wirecell config? It was 310 cm up to v2 and then 338.5 from v3 on.

[YoannKermaidic]

Hi @lpaulucc
About the drift length, this I can confirm. 338.5 cm is what we aimed for in the NP02 cryostat when setting the cathode height.

[lpaulucc]

Thank you, @YoannKermaidic. I suppose this is the drift wirecell used then and there is no need to make a new configuration once I return the cathode to x=0 😌

[YoannKermaidic]

In the mean time, I give few simulations trials this morning with your new files and let you know.

[lpaulucc]

Regarding the overlaps, TPC positions in v5 are exactly the same as the ones seen in this PR (7e23002#diff-b4aef1aca19588eb15eaaf2b350d8137f45bf57421e94fb9bd70cb924f2eb868) but it is causing overlaps. I think the offsets are dislocated on one side but since I am not the one who introduced it, I will not do anything unless I am instructed to.

[wenqiang-gu]

@wenqiang-gu thank you for the answer. Can you also confirm the drift lenght in the wirecell config? It was 310 cm up to v2 and then 338.5 from v3 on.

In the wirecell, we set the cathode position and extract wire positions from LArSoft. From the current input file, the wire positions are at +/- 341.5 cm, so it should be consistent with 338.5cm drift length.

/cvmfs/dune.opensciencegrid.org/products/dune/dunereco/v10_03_01d02/wire-cell-cfg/protodunevd-wires-larsoft-v3.json.bz2

I can rewrite the input file for wire positions once the gdml is updated.

[lpaulucc]

@wenqiang-gu I can solve the TPC overlaps by changing the signs in this bit

if($ii%2==0){
  if($jj%2==0){
    $quad=0;
        $pcbOffsetY =  $borderCRP/2; # offset of the active area from CRP envelope
        $pcbOffsetZ = ($borderCRP/2 - $gapCRU/4);
    $myposTPCY = $posY-$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
  }else{
    $quad=1;
        **$pcbOffsetY =  $borderCRP/2;
        $pcbOffsetZ =  -($borderCRP/2 - $gapCRU/4);**
    $myposTPCY = $posY+$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
      }

Should I do that?

[wenqiang-gu]

@wenqiang-gu I can solve the TPC overlaps by changing the signs in this bit

if($ii%2==0){
  if($jj%2==0){
    $quad=0;
        $pcbOffsetY =  $borderCRP/2; # offset of the active area from CRP envelope
        $pcbOffsetZ = ($borderCRP/2 - $gapCRU/4);
    $myposTPCY = $posY-$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
  }else{
    $quad=1;
        **$pcbOffsetY =  $borderCRP/2;
        $pcbOffsetZ =  -($borderCRP/2 - $gapCRU/4);**
    $myposTPCY = $posY+$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
      }

Should I do that?

If I understand correctly, here is the layout for 4 quads the coordinate:

For quad 0 & quad 1, somehow we should expect same offset in Z and opposite-sign offset in Y?

[YoannKermaidic]

@lpaulucc, with the latest commit, I get the following error:

cet::exception caught in art
---- OtherArt BEGIN
  ServiceCreation
  ---- ServiceNotFound BEGIN
    Unable to create ServiceHandle.
    Perhaps the FHiCL configuration does not specify the necessary service?
    The class of the service is noted below...
    ---- OtherArt BEGIN
      ServiceCreation
      ---- groupTPCsIntoSets in CRPWireReadoutGeom BEGIN
        could not interpret the CRP geometry correctly
      ---- groupTPCsIntoSets in CRPWireReadoutGeom END
      cet::exception caught during construction of service type dune::DUNEWireReadout
    ---- OtherArt END
  ---- ServiceNotFound END
  cet::exception caught during construction of service type lariov::SimpleChannelStatusService
---- OtherArt END

[lpaulucc]

@YoannKermaidic perhaps the problem is being caused by the change in the TPC offset. I will undo this change and commit again but it is causing an overlap.

[YoannKermaidic]

Hi,

I confirm that the reverted version works well (i.e. no errors).
How do we proceed with the overlap? Shall we have a dedicated meeting or somebody thinks this issue can be solved?

[aolivier23]

Any updates on this discussion? I'd be happy to try to merge when a few reviewers think this PR is ready.

[aolivier23]

@lpaulucc @YoannKermaidic any updates this week? I can try to merge this Friday morning Chicago time if you can get it approved in time.

[lpaulucc]

Hi @aolivier23, I am checking a possible change needed for the positions of some photon detectors. Let's see if we get this sorted out today. Regarding the overlaps, I am not sure what to do since this was not a change introduced by me and I don't know what impact this can have on the charge sim.

[lpaulucc]

Overlaps can cause random effects and photons disappearing or appearing more than they should. @wenqiang-gu @lhwhitehead and Laura Zambelli any idea how to solve this?

[wenqiang-gu]

Overlaps can cause random effects and photons disappearing or appearing more than they should. @wenqiang-gu @lhwhitehead and Laura Zambelli any idea how to solve this?

Hi @lpaulucc , perhaps you could revert the changes in PR #123 ? That PR was introduced to align the TPC offset at the bottom and top for calibration purpose. However, if geometry overlaps are a bigger concern, we could discuss reverting it.

By the way , Xin and Nitish presented their Python-based geometry package (GGD) at the last collaboration meeting, and it does not exhibit such overlaps. We could consider transitioning to that package in the future.

[YoannKermaidic]

One point in addition is that we should put back the CRTs:
my $DP_CRT_switch="off"; -> my $DP_CRT_switch="on";

[lpaulucc]

Thank you for your answer @wenqiang-gu . I will contact Nitish and ask about the overlap. I will keep you posted.
Sure, @YoannKermaidic , I can put the DP CRT back on. Not the HD CRTs too, right?
I get an extra overlap with the DP CRTs switch on
Overlap ov00002: volDetEnclosure/volSteelSupport_Top overlapping volDetEnclosure/volBeamPipe_0 ovlp=121.06