Project

General

Profile

Bug #1569

Latest geometry download fails

Added by Rogers, Chris almost 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Geometry
Target version:
Start date:
17 October 2014
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

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

test.tar.gz (109 KB) test.tar.gz Rogers, Chris, 17 October 2014 10:25
do_geometry.log (66.6 KB) do_geometry.log Rogers, Chris, 17 October 2014 10:43
do_geometry.bash (255 Bytes) do_geometry.bash Rogers, Chris, 17 October 2014 10:43

Related issues

Related to MAUS - Feature #1553: Geometry ComparisonClosedRogers, Chris30 September 2014

Actions
#1

Updated by Bayes, Ryan almost 7 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.

#2

Updated by Rogers, Chris almost 7 years ago

I'm an idiot!

#3

Updated by Rogers, Chris almost 7 years ago

  • Status changed from Open to Rejected
#4

Updated by Rogers, Chris almost 7 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!)

#5

Updated by Bayes, Ryan almost 7 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.

#6

Updated by Rogers, Chris almost 7 years ago

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?

#7

Updated by Bayes, Ryan almost 7 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...

#8

Updated by Rogers, Chris almost 7 years ago

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?

#9

Updated by Bayes, Ryan almost 7 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.

#10

Updated by Rogers, Chris almost 7 years ago

  • Status changed from Rejected to Open

Unblushes!

#11

Updated by Rogers, Chris almost 7 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...

#12

Updated by Rogers, Chris almost 7 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.

#13

Updated by Rogers, Chris almost 7 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...

Also available in: Atom PDF