Skip to content

Conversation

@cerati
Copy link
Contributor

@cerati cerati commented Apr 10, 2025

This PR adds the code to run NuGraph2 in ICARUS, as presented on docdb 40585.

NuGraph is not yet added to the reconstruction sequence. It will be done after this PR is integrated and fully tested in grid jobs.

PRs for sbncode and sbnanaobj will follow to add NuGraph information to the CAFs.

Note: this PR has a breaking change, since it splits the sequence icarus_reco_pandoraGausCryoE/W into icarus_reco_pandoraGausCryoE/W+icarus_reco_postPandoraGausCryoE/W. NuGraph is run in the latter, and the split is required since NuGraph needs both pandora and icarus_tpcpmtbarycentermatch to be run upfront. The standard reco fcl files are updated accordingly, but non centrally-maintained fcls may have issues.

@cerati
Copy link
Contributor Author

cerati commented Apr 10, 2025

Looks like this is on top of PR #809 . The two are independent, but hopefully #809 will soon be merged. Only files in icaruscode/NuGraphIcarus need to be reviewed as part of this PR.

@cerati
Copy link
Contributor Author

cerati commented May 2, 2025

This PR needs also needs icarus_data branch feature/cerati_NuGprah

export METRPORT=$((BASEPORT+2))
done
#
echo "physics.producers.NuGraphCryoE.TritonConfig.serverURL: \"localhost:"$GRPCPORT"\"" >> $FCL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to create a copy of the FHiCL file instead of changing the one specified, to prevent errors where the original FHiCL file is read-only or in storage that does not support appending.

TimeTracker: {}
MemoryTracker: {}
RandomNumberGenerator: {}
@table::icarus_geometry_services
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Geometry services are included in the "common" bundle.

Suggested change
@table::icarus_geometry_services

Comment on lines 84 to 91
reco: [nuslhitsCryoE, nuslhitsCryoW, NuGraphCryoE, NuGraphCryoW]
#reco: [ nuslhitsCryoE, NuGraphCryoE]
trigger_paths: [ reco ]

