To connect via Zoom: Meeting ID 831-443-820
Password distributed with meeting announcement
(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:
https://fnal.zoom.us/zoomconference?m=SvP8nd8sBN4intZiUh6nLkW0-N16p5_b
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: no in-person presence at the lab for this meeting
Notes from Nov 2 LArSoft Coordination Meeting
Erica Snider: Release and project report
no comments or questions
Herb Greenlee: ParticleID data product updates
Want to merge latest MicroBooNE prod branch w develop. Requires ParticleID, so will speak both to ParticleID and the other changes to be merged. Start with ParticleID
Historical overview
Proposed July 17, 2018
Some suggestions made and a second presentation Jan 15, 2019
agreed to in principle pending implementation of ioread rule
MicroBooNE forked MCC9 off LArSoft v08_05-00, Jan 16, 2019
ParticleID merged initially MCC9 fork, but not develop due to lack of ioread rule
In the MicroBooNE merge, broke backwards compatibility by choice
Old class description
Contained metric values for specific PID algorithms
Plus a single PlaneID class
New class description
Vector of structs that could accommodate arbitrary algorithm descriptors defined by user
string name
metric value
PDG hypothesis ID
Plane mask, a bitset, where each represents a plane in the TPC
allows specification of algorithms that used multiple planes for the PID
Advantages of the new class
Extensible. Add new algorithms w/o changing class
Multiple planes
Disadvantages
Assumes one TPC and cryostat
Neither TPC nor cryostat are included
Kyle comment: can diff collections be used to ident the TPC / Cryostat? Yes in principle
This needs more thought before going that route
Why no iorule before this?
Originally, root bug. Was long since fixed
Second issue was inability to read old geo::PlaneID that was embedded in ParticleID
This is now solved
How iorules work
root presents user with two versions of object being read
First matches compiled-in class
Uses global root dictionary
Second is reconstituted version of object read from disk based on dictionary stored in disk file
Available only as TObject*
No programmatic access to class members
Uses object-specific dictionary in the file
Need to convert by hand within the iorule
When reading an old version of ParticleID from disk, the embedded PlandID object needs to be unpacked in order to correctly set the plane mask
Observed that the embedded PlaneID embedded in reconstituted disk version of object is always default constructed (and so in "invalid" state)
But was still possible to read PlaneID alone. Some there was some issue in extracting the PlaneID from disk. This problem was never solved.
Solution
Add PlaneID data member back into new ParticleID class (a solution originally suggested by Philippe Canal)
Had to have a particular name ("fPlaneID")to trigger the default schema evolution.
That default schema evolution correctly fills the fPlaneID data member in the new class, even if the layout changed (with the addition of the vector, bitset, etc)
As a side effect, this also adds a location to specify the cryostat and TPC
The updated iorule adds nine algorithms structs corresponding to the atomic values in the old ParticleID class
Once the added member is read correctly, then just need to unpack it and fill the bitset.
Dependencies
lardataobj: ParticleID class
lardata: dump module
larreco: track fitter
lareventdisplay
larana: the algorithms
Merge branches in github.com/uboone
See slides
Experiment dependencies
Many.
Orig authors provided merge branches that worked at the time
Herb looked at some. Would need to do "git merge -X ignore-all-space conflicts"
But then had issues building things (as expected)
Also noted:
lariatsoft appears to be unmaintained
sbncode has ParticleID dep, but no eisting merge branch
Some experiment repositories migrated to github. The merge branches may or may not have been migrated from redmine
Experiment branches not fully tested
Lynn: noted that these branches are really old, so likely need to start over. CI system will not work w/o clean build.
Additional MCC9 updates that MicroBooNE would like to merge into develop:
MCS track momentum fitter
Author: Giuseppe Cerati
larreco updates and branch (see slides)
Existing fcl should work, but result will change
Slide with performance, JINST reference
Pandora event building
Andy Smith and Wouter van de PontSeele
larpandora updates
larpandora merge branch: greenlee_mc99_event_building
event building updates were designed to be non-breaking for non-MicroBooNE experiments at the time they were originally developed (ca Feb 2019)
Request
Test build with all of the merge branches mentioned so far.
Not including experiment repositories
List of branches in MicroBooNE fork (see slides)
Discussion
Lynn: Can you make this in the form of PRs? A: Yes
And mergeable with develop? A: Yes, will ensure that
Then merge into a test release? A: yes.
We can do that
From the test release, can then work on updating experiment branches
Will need to trigger stand-alone CI test once we have the test release
Chris Green: cetmodules 2: implications for UPS to Spack migration
Have deferred some things for a later presentation, so this is the first of several presentations to cover this
Recap:
See presentations from 9/21
Purpose: Developing long term replacement for build system based on ups
cetmodules 2 vs cetbuildtools 8
cetbuildtools 8 is a wrapper around cetmodules 2 with increased compatibility and fewer deprecation warnings
If all one did was change "cetbuildtools" to cetmodules" in CMakeList.txt, likely it would work
But now have power and flexibility to
improve build times, avoid unnecessary transitive dependencies
reduce lib size and memory footpring
improve code correctness and safty by elim ODR (one-definition-rule) violations caused by use of plugin services and tools
eliminate need to use include_directives()...
eliminate need to use find_package() or find_ups_product() for transitive-only deps
elim need to use find_library(), find_file() or find_program() for non-CMake external deps
deal trivially w header-only deps
elim need to use cetbuildtools or cetmodules in dep packages
elim need to generate and use "product_deps" files
Could do this w/o using cetbuildtools or cetmodules, but:
would involve wiring a lot of cmake infra, or hand-rolling cmake config files for every packages, and keeping track of transitive deps manually
write a lot more cmake code in each package
doing a lot of work that's already been done for you
Value added
Auto generation of CMake config files including [See slides to avoid possible errors in this list!]
find_dependency() calls for transitive edeps
useful variable definitions, inclding cetbuiltdtool_compat (<project>_OLD_STYLE_CONFIG_VARS)
CMAKE_MODULE_PATH additions to find cmake modules
scoped target defintions
All the accounting... [missed...]
mechanisms to enable developer to provide the info
overrides for CMake function: include(*), find_package()
functions combining multiple CMake features: cet_make_library(), cet_test(), basic_plugin()
A path from UPS-dep building and packaging to an agnostic system suitable for...
New concepts: dependency types
direct
shared lib x1 from X needs shared lib Y 1 from package Y
indirect transitive dep:
lib W1 from W needs lib X1 f, but needs to know where Y1 is so X1's deps can be satisfied
Direct transitive
S1 from W users header from X, which defines and inlined function requiring symbols defined in lib Z1
New concepts: targets vs variables
vars: one name , one value
targets: one name, many propertyes
art::Framework_services_optional_RandomNumberGeneratorSErvice:
shared
imported
interfac_including_direcdtoreis "{${_IMPORT_PREFIX}/include"
interface_link_libbraries
imported_location_relwithdebinfo
Library types
STATIC : libXXX.a
concrete file, existins in filesystem
code defining required symbols extracted from .a and included in dep library or exe
SHARED: libXXX.so
concrete file
code defines required symbols loaded from .so at runtime
INTERFACE library
conveys header--propagated transitive deps (direct transitive)
No library, no file
just properties defined
add_library(art_plugin_support::toolMaker INTERFACE IMPORTED)
set_target_properties(art_plugin_support::toolMaker PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "$..." INTERFACE_LINK_LIBRARIES "...." INTERFACE_SOURCES "..."
So no secret / magic info you need to know
MODULE: libXXX.so, XXX.so
concreate file
cannot be lined to: usable only via dlopen()
ideal for plugins registration code
OBJECT : mypkg::XX_objects --> ethel.o, bill.o...
virtual, CMake-only concept
list of object files:: compile once
Plugin implementaion and registration libraries
currently, registration code and implementaion code are always in the same lib
problematic for plugins with user-visible interface: services, tools
c-linkage --> ODR violations
memory bloated with code that may never be needed
Solution: put implementation, registration code in sep libs
Example:
libart_Framework_services_Optional_RandomNumberGenerator.so
SHARED, linkable
art::Framework...
libart_FRameworkServices_Optional_RandomNumberGenerator_service.so
MODULE, not linkable-- no exported target for deps
RandomNumber...
How do I use this?
Understand the code you're writing
What is it providing
What is required to use it
What types of dependency does it have and/or confer to users
New keywords to help: find_package()
PUBLIC dependents will also need to know where this package is
PRIVATE: Needed only by us. Eg, macros, build-only, test deps, data,...
Use targets in lib link lists, not lib file names aor variables
header locations, transitive deps, ...
New keywords for library link lists
INTERFACE: you don't need this lib, but users will
PUBLIC: needed to link this library, and also needed directly by deps
PRIVATE: needed only to link this library
New keywords for cet_make_library()
Move away from GLOBbed lists
eg, relying on build system to find all source files because they have a particular name or live in a particular place. That only works by re-running cmake
Prevents rebuilds, hysteresis
Documentation will be coming
Changes will be adiabatic
Will not lose ability to generate ups packages if needed until finally ready to switch everything over
So can continue to change CMakeList.txt to work with spack without losing ability to use ups packages
Discussion
Lynn: tools to help w dependencies you will need in a link list?
generally grep. You need to know your code, and what includes end up in headers vs those you have only in source
Kyle used something? lvm_use? [??] Hope we can make that available. But for now, need to look at code and pare things down and make things public or interface, etc.
Herb: getting rid of product_deps?
It will no longer be the primary place where you put info where it currently lives
Lynn: don't see that in converted packages
Not yet. But in cetbuildtools 8, will notice a lot of -D definitions during cmake phase. That is all the info from product_deps encoded for cmake.
A relatively recent feature in cmake called "presets". Just files you can tell cmake to work from that contain all these settings, things you never need to change because they are features of the package. Eg, this is where fcl, gdlm files installed, my incluldes are here, etc.
All these can now be put into CMakeLists.txt files, and don't need to be anywhere else. Things that can be in presets...
In future, package will ship with small number of these preset files that someone building will put on their cmake command line, so will only be a few characters long, and it will build correctly.
So will have a single point of maintenance for own package config that is not product_deps
Herb: but if building a ups package?
Do need it right now, and currently smooths the transition to spack, but creating and using ups packages will still be possible without the product_deps
Marc Mengel has provided ways for ups to use spack-gen packages by creating approp table files. Similarly, can use ups packages inside spack-generated package
But the entire point here is to retire ups, and move to new ways of doing things
We're providing a smooth transition path
Kyle:
regarding product_deps, look at the ones in LArSoft that are used w cetbuildtools 8. The biggest changes there are that the product name and version have migrated entirely to CMakeLists.txt files. Those types of changes are examples of how the migration to ups to something that can support spack will happen.
find_ups_xxx: want to move away from that. Replaced by "find_package()"
If still need uppercase var names, then can set a var that will generate that for you in addition to package names. But want to move away from that asap
Herb: dependency types. Did not mention runtime deps
Correct. But in runtime dep, can come from find_package().
Described how this works (didn't follow).
Giuseppe: while playing around w spack independently, sometimes have issues, maybe due to limited knowledge of cmake. But we could also be using tools on top of cmake, possibly without being aware. So in preparing docs, make it clear what is standard cmake vs the tools on top.
Agree. Will do this
Patrick: have issue with larevt currently because migration did not have services in subpackage...
GC: a more generic comment
Erica: migration script. What will it do
Will extract things from product_deps and put it into CMakeLIsts.txt form
Will move from ups_find_product to find_packages.
Will move from variables to targets, up to a point
Will do what is necessary to point out things that should change yourself by putting recommendation comments on the end of lines. Will do this for changes that are too complicated to change by script
Lynn: have been using migration script with nutools. Left a ton of work to do.
Certainly the case that there are many things that are a feature of, or implied by prev use of ups and environment variables everywhere that will magically be available in the new environment. But this is not the case. Some things will just not be in the spack world.
This is why cetbuildtols 8 exists, to allow an easer, more protracted change without losing ability to make and use ups packages
This is why is has taken so long
Erica: State of documentation? At least a month away.
###