All posts by esnider

May 2026

leads

Offline Leads 5/14/26 meeting notes

Attending:  Giuseppe Cerati, Gavin Davies, Steven Gardiner, Herb Greenlee, Tom Junk, Erica Snider

Agenda:

  • Phlex migration efforts (Erica, Tom Junk, PNNL, Gavin Davies, David Dagenhart, Kyle, et al)
    • By hand GausHitFinder migrated to Phlex. Demonstrated to run properly. (David Dagenhart)
      • [Not discussed at meeting, but that migration did not address the issue of art::service and art::tool migration]
    • Working with PNNL since start of this year on developing AI agentic workflow to automate refactoring algorithm code in art modules, and migrating it to Phlex 
      • Submitted Genesis proposal for this work. 
      • Substantive progress so far in the refactoring step + validation thereof
    • Proposal for handling art services and tools as interface pointers in data products. Many details to work out [see discussion below]
    • Working on “migrating” larcorealg and larcoreobj repositories to support a new larrecoalg repository that will be home to the refactored GausHitFinder algorithm code. [Note:  larcorealg and larcoreobj are part of the LArSoftObj suite designed to contain code that is independent of all art framework interface code. The suite was introduced to support the LArSoft coding standard of separating algorithm and framework interface code.] The intent is to make LArSoftObj repositories compatible with both art and Phlex. The migration requires Phlex compatible solutions to message_facility, possibly art::Exception.
      • Plan to migrate from message_facility to spdlog. NOTE: Log files will change!! Please check with production teams to assess impact of changes to log file format and content.
      • art::Exception:  ok in principle to use as is, since it will just lead to program termination.
        • Phlex team has not addressed the question of exceptions yet, however,  do not currently expect that they will trigger changes in framework processing, as is possible in art. 
        • Keeping art::Exception requires bringing canvas product (the art EDM) into the build. Not a desirable outcome. 
        • Will possibly replace with cet::exception or std::exception to avoid using canvas
        • In all cases, any exception will lead to program termination.
    • Plan to replace art::Ptr and art::Assns with combinations of pointers and indices. May have (locally defined) run-time wrappers that can make them look like smart pointers

Discussion

    • Steven:  no imminent plan within SBN to migrate. Will take logging issue back.
    • Gavin:  Elaborate on services solution?
      • LArSoft coding standard for services is to separate them into two classes, one “service” class that performs all of the framework interfacing functionality, and a “provider” class that performs the actual work of the service. Both parts can have abstract interfaces with multiple implementations, one of which is selected at run time via the configuration
      • Various services implement this scheme in different ways. Some have service inherit from provider. Others have a service class that contains a provider. Almost all services in LArSoft, however, respect this convention, and in this sense are already factored in the way we need for Phlex.
      • The Phlex solution will be to have a node that instantiates the provider that is needed, then stores a data product with a pointer to the provider interface in the data tree at the appropriate level and family to allow updates as needed, eg, for validity intervals, etc. This provides thread safe mechanism to update and retain any required state. 
      • The data product is then passed into the HOFs, where it is used as needed. Because the pointer is of provider interface type, we retain any polymorphic behavior already built into the algorithm code. 
      • This solution enables shallow migrations of existing LArSoft and DUNE code. That will be the fastest path to getting things running in Phlex. Can further Phlexify things from there as needed to optimize execution.
      • This basic plan has been approved by Kyle. Many details to work out still.

 

  • Status of Celeritas / Opticks integration 
    • Goal:  perform single-optical-photon tracking on GPUs to improve fidelity of light simulations, believed to be important for low energy physics 
    • Held two mini-hackathons at Fermilab
    • Celeritas team (ORNL, ANL, Fermilab)  has completed integration and reached benchmarking and optimization stage
    • Opticks team (Rice University) has also completed integration and basic validations. 

 

  • Spack migration
    • The quick overview:
    • LArSoft completed (summer 2025) (modulo changes / rebuilds triggered by cascading solutions from work on experiments)
    • DUNE completed (fall 2025) (“ “…)
    • SBND completed (winter 2026) (“ “…)
    • MicroBooNE and ICARUS both actively working on migration
      • How is the work going? Are there support issues?
      • Giuseppe:  initial meeting last week. Release managers were there. Don’t know status since then
    • Message from migration team 
      • Still working with all the experiments. Need your continued attention
      • Expect an announcement for the next Release Managers Forum meeting soon
    • Needless annoying reminder:  critical that we complete this process asap. SL7 is now 2 years beyond EOL.

