Bug #1569
Latest geometry download fails
100%
Description
Ryan, I tried to download the latest geometry doing
python ${MAUS_ROOT_DIR}/bin/utilities/download_geometry.py --geometry_download_by id --geometry_download_id 40 --geometry_download_directory geometry >& download.log
That went smoothly, but when I tried to load the geometry I got an error like
Traceback (most recent call last):
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 528, in <module>
main()
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 522, in main
tracking.do_tracking()
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 471, in do_tracking
self._fiddle_configuration()
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 494, in _fiddle_configuration
maus_cpp.globals.birth(json.dumps(self.config))
RuntimeError: Dimension x in module ParentGeometryFile.dat/Iges_0.dat out of range at MiceModToG4Solid::checkDim
Indeed, the Iges_0.dat geometry file does not exist again. Once is an accident, twice is careless!
Files
Related issues
Updated by Bayes, Ryan about 9 years ago
Indeed. Twice is careless.
Geometry ID 40 contains a file "FastRad.gdml" which contains the "Iges_0.gdml" reference. With both this file and the Step_IV.gdml file there is some kind of a (unknown) selection process to pick one over the other for the creation of the ParentGeometryFile. Geometry ID 41 has this file removed and it should work. It was in fact created for this specific reason. The alternative is to remove the functionality to build the ParentGeometryFile from a file named "FastRad.gdml" but that would break the existing Step I geometries. Also useful would be the ability to flag broken geometries as the code moves on --- altering the comment field would be useful for example.
If you are using the merge branch, use the latest geometry upload (ID 43). This contains the latest updates to the material definitions and multiple volumes to fill the cooling channel with vacuum.
Updated by Rogers, Chris about 9 years ago
- Status changed from Rejected to Open
I set up a test job that attempts a nightly download and simulate_mice.py against trunk and latest geometry on CDB. It fails! Have a look at:
http://test.mice.rl.ac.uk/view/Trunk/job/MAUS_geometry_download/
Log file is at:
http://test.mice.rl.ac.uk/view/Trunk/job/MAUS_geometry_download/ws/simulation.log/*view*/
I'm afraid this one is reopened... (but I am still blushing from previous mistake!)
Updated by Bayes, Ryan about 9 years ago
I am afraid that this cannot be the latest geometry.
There are no objects called TDm<blah> in the latest geometry. The last time that was used was one of the last geometries produced by Matthew Littlefield (maybe something like geometry ID 7 or 9). I think I need to figure out a way to log the geometry ID number.
Updated by Rogers, Chris about 9 years ago
- File test.tar.gz test.tar.gz added
- Status changed from Open to Rejected
I think I need to figure out a way to log the geometry ID number.
Yes this would be useful. If I do
python ${MAUS_ROOT_DIR}/bin/utilities/download_geometry.py --geometry_download_directory test
I get this geometry (attached as test.tar.gz). Is this downloading the geometry that is valid now?
Updated by Bayes, Ryan about 9 years ago
No it is not.
I think I know the problem though.
The default configuration downloads the geometry by ID number and currently defaults to ID number 6 (I have not changed this number).
The solution might be as simple as adding the option --geometry_download_id 41 to your command line...
Updated by Rogers, Chris about 9 years ago
- File do_geometry.log do_geometry.log added
- File do_geometry.bash do_geometry.bash added
Okay, I tried again with latest trunk, trying to get geometry 43 working (which is where I started). I ran the attached do_geometry.bash script, got the attached do_geometry.log output.
rm -r geometry
mkdir geometry
python ${MAUS_ROOT_DIR}/bin/utilities/download_geometry.py --geometry_download_directory geometry --geometry_download_id 43
python ~/MAUS/maus_merge/bin/utilities/geometry_validation.py --configuration_file configuration.py
output
Traceback (most recent call last):
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 528, in <module>
main()
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 522, in main
tracking.do_tracking()
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 471, in do_tracking
self._fiddle_configuration()
File "/home/cr67/MAUS/maus_merge/bin/utilities/geometry_validation.py", line 494, in _fiddle_configuration
maus_cpp.globals.birth(json.dumps(self.config))
RuntimeError: Dimension x in module ParentGeometryFile.dat/Iges_0.dat out of range at MiceModToG4Solid::checkDim
And now I am back where I started with mysterious Iges_x files in the geometry. Am I still doing something wrong?
Updated by Bayes, Ryan about 9 years ago
And the FastRadModel.gdml file snuck into 43. This one is mine. And again, my tests do not have a problem with it... I wonder why. It must be a system specific issue.
Anyway, I uploaded a new geometry (ID 44) with the file in question removed (and the solenoid current densities corrected to the latest 6pi200 settings).
Sorry.
Updated by Rogers, Chris about 9 years ago
- Assignee changed from Bayes, Ryan to Rogers, Chris
I think this issue closes when we have an integration test that does a nightly build and generates validation plots for the latest geometry. The point of the test server is that it is an independent arbiter (no "oops I left a local file somewhere" bugs). I can do it. Let me wait for #1567 to close (in test right now, I screwed something up so it will take another couple of hours to come into the trunk).
We probably want a release procedure whereby geometries are uploaded to http://preprodcdb.mice.rl.ac.uk/, then Ryan/whoever pushes a test job on the test server, then geometry goes into production. We could modify the upload/validation procedure to follow this route...
Updated by Rogers, Chris about 9 years ago
I added the test that the latest geometry passes, it is in test now(!) and will go into the trunk when it is ready. I also noticed that I screwed up the routine to make the 1D material plot (in #1567) so I fixed it and added an additional feature to plot off-axis materials in grey, as per the volumes plot. So materials on-axis are plotted in black, materials off-axis are plotted in grey as a function of z and slightly offset.
Updated by Rogers, Chris about 9 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Okay, I added the geometry validation test to the trunk and am now running a daily build against it. Ryan, you are encouraged to do an ad-hoc test when you upload a geometry. The test job is
http://test.mice.rl.ac.uk/view/Trunk/job/MAUS_geometry_download/
One could imagine setting up something more sophisticated, e.g. checking the preprod server, checking the cdb geometry_id number and only running if it changed, etc. As it stands this is probably quite heavy on test server load. At least this is something automated...