LArSoft Coordination Meeting

US/Central
WH3NE ("Conjectorium") (FNAL)

WH3NE ("Conjectorium")

FNAL

Gianluca Petrillo (Fermilab)
Description

To connect via Zoom:  Meeting ID 831-443-820
(See instructions for setting Zoom default to join a meeting with audio and video off: https://larsoft.org/zoom-info)

PC, Mac, Linux, iOS, Android:  https://fnal.zoom.us/j/831443820

Phone:

H.323:

162.255.37.11 (US West)
162.255.36.11 (US East)
213.19.144.110 (EMEA)
See https://fnal.zoom.us/ for more information
 

At Fermilab:  WH3NE (Conjectorium)

Present

Giuseppe Cerati, Vito Di Benedetto, Lynn Garren, Krzysztof Genser, Herbert Greenlee, Robert Hatcher, Wesley Ketchum, Gianluca Petrillo, Hans Wenzel

Remote

Christoph Alt, Erin Conley, Katherine Lato, Gleb Sinev, Jose Soto, Tracy Usher

Project status report [Gianluca Petrillo]

  • reminder: breaking change in GENIEGen in the last LArSoft release v06_69_00 to comply to recommended usage of IFDH
    • not affecting CorsikaGen for now, but only because the latter does not comply yet to the recommendation
    • while IFDH service is always instantiated, it is not doing anything until it is actually invoked
  • this week release scheduled with art 2.10
    • including support for temporary data products put in the event (not saved in art ROOT file), plus new --validate-config option
    • [Wesley Ketchum] how can the temporary data product be useful? what is the difference with respect to dropping the data product in RootOutput? [A] One difference is that it is the producer which elects the product to be temporary, not the output module. A real use case might appear in BackTrackerService refactoring, but this pattern is being discussed.
    • [Herbert Greenlee] is the provenance of the temporary data product available? [A] -yes, just as for any data product- it turns out the answer is more complicate, and the provenance is not handled as for a dropped product
  • support will be for SLF6/7, Ubuntu LTS 16.04 and OSX 10.12 ("Sierra")
    • [Herbert Greenlee] will Clang be used? [A] the plan is to use Clang for OSX releases only, which will buy us support for OSX 10.13 ("High Sierra") too, but this is being pursued in parallel, and won't stop the adoption of art 2.10
  • GENIE 2.12.10 is now available, it is faster and improved for Nieves
    • [Lynn Garren] are new splines for that version already available? [Robert Hatcher] Whoops-no, but from now that is on the to-do list
    • asked for objections about switching to it
  • binary releases older than v06_00_00 will be removed, except production releases; let us know if you want specific releases to be kept

Conclusions

  • no objection raised for update to GENIE 2.12.10; will follow up via e-mail to confirm
    • in the meanwhile, splines should become available for it
  • awaiting response from DUNE and ArgoNeuT on removing older binaries of LArSoft

LArG4 refactoring update [Hans Wenzel]

  • recent Geant4 changes are relevant for Intensity Frontier community
    • G4 collaboration implemented our requests about new interfaces
    • eliminated performance bottlenecks, improved cross sections e.g. for kaons
  • GDML used for detector description at runtime, including optical properties and sensitive detectors
    • [Wesley Ketchum] moving parameters (e.g. step limit size, optical parameters...) from the FHiCL configuration to the GDML description is going to be a change in people patterns, and at the beginning to adapt might be hard
  • example of detector was implemented, with complete GDML description, and interactions were simulated in it
  • status: chain working, need to cleanup and rearrange
  • [Gianluca Petrillo] ROOT needs to be able to understand the GDML file [A] the file could be processed by Geant4 utilities and dumped in a format ROOT can understand [Krzysztof Genser] Geant4 should try to have ROOT fully support GDML format

Energy Deposits in Simulation [Wesley Ketchum]

  • motivation: MicroBooNE needs systematic variations of detector simulation parameters for error evaluation
  • problem: LArG4 module in LArSoft simulates particle interactions and charge transportation at the same time
  • solution is to split LArG4 module to factorise the two steps
    • it should be possible to apply a variation in charge transportation without altering the energy deposition
    • future development: possibility to translate energy depositions in space and time, and across detectors
  • lots of work done in MicroBooNE so far to accomplish this
    • developed under LArSoft v06_26_01 series
    • including new data product sim::SimEnergyDeposit which is from William Seligman proposal...
    • ... with the addition of a PDG ID code to avoid a lookup each time that one is needed
    • ionisation and scintillation (I&S) is implemented only with the algorithm "separate"
      • while in v06_26_01 art tools are not yet available, that is the natural solution for the I&S algorithm
      • NEST requires additional information from the detector description, and it might be more complicate to implement
  • results being validated
  • request to integrate in v06_26_01 era release and possibly in develop if there is time
    • there is no commitment at this time on porting the changes to develop and testing them
    • [Gianluca Petrillo] the data product itself should be ported into develop immediately to allow using data produced by v06_26_01 with modern LArSoft versions

Conclusions

  • the data product sim::SimEnergyDeposit is a good starting point as is now (can be schema-evolved later)
  • the proposed code (feature/wketchum_LArG4Edeps_2 branch in larsim and lardataobj) will be integrated in larsim v06_26_01 branch series now
  • integration in develop branch postponed after deployment in MicroBooNE

GENIE v3 status report and LArSoft requirements [Marco Roda]

  • GENIE v3 will allow a better management of models ("tunes")
  • most physics in GENIE v2 has an equivalent in v3
    • an exception are the old Final State Interaction models (which are not used by the experiments) [Ed.] Nobody in the room contested this statement.
  • support for GENIE v2 will be eventually dropped (for the usual endemic lack of available effort)
  • GENIE v3 is being finalised
    • [Robert Hatcher] the first release is expected in one week or two (announcement in GENIE mailing list)
    • [Gianluca Petrillo] we can use it for a "release candidate" of nutools and then LArSoft
      • [Marco Roda] with the release, the interfaces will be frozen
  • [Gianluca Petrillo] due to code changes, the same nutools code can't support both GENIE 2.x and 3.x [Lynn Garren] this is not any different from how things have been most of the time: NOvA uses a frozen version
  • [Gianluca Petrillo] beside SBND, also some DUNE collaborators are interested in the new GENIE version (but that's not a DUNE official request)
  • [Lynn Garren] this announcement is so far considered as a "heads up"

Conclusions

  • there will be some work to be done to allow the integration of the new GENIE, after it's released
  • when that's completed, a nutools and LArSoft release candidate will be published to allow experiments to test with it
  • the official adoption will follow the regular path of approval by LArSoft stakeholders
There are minutes attached to this event. Show them.