Bug #1263
Special VirtualPlane Z-Position
0%
Description
In my *OpticsModel unit tests I setup virtual planes for use in building transfer maps as follows:
MAUS::VirtualPlaneManager * virtual_plane_manager = new MAUS::VirtualPlaneManager();
...
MAUS::VirtualPlane virtual_plane = MAUS::VirtualPlane::BuildVirtualPlane(
CLHEP::HepRotation(), CLHEP::Hep3Vector(0., 0., z), -1, true,
z, BTTracker::z, MAUS::VirtualPlane::ignore, false);
virtual_plane_manager->AddPlane(new MAUS::VirtualPlane(virtual_plane), NULL);
...
MAUS::MAUSGeant4Manager::GetInstance()>SetVirtualPlanes(virtual_plane_manager);
I've determined that if -1 < z < 1 then a single virtual plane will be placed at z = -2147.48. I can obviously work around this by shifting my virtual planes to be asymmetric with respect to the origin, but I'm assuming this shouldn't be happening.
Updated by Lane, Peter almost 10 years ago
Apparently other values of z also cause this behaviour, but I see no pattern.
Updated by Rogers, Chris almost 10 years ago
I am looking at
bzr+ssh://bazaar.launchpad.net/~plane1/maus/devel/
file
tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc
let me know if that is not right.
Updated by Rogers, Chris almost 10 years ago
Pushed to lp:~chris-rogers/maus/1263 with diff
=== modified file 'tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc'
--- tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc 2013-04-26 23:34:58 +0000
+++ tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc 2013-04-29 09:43:27 +0000
@@ -98,7 +98,7 @@
MAUS::GlobalsManager::DeleteGlobals();
MAUS::GlobalsManager::InitialiseGlobals(config_string);
-
+ std::cerr << kPrimaryPlane << std::endl;
simulation->SetVirtualPlanes(virtual_planes_);
MAUS::VirtualPlane start_plane = MAUS::VirtualPlane::BuildVirtualPlane(
CLHEP::HepRotation(), CLHEP::Hep3Vector(0., 0., kPrimaryPlane), -1,
@@ -116,6 +116,11 @@
-1, true, kPrimaryPlane+2000., BTTracker::z, MAUS::VirtualPlane::ignore,
false);
virtual_planes_->AddPlane(new MAUS::VirtualPlane(end_plane), NULL);
+
+ for (size_t i = 0; i < virtual_planes_->GetPlanes().size(); ++i) {
+ std::cerr << virtual_planes_->GetPlanes()[i]->GetPosition() << std::endl;
+ }
+
}
~LinearApproximationOpticsModelTest() {
Runnning
rm build/test_cpp_unit; scons -j8; ./build/test_cpp_unit --gtest_filter=LinearApproximationOpticsModelTest.*
Gives
<snip build crud> Initialising Globals Checking overlaps for volume Box ... OK! Note: Google Test filter = LinearApproximationOpticsModelTest.* [==========] Running 3 tests from 1 test case. [----------] Global test environment set-up. [----------] 3 tests from LinearApproximationOpticsModelTest [ RUN ] LinearApproximationOpticsModelTest.Constructor 10 (0,0,10) (0,0,1010) (0,0,2010) [ OK ] LinearApproximationOpticsModelTest.Constructor (6 ms) [ RUN ] LinearApproximationOpticsModelTest.Accessors 10 (0,0,10) (0,0,1010) (0,0,2010) [ OK ] LinearApproximationOpticsModelTest.Accessors (7 ms) [ RUN ] LinearApproximationOpticsModelTest.Transport 10 (0,0,10) (0,0,1010) (0,0,2010) [ OK ] LinearApproximationOpticsModelTest.Transport (955 ms) [----------] 3 tests from LinearApproximationOpticsModelTest (968 ms total) [----------] Global test environment tear-down [==========] 3 tests from 1 test case ran. (968 ms total) [ PASSED ] 3 tests.
This looks correct. What is the error you are seeing? Maybe the virtual plane output is reporting tracks that stepped to the wrong point?
Updated by Rogers, Chris almost 10 years ago
Should say I used bzr+ssh://bazaar.launchpad.net/~plane1/maus/devel/ as source as of this morning (I think r729)
Updated by Lane, Peter almost 10 years ago
Chris,
That is indeed one of the tests I had trouble with. The planes as they are now don't cause an error. I tried various values until the test didn't fail. If you change the value of kPrimaryPlane (about line 154) to, say, -1000 it will cause the planes to be at -1000, 0, and 1000. This should cause the error I was getting.
Updated by Rogers, Chris almost 10 years ago
- Target version set to Future MAUS release
That is still working okay for me. Committed as r731 in bzr+ssh://bazaar.launchpad.net/~chris-rogers/maus/1263/
=== modified file 'tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc'
--- tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc 2013-04-29 09:45:08 +0000
+++ tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc 2013-04-29 13:17:03 +0000
@@ -69,7 +69,7 @@
std::stringstream reference_particle_string;
reference_particle_string
<< std::setprecision(1)
- << "{\"position\":{\"x\":0.0,\"y\":0.0,\"z\":" << kPrimaryPlane << "},"
+ << "{\"position\":{\"x\":0.0,\"y\":0.0,\"z\":" << kPrimaryPlane-1e3 << "},"
<< "\"momentum\":{\"x\":0.0,\"y\":0.0,\"z\":200.0},"
<< "\"particle_id\":-13,\"energy\":226.1939223,\"time\":0.0,"
<< "\"random_seed\":2}";
@@ -155,7 +155,7 @@
// *************************************************
// LinearApproximationOpticsModelTest static const initializations
// *************************************************
-const double LinearApproximationOpticsModelTest::kPrimaryPlane = 10;
+const double LinearApproximationOpticsModelTest::kPrimaryPlane = -1000;
const double LinearApproximationOpticsModelTest::kCovariances[36] = {
0., 1., 2., 3., 4., 5.,
1., 2., 3., 4., 5., 6.,
yields some test fails, but I think they are okay to fail (i.e. time at the plane is wrong because the plane has moved)
Initialising Globals Checking overlaps for volume Box ... OK! Note: Google Test filter = LinearApproximationOpticsModelTest.* [==========] Running 3 tests from 1 test case. [----------] Global test environment set-up. [----------] 3 tests from LinearApproximationOpticsModelTest [ RUN ] LinearApproximationOpticsModelTest.Constructor -1000 (0,0,-1000) (0,0,0) (0,0,1000) [ OK ] LinearApproximationOpticsModelTest.Constructor (6 ms) [ RUN ] LinearApproximationOpticsModelTest.Accessors -1000 (0,0,-1000) (0,0,0) (0,0,1000) tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc:184: Failure Value of: primary_plane Actual: -2000 Expected: kPrimaryPlane Which is: -1000 [ FAILED ] LinearApproximationOpticsModelTest.Accessors (5 ms) [ RUN ] LinearApproximationOpticsModelTest.Transport -1000 (0,0,-1000) (0,0,0) (0,0,1000) tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc:201: Failure Value of: output_vector Actual: t: -2.7462090236901948e-05E: 226x: 1Px: 0y: 3Py: 0 Expected: input_vector Which is: t: 0E: 226x: 1Px: 0y: 3Py: 0 tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc:222: Failure The difference between expected_vector[index] and output_vector[index] is 3.7733274620902368, which exceeds 5.0e-4, where expected_vector[index] evaluates to 3.7732999999999999, output_vector[index] evaluates to -2.7462090236901948e-05, and 5.0e-4 evaluates to 0.00050000000000000001. tests/cpp_unit/Optics/LinearApproximationOpticsModelTest.cc:234: Failure The difference between expected_vector[index] and output_vector[index] is 3.7735549425047719, which exceeds 5.0e-4, where expected_vector[index] evaluates to 3.7732999999999999, output_vector[index] evaluates to 7.5468549425047717, and 5.0e-4 evaluates to 0.00050000000000000001. [ FAILED ] LinearApproximationOpticsModelTest.Transport (963 ms) [----------] 3 tests from LinearApproximationOpticsModelTest (974 ms total) [----------] Global test environment tear-down [==========] 3 tests from 1 test case ran. (974 ms total) [ PASSED ] 1 test. [ FAILED ] 2 tests, listed below: [ FAILED ] LinearApproximationOpticsModelTest.Accessors [ FAILED ] LinearApproximationOpticsModelTest.Transport
Perhaps you should push a version which fails (could be to a bug branch if you want to keep devel clean).
Updated by Rogers, Chris almost 10 years ago
Nb valgrind reports no memory issues (main source of e.g. non-reproducible bugs).
Updated by Lane, Peter almost 10 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
No, the error was a result of a bad hit z. My code was the problem, though. I had a faulty rounding statement that I used to generate consistent z->hit map keys. I was then using the key instead of the actual hit's z for calculations. Sorry for wasting your time.
Updated by Rogers, Chris almost 10 years ago
- Status changed from Closed to Rejected
- % Done changed from 100 to 0
Okay no problem
Cheers,
chris