Discussion

    • Giuseppe:  are regular Spack builds happening? 
      • Not yet. LArSoft waiting for completion of experiment migrations before starting regular Spack builds. [Not mentioned at meeting:  this is partly an issue of limits in available effort. Do not want to be supporting both UPS and Spack builds for an extended period of time]
      • Once all experiments migrated and CI is working with Spack, will then start regular Spack builds. Schedule of builds will be similar to what is happening now:  as new PRs come in, we will provide new standard releases (up to one release per week).

 

  • Adding support for arithmetic products and ratios of quantities with units (lardatalg#52)
    • Not a field-wide solution. No clear guidance from HSF. Prefer to adopt community solution
    • Author was not driven by a specific demand, and knows of no latent demand
    • Bringing it here bc we thought it important to gauge demand before taking action
    • QUESTION: do any experiments want this? If not, then we propose dropping it

Discussion

    • Giuseppe:  would be nice to have as an option. Not clear whether it requires a major migration. Not sure if they would push for major migration across LArSoft code
    • Herb:  SI package from years ago that did the same thing. Written by Fischler and Walter Brown. (Erica:  prefaced discussion noting that many solutions have been proposed over the years, none of which has been widely adopted.)   See no problem incorporating it if it does not break things. Don’t see it being widely adopted. A mental barrier to making needed changes (?).
    • Giuseppe:  Is it useful to get phlex people involved if this becomes a thing? More enforced? Could add it during phlex migration, for instance. 
      • Erica:  will ask Kyle. Do not expect they will have an opinion. ***
    • Steven:  seems fine
    • Gavin:  would like to hear what HSF thinks about this. 
      • Erica:  will ask Gianluca if he has discussed it in that forum. ***
      • Gavin:  If we adopted, that could spur the conversation. People have more opinions when things show up.

 

  • Other topics
    • Dormant LArSoft Coordination Meeting schedule
      • Plea to spur people to bring updates to the coordination meeting

 

Round table

  • Gavin
    • No issues.
    • DUNE CM next week. Will invite ES to Phlex adoption session. Talk about proposed LArSoft solution to services, tools there? Yes.
  • Steven
    • Working toward Genie 3.8. Coming soon. Keeping eye on framework developments relate to generator interfaces. If people notice anything, let him know. Will help 
  • Giuseppe
    • Working w wirecell team to reduce memory usage. Particularly the features that deal with non-uniformity in y-z in simulation. As implemented blows up memory. Working to reduce. Hopefully will be new request coming soon that solves this issue. Part of detsim.
    • Also developments on IaaS. No imminent requests from that.
      • SBN, part of ICARUS are studying this infrastructure
      • NuSonic? Yes
  • Herb
    • uB, MCC9 and MCC10. Both mature. Don’t usually get major updates
    • Recently started migration to refactored LArG4 for uB integration release. Also refurbished CI tests, which had been broken for 3 years. Partially motivated because SBN is more heavily invested in CI [connection to this is through HG’s new role in SBN]
    • uB using updated PPFX that is not integrated yet. Not sure how it will shake out. Maybe never. Breaking change. Minor affect on on-axis NuMI. Big change for uB and maybe ICARUS
      • Gavin:  PPFX v3 under development by Mike Korkoski. NOvA uses that
        • Larsoft uses v2. Lynn’s solution was to a make new fork for v2. That lives in HSF world
        • Not a good situation, to trying to get everyone working together and on same code base
        • Optimistic. Leo is DUNE release manager. Working directly with him. 
      • Herb:  monitoring the situation. Author of uB update is Nitish Nayak. Bug he found was that particles w neg x_F were being dropped. Important for off axis. Less for for on-axis.
    • Struggling witb Spack migration. Next highest priority thing. Meeting with Patrick, others. But still issues. Migration team (eg. Patrick) is responsive, so no issues with support