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!)

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?

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?

Unblushes!

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...

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...