Bug #1757
Unable to run against CDB geometry on onrec03
100%
Description
Unable to process data -- reconstruct, or simulate, against the CDB geometry on miceonrec03/02. G4GDMLRead failure.
Updated by Rajaram, Durga about 8 years ago
The error is:
[mice@miceonrec03 .maus_trunk]$ python bin/analyze_data_offline.py -daq_data_path ../.maus_release -daq_data_file 7367 -simulation_geometry_filename files/geometry/download/ParentGeometryFile.dat >Server: MICE Production Server - Public read only interface 1.1.3 Welcome to MAUS: Process ID (PID): 25485 Program Arguments: ['bin/analyze_data_offline.py', '-daq_data_path', '../.maus_release', '-daq_data_file', '7367', '-simulation_geometry_filename', 'files/geometry/download/ParentGeometryFile.dat'] Version: MAUS release version 1.1.0 Unpacker: StepIV Initialising Globals Using /home/mice/MAUS/.maus_trunk/files/geometry/download/Step_IV.gdml -------- EEEE ------- G4Exception-START -------- EEEE ------- *** G4Exception : InvalidRead issued by : G4GDMLRead::Read() Empty document! *** Fatal Exception *** core dump *** -------- EEEE -------- G4Exception-END --------- EEEE ------- *** G4Exception: Aborting execution *** Aborted
Tried on release branch, as well as on onrec02 with same result.
onrec03 is an SL6.4 machine -- one on which we plan to run our data reconstruction.
Able to run against ParentGeometry on my Fermilab box running SLF6.4.
Any idea why onrec0x is behaving this way?
Updated by Rajaram, Durga about 8 years ago
The integration test
tests/integration/test_utilities/test_geometry/test_latest_geometry.pyalso fails with the same error.
Updated by Bayes, Ryan about 8 years ago
I was not able to reproduce this error on the trunk or release 1.0.0 on my local machine.
I also logged in to onrec02 and ran
python tests/integration/test_utilities/test_geometry/test_latest_geometry.py
from the /home/mice/MAUS/.maus_release directory. This reproduced Durga's failure. Looking at the Step_IV.gdml file (the location of the error) presents no obvious anomalies.
To extract a little more information about the error I ran
../bin/simulate_mice.py --simulation_geometry_filename /home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/ParentGeometryFile.dat --verbose_level 0
from /home/mice/MAUS/.maus_release/tmp directory produces a little more information. After a bunch of stuff, I get
Using /home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/Step_IV.gdml G4GDML: Reading '/home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/Step_IV.gdml'... G4GDML: VALIDATION ERROR! unable to connect socket for URL 'http://service-spi.web.cern.ch/service-spi/app/releases/GDML/schema/gdml.xsd' at line: 0 G4GDML: VALIDATION ERROR! fatal error during schema scan at line: 2 -------- EEEE ------- G4Exception-START -------- EEEE ------- *** G4Exception : InvalidRead issued by : G4GDMLRead::Read() Empty document! *** Fatal Exception *** core dump *** -------- EEEE -------- G4Exception-END --------- EEEE ------- *** G4Exception: Aborting execution ***
which basically means it is trying to use the web to access an external style sheet and GEANT4 cannot access the web.
I note that there is a local copy of this style sheet in MAUS that we do not use at $MAUS_ROOT_DIR/src/common_py/geometry/GDML_3_0_0/schema/gdml.xsd. If I exchange the web reference for the local file, the simulation runs with no problem. (Incidentally the doctored file is on onrec02 as "/home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/ParentGeometryFile.dat" for a short term solution.)
I am building release 1.1.0 on my local system to verify that the problem is not version dependent but it looks more like it is a network issue. The course of action is to either make sure that the network can access the style sheet or make the style sheet reference local. Most people will likely prefer the second option. To make the second option work requires a software intervention at the geometry formatting stage that replaces the default "xsi:noNamespaceSchemaLocation" with a local reference --- no worse than replacing the local file references in the GDML with absolute path names.
Updated by Bayes, Ryan about 8 years ago
I was not able to reproduce this error on the trunk or release 1.0.0 on my local machine.
I also logged in to onrec02 and ran
python tests/integration/test_utilities/test_geometry/test_latest_geometry.py
from the /home/mice/MAUS/.maus_release directory. This reproduced Durga's failure. Looking at the Step_IV.gdml file (the location of the error) presents no obvious anomalies.
To extract a little more information about the error I ran
../bin/simulate_mice.py --simulation_geometry_filename /home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/ParentGeometryFile.dat --verbose_level 0
from /home/mice/MAUS/.maus_release/tmp directory produces a little more information. After a bunch of stuff, I get
Using /home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/Step_IV.gdml G4GDML: Reading '/home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/Step_IV.gdml'... G4GDML: VALIDATION ERROR! unable to connect socket for URL 'http://service-spi.web.cern.ch/service-spi/app/releases/GDML/schema/gdml.xsd' at line: 0 G4GDML: VALIDATION ERROR! fatal error during schema scan at line: 2 -------- EEEE ------- G4Exception-START -------- EEEE ------- *** G4Exception : InvalidRead issued by : G4GDMLRead::Read() Empty document! *** Fatal Exception *** core dump *** -------- EEEE -------- G4Exception-END --------- EEEE ------- *** G4Exception: Aborting execution ***
which basically means it is trying to use the web to access an external style sheet and GEANT4 cannot access the web.
I note that there is a local copy of this style sheet in MAUS that we do not use at $MAUS_ROOT_DIR/src/common_py/geometry/GDML_3_0_0/schema/gdml.xsd. If I exchange the web reference for the local file, the simulation runs with no problem. (Incidentally the doctored file is on onrec02 as "/home/mice/MAUS/.maus_release/tmp/test_latest_geometry_70/geometry/ParentGeometryFile.dat" for a short term solution.)
I am building release 1.1.0 on my local system to verify that the problem is not version dependent but it looks more like it is a network issue. The course of action is to either make sure that the network can access the style sheet or make the style sheet reference local. Most people will likely prefer the second option. To make the second option work requires a software intervention at the geometry formatting stage that replaces the default "xsi:noNamespaceSchemaLocation" with a local reference --- no worse than replacing the local file references in the GDML with absolute path names.
Updated by Bayes, Ryan about 8 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
I have corrected the problem so that the local schema are accessed by the geometry. The solution has been tested, and I have submitted it to the maus trunk. I think this issue is now done.