Add Pandora LCContent to the suite of UPS products
This request actually comes from the DUNE Near Detector effort. We'd like the code at
to be available in a UPS product distributed in CVMFS and scisoft, similar to larpandoracontent.
It is useful in reconstructing particles in the calorimeter of the MPD. While this isn't a liquid
argon issue, it might be reasonable to include the distribution of the Pandora LCContent package
together with the other Pandora packages rather than treat it specially. We realize this creates
a long-term maintenance burden to make releases as development in Pandora LCContent continues
and new compilers come out. There hasn't been significant new development in it in three
years, though with some use it might start up again.
#1 Updated by John Marshall 3 months ago
I was wondering what kind of solution we'd need here, and whether you were planning for LCContent changes/development, or whether you'd initially just be happy to have it as an "external"? I ask this, about the external, specifically because I made a way for bundling the different Pandora libraries together quite nicely as part of the single "pandora" external product.
Currently this product has the PandoraSDK and PandoraMonitoring libraries. Initially, when we started LArTPC development, the Pandora LArContent library was an external there too, with just larpandora as the interface package in larsoft. We could do this for LCContent, with just an extra CMake command.
Basically, there's a SDK for reasonably generic (but quite HEP-specific, really) pattern recognition, then a package that does visualisation. Those are what are built right now as the current pandora external product. Next, to build a reconstruction, you need some logic, and we divide this up into libraries of Pandora "content", each targeting different patrec problems.
So, we have a LArContent library, the original (where the project started) LCContent library, then a generic learning ExampleContent library and a WorkshopContent library, for the Pandora learning workshops we've run. The last ingredient is the application that passes in building blocks for patrec, and selects which algs and alg tools (from the content libraries) to run. For larsoft, this is larpandora. For iLCsoft, this is DDMarlinPandora. For the ExampleContent, this is a simple int main entry point, etc.
The build instructions for the PandoraPFA metadata package are here, and this is pretty much what Lynn already uses to build the pandora external. In those instructions, the options to build the different content libraries all set to off, but could issue -DPANDORA_LC_CONTENT=ON and it should appear:
It should be possible to build the exact same version of pandora as currently used in larsoft, but with the LCContent library present too. Actually, we have some minor updates for SDK and Monitoring and were going to suggest that an minor update of the pandora external be made then, but best to decouple separate issues!
Finally, if the LCContent (or Pandora for ND generally) were to come under active development here, then we'd want to do something slightly different. My strong suggestion then would be create a new Pandora application and/or content library, e.g. NDPandoraContent, which can depend on either/both of the LCContent and LArContent libraries and add new functionality or override existing functionality so as to be in ultimate control of a ND reconstruction, without conflicting in any way with the existing LArTPC reconstruction or the LC reconstruction (modifications to which should involve our iLCsoft colleagues).
#2 Updated by Eldwan Brianne 3 months ago
This is actually a very good comment. I think for at the moment, we would like to have it as an external package. I have developed the interface to Pandora for GArSoft that are based on LArSoft and also DDMarlinPandora as I have experience with it already coming from the LC Community and at DESY. But finally, at the end, we may indeed go a different path by developing a ND Pandora Content package in order to have a unified framework for the ND. It is still a bit early to know which path we will go as discussions have just started on this with the Pandora Team. Anyhow I do agree that if development will become active for the ND, a different package should be done, avoiding to break sth for the LC reconstruction.
#3 Updated by Lynn Garren 3 months ago
Given John's comments (thank you!), we would prefer to include LCContent as part of the pandora ups product. However, Eldwan indicates that the use of LCContent is still under investigation. I suggest that this request be put on hold until the experiment decides which product will be used. I presume it is possible to continue investigations with local builds of the relevant packages. Does that present any problems?
#4 Updated by Eldwan Brianne 3 months ago
I think this is ok to put on hold this request. The current development is mostly done by me at the moment and I can continue using a local environment.
This should be fine with a proper documentation until we reach a decision on how to proceed forward for the ND and Pandora.
#6 Updated by John Marshall 3 months ago
Following some informal chats, the consensus is to request that LCContent be included as part of the "pandora" external package, built at the SciSoft Team's convenience - thanks!
The recommendation is that v03-15-00 of the PandoraPFA metadata package be used. The build instructions can be whatever is used for existing pandora external builds, but the CMake step should now include one extra argument, with everything else exactly as before:
For reference, the build instructions you have been using will not be too dissimilar to those shown for build option 1 at: https://github.com/PandoraPFA/Documentation/blob/master/README.md
v03-15-00 of the PandoraPFA metadata package will bring together Pandora SDK v03-04-00, Pandora Monitoring v03-05-00 and LCContent v03-01-05. No change in functionality is expected for the existing larpandora/larpandoracontent LArTPC reconstructions running in LArSoft if they switch to this new build.
Hopefully all will be smooth, but please just let me know if anything goes awry (CMake ExternalProject_Add likes everything to be just right!).
P.S. Anyone who wants to know more about what's actually in the Pandora LCContent library, please take a look at: https://github.com/PandoraPFA/Documentation/blob/master/Pandora_LC_Reconstruction.pdf
#7 Updated by John Marshall 3 months ago
Hi again, I've below included a little summary of the suggestions we've discussed about how things might be best structured as this project moves forwards, as a reference:
The first suggestion for minimal impact on existing use cases would be to add a new ND development area as a fully-fledged garsoft product (named ndpandoracontent, or garpandoracontent?). This would be equivalent to the larpandoracontent used for LArTPC pattern recognition. The Pandora SDK, Pandora Monitoring and Pandora LCContent libraries would be part of the pandora external product. The ndpandoracontent could depend on LCContent and larpandoracontent (if needed), as driven by the algorithm needs of the ND reconstruction use case.
Small changes (e.g. would help if this was public; need this to be virtual; add this interface, etc.) could be accommodated by larpandoracontent and LCContent (via discussion and pull requests to PandoraPFA/LArContent and PandoraPFA/LCContent), but anything that would make life difficult for the existing LArTPC reconstruction or for iLCsoft would be strictly confined to ndpandoracontent. And, indeed, the expected all-new algorithms for ND reconstruction would be developed there too.
Efforts to minimise code repetition would be sensible, of course, but there’d be a decent degree of freedom to develop for each of the relevant use cases, so this should work well. Pandora works by having large numbers of algorithms and algorithm tools registered with Pandora instances, then XML settings files trigger which are actually used (and there's lots of options for nested algorithms and reclustering, etc.). Algorithms and algorithm tools from any content library can be registered and then called. The interfaces and abstraction ensure all algs will run, but it's up to the user to put together a coherent chain of algs that do what is wanted! Helper functions and constructs from each library can be safely reused.
A final point: there is a need for a new ND application/module that does the job of larpandora, but for ND (Eldwan has already made progress with this). In essence, this sends the hits off to Pandora and receives the output particles. This could be a new ndpandora product. But, if we wanted to keep things a little simpler at first, it’s perfectly possible for the ND-specific algorithms (i.e. what would be in ndpandoracontent, above) to live and be developed in this area too, maybe only being separated if the two areas of activity start to warrant separate repositories and management.
Hope this helps!
#8 Updated by Thomas Junk 3 months ago
The consensus from the discussion earlier in this ticket and a meeting we had on July 15 is that yes, indeed we want Pandora LC Content included in future versions of the pandora UPS product in the larsoft distribution. We would like a new version of pandora with LC Content at the earliest convenience.
We had worried ourselves a bit about using the new pandora product with GArSoft development forcing us into all new versions of everything else, including GENIE, but this is not a problem. I have already adjusted GArSoft source code to be compatible with art v3_05_01 and nutools v3_06_05 (and the refactored nutools products) but haven't pushed it yet. Since we use edep-sim in the ND, we split off the generation step from what's linked in garsoft which is used for detsim, reco, and analysis, so we're okay from the GENIE version perspective.
#11 Updated by Lynn Garren 3 months ago
- % Done changed from 0 to 100
- Status changed from Assigned to Resolved
pandora v03_15_00 is now available on SciSoft and larsoft cvmfs. Please ensure that this release meets your needs.
John, are changes needed in larpandoracontent or larpandora before larsoft begins using this release of pandora? Also, does the Pandora team want to make any changes before larsoft begins using the new release?
#13 Updated by John Marshall 3 months ago
Hi Lynn, Many thanks, and I'm glad the build was smooth. No code changes are required for larpandora or larpandoracontent in order to use this new version of the pandora external product (so nothing needed other than any e.g. ups/product_deps changes).
You could choose to switch things over to pandora v03_15_00 this week, or you could choose to wait until next week, to decouple this change from the two new Pandora-related features looking for release this week. There's no specific need to wait, but it might just help to keep things simple:
No new Pandora-features are expected next week. This week there's a larpandora feature from Ed Tyley (https://github.com/LArSoft/larpandora/pull/10) and a larpandoracontent feature from Isobel Mawby (https://github.com/LArSoft/larpandoracontent/pull/9).
#16 Updated by Eldwan Brianne 3 months ago
One question, was LCContent compiled against PandoraMonitoring? (with the option PANDORA_MONITORING=1)
LCContent algorithms are running fine, just the VisualMonitoring algorithm does not run (do nothing).
I got this when the library was not compiled against PandoraMonitoring.
#18 Updated by Eldwan Brianne 3 months ago
John contacted me about this. It was maybe related to a problem with the PandoraPFA external package build and an argument that is not passed.
However I checked this and this is not the case. The LCContent library is linked against PandoraMonitoring library when building PandoraPFA v03-15-00 using the command
cmake -DCMAKE_MODULE_PATH=$ROOTSYS/etc/cmake -DPANDORA_MONITORING=ON -DPANDORA_EXAMPLE_CONTENT=OFF -DPANDORA_LAR_CONTENT=OFF -DPANDORA_LC_CONTENT=ON ..
Looking at the current scisoft build, the libLCContent.so and libPandoraMonitoring.so are built, however the command
linux-vdso.so.1 => (0x00007ffe2ed49000) libPandoraSDK.so.03.04 => /cvmfs/larsoft.opensciencegrid.org/products/pandora/v03_15_00/Linux64bit+3.10-2.17-e19-prof/lib/libPandoraSDK.so.03.04 (0x00007f81a7aa8000) libstdc++.so.6 => /cvmfs/dune.opensciencegrid.org/products/dune/gcc/v8_2_0/Linux64bit+3.10-2.17/lib64/libstdc++.so.6 (0x00007f81a7724000) libm.so.6 => /lib64/libm.so.6 (0x00007f81a7422000) libgcc_s.so.1 => /cvmfs/dune.opensciencegrid.org/products/dune/gcc/v8_2_0/Linux64bit+3.10-2.17/lib64/libgcc_s.so.1 (0x00007f81a720a000) libc.so.6 => /lib64/libc.so.6 (0x00007f81a6e3c000) /lib64/ld-linux-x86-64.so.2 (0x00007f81a8223000)
Somehow, it is not linked against libPandoraMonitoring.so. This should normally be done automatically if PandoraMonitoring package is build with the option
according to the instructions in the README here