ana: [NuGraphAnaCryoE,NuGraphAnaCryoW]
#ana: [NuGraphAnaCryoE]
streamROOT: [ rootOutput ]
end_paths: [ ana, streamROOT ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the indentation.

Comment on lines 31 to 36
NuGraphCryoE.avgs_u: [168.04594 , 178.3245 , 266.6149 , 3.857218 ]
NuGraphCryoE.avgs_v: [1245.3547 , 176.54117 , 323.52786, 4.3267984]
NuGraphCryoE.avgs_y: [1225.5012 , 183.58075 , 310.83493, 4.3409133]
NuGraphCryoE.devs_u: [ 82.80644 , 67.60649 , 274.32666, 1.2912455]
NuGraphCryoE.devs_v: [ 293.06314, 66.8194 , 322.11386, 1.4249923]
NuGraphCryoE.devs_y: [ 307.1943 , 67.063324, 312.461 , 1.4532351]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where are these numbers from? do they need to be changed if we change geometry?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are training-specific. With a new geometry, a new training will likely be useful but it would depend on the type of geometry changes.

MemoryTracker: {}
RandomNumberGenerator: {}
FileCatalogMetadata: @local::art_file_catalog_mc
@table::icarus_geometry_services
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "common" bundle includes the geometry already.

Suggested change
@table::icarus_geometry_services

@francescopoppi
Copy link
Contributor

francescopoppi commented May 7, 2025

Hi @cerati I have a request if we can include the following change in the icaruscode cafmaker fcl.
Recently I included CRT Tagged tracks in the carmaker (see: https://github.com/SBNSoftware/sbncode/blame/be46110722ff58957b030001069dda11bf57fb1c/sbncode/CAFMaker/CAFMaker_module.cc#L1954-L1961C48 ) and since I was exploiting a data product that could have also been used by SBND colleagues @PetrilloAtWork asked me to keep the default string for the product (https://github.com/SBNSoftware/sbncode/blob/be46110722ff58957b030001069dda11bf57fb1c/sbncode/CAFMaker/CAFMakerParams.h#L275C1-L286C1 ) namely: CRTHitMatchLabel = "pandoraTrackCRTHit"
can I ask you to include in the icarus cafmaker definitions the following lines:
cafmaker.CRTHitMatchLabel: "CRTT0Tagging"
cafmaker.CRTHitMatchInfoLabel: "CRTT0Tagging"

[https://github.com/SBNSoftware/icaruscode/blob/343bb9ee925a5b15653a8b183356e4e1f2fe8367/fcl/caf/cafmaker_defs.fcl#L321]

Thanks!

EDIT: actually... ignore this request. I realized my first PR is not yet merged, so I will add these changes there. Sorry for the confusion

Copy link
Member

@PetrilloAtWork PetrilloAtWork left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like I have limited myself to 7 bits of comments.

I am less than enthusiastic about how much the ICARUSNuSliceHitsProducer module and his True twin depend on a specific type of PMT matching. There should be no reason for that, if my reading of the code is correct and the module blindly trusts the match from the input. At the point that I would advocate using the direct association between slice and flash for the matching, and the trigger time from raw::Trigger to determine if it's the triggering flash. This is easier said than done, since there is no such direct association, but I think this is important enough that we may want to add that one too (I can help with that).

Other general comment: please add in the FHiCL file a short introduction describing what they do and your name as author, so that we can track you down when flames reach the ceiling. 🪣

Also: this is a breaking change in that it changes the definitions in stage1 workflow; derived workflows that use e.g. icarus_reco_pandoraGausCryoW will not execute some of the modules any more. This needs to be advertised: please write a summary of the breaking changes in the PR description, and make sure the release managers are aware of them so that they can report them in the release notes.

Names and locations

Proposed changes:

  • The custom for module names is to spell ICARUS all uppercase.
  • No need to have Icarus in the directory name, NuGraph is enough, and I would argue that it's better under TPC directory.
  • jobs dealing with a single cryostat should bear the name of that cryostat

@cerati cerati added enhancement New feature or request breaking this change will break backward compatibility in some way labels Jun 10, 2025
@cerati
Copy link
Contributor Author

cerati commented Jun 10, 2025

@PetrilloAtWork I addressed all your comments (implementing most of your suggestions, although not all). Please let me know if there is any follow up.

@PetrilloAtWork
Copy link
Member

I have marked as resolved the comments I consider addressed.
I have left unresolved the comments that haven't been implemented without any message from you, and the ones where I wrote a reply (including a few that do not require follow up).

@cerati
Copy link
Contributor Author

cerati commented Jun 11, 2025

@PetrilloAtWork I addressed all 2nd round comments and posted a reply to all those that are not resolved

@PetrilloAtWork PetrilloAtWork self-requested a review June 12, 2025 01:35
Copy link
Member

@PetrilloAtWork PetrilloAtWork left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A typo is left to be fixed in a description.

All my comments have been discussed and resolution was achieved.

Still not convinced that leaving a change of format pending is a good idea... time will tell.

Approved, with thanks to the author for his patience.

Copy link

@acampani acampani Jun 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If my understanding is correct the stitched plane basically exchanges IND2 and COLL in TPC 2 and 3 because of the different wires orientation on the two sides of the cathode, the remaining corrections are explained in detail, but perhaps I'd add also a comment on this for clarity.

Copy link
Contributor Author

@cerati cerati Jun 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent suggestion, will do it. Edit: DONE.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only have a comment on L451: why is the position included among features if it's left at a default? Is this changed at a later stage? Also I'd use a different default (in principle this is a physical position).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is to keep the format consistent with other experiments that do fill this information. Eventually we may want to do it also for ICARUS.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes to caf files will have a dedicated PR, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. sbncode PR532 was merged in May

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could it make sense to add a sanity check after L158 to check that the assocHits are vectors with exactly 3 elements and not larger? Perhaps this is unnecessary, but thought of bringing this up.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also wander what scenario could give condition at line L163 to be verified (I know this is a sanity check, but unsure of the exception here)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there can be space points with >3 hits associated, at least not with the current algorithms.

At line 164 we are checking that the hit associated to the spacepoint is part of the selected neutrino slice. Since NuGraph is run per-slice, we consider only space points that have all associated hits part of the neutrino slice.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the first I assumed it was unnecessary but just in case, on the second thanks for the clarification.

Copy link

@acampani acampani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After checks on all the files and the new structure of stage1 and a few clarifications provided by G. Cerati on the implementation of nugraph/impact on the other steps, I approve this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking this change will break backward compatibility in some way enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants