Project

General

Profile

Support #23835

Support for Geant4Reweight package

Added by Jacob Calcutt about 2 months ago. Updated 11 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
01/07/2020
Due date:
% Done:

100%

Estimated time:
2.00 h
Spent time:
Scope:
Internal
Experiment:
DUNE
SSI Package:
Co-Assignees:
Duration:

Description

I'd like to create a ups product for some code I've developed that will be used by members of DUNE, NOvA, and MicroBooNE. It's already buildable through mrb, and depends on geant4 + root.

Here is the redmine page:
https://cdcvs.fnal.gov/redmine/projects/geant4reweight

Please let me know what other info I can provide

Thank you
- Jake Calcutt

History

#1 Updated by Lynn Garren about 2 months ago

  • Status changed from New to Feedback

I see that you use the cmake command line instructions to pick up the appropriate release of geant4. This is fragile. Any product in ups will depend on an explicit release of geant4. That will need to be part of the table file - and encapsulated in ups/product_deps. There are a couple of ways to do that. Are you and interested parties available for a short meeting sometime this week?

#2 Updated by Jacob Calcutt about 2 months ago

Are you referring to the README instructions for installing? If so, they're a bit outdated and I've updated them to build with buildtool.

I've avoided having a specific version of geant be required as different experiments will have different requirements, but I suppose this could be achieved by having different releases.

I'm available to have a meeting this week. Should I invite the various interested users?

#3 Updated by Lynn Garren about 2 months ago

Yes, please. Please also include Kyle and Chris. Are you able to use the outlook calendar?

#4 Updated by Cathal Sweeney about 1 month ago

The versions of ROOT and Geant4 NOvA is currently using v6_16_00 and v4_10_4_p02b respectively. I've been using geant4reweight with these versions without any issue.

#5 Updated by Jacob Calcutt about 1 month ago

DUNE:

Geant: v4_10_3_p03e

ROOT: v6_18_04b

#6 Updated by Jacob Calcutt about 1 month ago

I've added Lynn and Kyle as Developers

#7 Updated by Kirsty Duffy about 1 month ago

MicroBooNE uses:

Geant4 v4_10_3_p03c
Root v6_12_06a

#8 Updated by Lynn Garren about 1 month ago

The latest LArSoft release (v08_39_00) uses root v6_18_04b and geant4 v4_10_3_p03e.

So we have the following sets:
  • root v6_18_04b and geant4 v4_10_3_p03e
  • root v6_12_06a and geant4 v4_10_3_p03c
  • root v6_16_00 and geant4 v4_10_4_p02b

#9 Updated by Lynn Garren about 1 month ago

  • Estimated time set to 2.00 h
  • Assignee changed from Jacob Calcutt to Lynn Garren
  • Status changed from Feedback to Assigned

#10 Updated by Lynn Garren about 1 month ago

  • Status changed from Assigned to Feedback

I see that the top level CMakeLists.txt file contains find_ups_product(art) and there are art and canvas libraries in various link lists. Were these just left over, or does the code indeed use art?

Lynn

#11 Updated by Jacob Calcutt about 1 month ago

Lynn Garren wrote:

I see that the top level CMakeLists.txt file contains find_ups_product(art) and there are art and canvas libraries in various link lists. Were these just left over, or does the code indeed use art?

Lynn

These are left over. I'll go ahead and start trimming this

#12 Updated by Jacob Calcutt about 1 month ago

I'm having some issues getting this to work right. I'll have to spend a bit of time making this independent of art, art_make, etc.

#13 Updated by Kyle Knoepfel about 1 month ago

Thanks, and let us know when you have something for us to package. Also, let us know if you need help.

#14 Updated by Jacob Calcutt about 1 month ago

Hi all,

I've changed the CMake build a bit. I removed the art dependence and changed how it's linked (took out the 'art_make_library' portion to link everything 'by-hand'.

It works within and without mrb so I think it should be good. I left the art_make stuff that is activated with a compiler flag that I had for testing. I'll go ahead and comment this all out so it's not so messy/confusing.

I think it should be good to go, but please let me know if it's still not working or if you see anything glaringly wrong.

Thanks
- Jake

#15 Updated by Lynn Garren about 1 month ago

  • Status changed from Feedback to Assigned

Thanks Jacob. FYI: as long as you are using cetbuildtools, you can call cet_make instead of art_make_library.

#16 Updated by Jacob Calcutt about 1 month ago

Thanks. I'm trying to port back over to cet_make now. Getting this error:

[100%] Linking CXX shared library ../../../lib/libPredictionBaseLib.so
/usr/bin/ld: cannot find -lcetlib
/usr/bin/ld: cannot find -lcetlib_except
/usr/bin/ld: cannot find -lclhep

I fixed this before by linking 'by-hand'

I'm using find_ups_product to find this in the top-level CMakesList, then using the following to create that library:
2 cet_make_library( LIBRARY_NAME PredictionBaseLib
3 SOURCE
4 G4CascadeDetectorConstruction.cc
5 G4CascadePhysicsList.cc
6 LIBRARIES
7 ${FHICLCPP}
8 cetlib cetlib_except
9 clhep
10 #CLHEP
11 ${G4EVENT}
12 ${G4INTERCOMS}
13 ${G4INTERFACES}
14 ${G4RUN}
15 ${G4TRACKING}
16 ${G4MATERIALS}
17 ${G4GEOMETRY}
18 ${G4GLOBAL}
19 ${G4PERSISTENCY}
20 ${G4PHYSICSLISTS}
21 ${ROOT_BASIC_LIB_LIST}
22 )
23 install_headers()
24 install_source()

Are there extra steps I need to do to define lclhep, etc.?

#17 Updated by Lynn Garren about 1 month ago

Hum, so you do still depend on cetlib and fhicl.

Try these:

${CETLIB}
${CETLIB_EXCEPT}
${CLHEP}

#18 Updated by Jacob Calcutt about 1 month ago

I was able to get it working with clhep, and ${CETLIB}

and also had to throw this in at the top-level
find_library( CETLIB NAMES cetlib PATHS $ENV{CETLIB_LIB} )
find_library( CETLIB_EXCEPT NAMES cetlib_except PATHS $ENV{CETLIB_EXCEPT_LIB} )
find_library( CLHEP NAMES CLHEP PATHS $ENV{CLHEP_LIB_DIR} )

#19 Updated by Lynn Garren about 1 month ago

  • Status changed from Assigned to Feedback

Since this package uses fhicl, it relies in part on the art framework. It will be necessary to make sure that the correct releases of geant4, root, and fhicl are used. Given that this is the case, it makes sense to use the appropriate s qualifier. In addition, ups/product_deps will setup either nug4 or (for older releases) nutools. This pulls in the correct set of dependencies and avoids any release mismatches, which can be painfully difficult to debug.

The changes necessary to do this are in feature branch feature/lg_use_quals.

LArSoft requires that this build for both e19 and c7. The good news is that both e17 and e19 build nicely. The bad news is that both c2 and c7 builds fail. The build failures have caught bugs in the code that need fixing.

unimplemented function

/home/garren/devel/lar/geant4reweight/geant4reweight/src/ReweightBase/G4ReweightTraj.hh:80:5: error: control may reach end of non-void function [-Werror,-Wreturn-type]
    };
    ^

In fact, the code in question performs a check but returns no value:
    double GetWeight( size_t i ){
      if( i > weights.size() - 1 ){
        std::cout << "Error: out of weights vector range" << std::endl;
        return -1;
      }
    };

uninitialized variables

clang complains that the first use of these variables is uninitialized.

/home/garren/devel/lar/geant4reweight/geant4reweight/app/PredictionBase/G4CrossSection.cc:156:16: error: variable 'proton' is uninitialized when used here [-Werror,-Wuninitialized]
    part_def = proton->Definition();
               ^~~~~~
/home/garren/devel/lar/geant4reweight/geant4reweight/app/PredictionBase/G4CrossSection.cc:141:20: note: initialize the variable 'proton' to silence this warning
  G4Proton * proton;
                   ^
/home/garren/devel/lar/geant4reweight/geant4reweight/app/PredictionBase/G4CrossSection.cc:151:16: error: variable 'piminus' is uninitialized when used here [-Werror,-Wuninitialized]
    part_def = piminus->Definition();
               ^~~~~~~
/home/garren/devel/lar/geant4reweight/geant4reweight/app/PredictionBase/G4CrossSection.cc:140:24: note: initialize the variable 'piminus' to silence this warning
  G4PionMinus * piminus;
                       ^
/home/garren/devel/lar/geant4reweight/geant4reweight/app/PredictionBase/G4CrossSection.cc:146:16: error: variable 'piplus' is uninitialized when used here [-Werror,-Wuninitialized]
    part_def = piplus->Definition();
               ^~~~~~
/home/garren/devel/lar/geant4reweight/geant4reweight/app/PredictionBase/G4CrossSection.cc:139:23: note: initialize the variable 'piplus' to silence this warning
  G4PionPlus  * piplus;
                      ^

#20 Updated by Jacob Calcutt about 1 month ago

I'll start work on fixing these

#21 Updated by Jacob Calcutt about 1 month ago

Fixed these and tested with c2 and c7. The builds succeeded.

I pushed the changes to your branch

#22 Updated by Lynn Garren about 1 month ago

Thanks Jacob. feature/lg_use_quals now builds successfully for the supported options. The next step is to merge the feature branch with master and make the first tag. I propose that the first release be v01_00_00 (or v1_00_00 if you prefer). Any problems? Do you want to merge and tag, or shall I do that?

FYI, the head of master is using a random v08 release number that apparently was copied from some larsoft repository. We don't want to perpetuate that number.

#23 Updated by Jacob Calcutt about 1 month ago

Just merged, tagged v01_00_00, and pushed :)

#24 Updated by Lynn Garren about 1 month ago

Super! I'll add it to this weeks' larsoft distribution. I will also provide a standalone build script that can be used by a simple Jenkins job.

#25 Updated by Jacob Calcutt about 1 month ago

Great thank you so much for all the help! This will also be available outside of larsoft (for NOvA users), right?

#26 Updated by Lynn Garren about 1 month ago

Yes, it will. I'll be moving it from the larsoft distribution to the nulite distribution, which is used by both NOvA and LArSoft. Just put it in the larsoft distribution for now to get it out for larsoft.

#27 Updated by Lynn Garren about 1 month ago

  • % Done changed from 0 to 70
  • Status changed from Feedback to Assigned

geant4reweight v01_00_01 has been distributed with larsoft v08_40_00 and is available under /cvmfs/larsoft.opensciencegrid.org/products.

#28 Updated by Cathal Sweeney about 1 month ago

Thanks everyone! Just to note - NOvA uses the e17 GCC qualifier. Once it comes to distributing the product to NOvA it would be great if that could be added, if possible.

#29 Updated by Lynn Garren about 1 month ago

Not a problem. Building for e17 is already an option.

#30 Updated by Jacob Calcutt about 1 month ago

Thanks for all the help Lynn,

I see a bug that needs fixing. When I submit a new tag (i.e. v01_00_02) is there an automatic build, or do I need to make a request?

#31 Updated by Lynn Garren about 1 month ago

We have no mechanism for automatically picking up changes in the package. If you make changes for any reason, please send email to .

Note that I have already tagged a new release for use with art 3.04.

#32 Updated by Kirsty Duffy about 1 month ago

Thanks for the work on this! To add to the MicroBooNE requirements: for our production branch we will need builds with qualifiers e17, c2, and s78 (as well as dependencies on root v6_12_06a and geant4 v4_10_3_p03c). Will that be possible to make?

#33 Updated by Lynn Garren 22 days ago

  • % Done changed from 70 to 80

I have provided the nulite v3_01_04a distribution, which includes geant4reweight built with s85 for NOvA.

#34 Updated by Lynn Garren 21 days ago

  • % Done changed from 80 to 100
  • Status changed from Assigned to Resolved

There is now a nulite v2_27_06a distribution which contains geant4reweight built for s78 (MicroBooNE production). This geant4reweight is installed on the larsoft cvmfs.

#35 Updated by Cathal Sweeney 21 days ago

Having some trouble installing nulite v3_01_04a. Has EventDisplayBase now moved from nutools to nuevdb - and if so which version of nuevdb should NOvA install?

#36 Updated by Lynn Garren 21 days ago

Cathal, are you using pullProducts? It should pull everything you need. What exactly is the problem?

 ./pullProducts `pwd` slf7 nulite-v3_01_04a s85-e17 prof

nutools v3_01_04 has nuevdb split out. However, NOvA can continue to use nutools v3_01_03 until you are ready to upgrade.

#37 Updated by Cathal Sweeney 21 days ago

Ah ok, I assumed that we would need to setup the new version of nutools, so I had updated our setup script accordingly. Well I suppose now is as good a time as any to switch. I am part way through installing nuevdb v1_01_02.

#38 Updated by Lynn Garren 21 days ago

My apologies, I actually believe you need nuevdb v1_00_00, which should have been in the nulite v3_01_04a distribution. I am updating the distribution with nuevdb v1_00_00.

#39 Updated by Cathal Sweeney 21 days ago

Thanks Lynn!

#40 Updated by Cathal Sweeney 21 days ago

Just want to make sure I understand correctly. nuevdb v1_00_00 doesn't seem to exist on scisoft - has it yet to be created?

(versions I can see are 1_01_00, v1_01_01, v1_01_02, v1_02_00)

#41 Updated by Lynn Garren 21 days ago

The build has just now completed. If you run pullProducts again, you will get nuevdb v1_00_00.

#42 Updated by Lynn Garren 11 days ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF