Project

General

Profile

Bug #996

Missing TrackerSingleStation.dat in current geometry

Added by Lane, Peter over 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Littlefield, Matthew
Category:
Geometry
Target version:
Start date:
24 May 2012
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

Using download_geometry.py with geometry_download_by = 'current' I downloaded a bunch of files to files/geometry/download/. I then configured simulate_mice.py to use simulation_geometry_filename = "files/geometry/download/ParentGeometryFile.dat". The script failed with a very unhelpful stack trace and error message:

    MAUS.Go(my_input, my_map, MAUS.ReducePyDoNothing(), my_output, datacards)
  File "/home/lane/Development/maus/maus/src/common_py/Go.py", line 121, in __init__
    executor.execute()
  File "/home/lane/Development/maus/maus/src/common_py/framework/single_thread.py", line 66, in execute
    assert(self.transformer.birth(self.json_config_doc) == True)
AssertionError

Digging down into the code I was able to trace the error to MapCppSimulation.cc. The following error was not being propegated up to the user:

Dimension x in module ParentGeometryFile.dat/TrackerSingleStation.dat out of range

Upon investigation I noticed that TrackerSingleStation.dat does not exist with the rest of the downloaded geometry data files.


Files

ParentGeometryFile.dat (80.9 KB) ParentGeometryFile.dat Lane, Peter, 29 May 2012 16:23
ParentGeometryFile.dat.orig (81.1 KB) ParentGeometryFile.dat.orig Lane, Peter, 29 May 2012 16:23
45D_geometry.dat (558 Bytes) 45D_geometry.dat Littlefield, Matthew, 29 May 2012 16:51
config.py (2.44 KB) config.py Lane, Peter, 12 June 2012 15:31
90D_rotated_geometry.dat (558 Bytes) 90D_rotated_geometry.dat Lane, Peter, 12 June 2012 15:31
Detectors.png (96.2 KB) Detectors.png Picture of geometry Littlefield, Matthew, 21 June 2012 12:30
Detectors.dat (1.13 KB) Detectors.dat Dat file. Littlefield, Matthew, 21 June 2012 12:30
Detectors.dat (1.13 KB) Detectors.dat Littlefield, Matthew, 25 June 2012 14:41
config.py (2.77 KB) config.py Lane, Peter, 25 June 2012 16:11
sim.py (1.65 KB) sim.py Lane, Peter, 25 June 2012 16:11
Detectors.dat (1.13 KB) Detectors.dat Littlefield, Matthew, 26 June 2012 09:55
Config.py (6 KB) Config.py Littlefield, Matthew, 26 June 2012 11:08
config.py (2.87 KB) config.py Lane, Peter, 26 June 2012 12:12
ConfigurationDefaults.py (13.3 KB) ConfigurationDefaults.py Lane, Peter, 26 June 2012 14:05
Rotation.dat (603 Bytes) Rotation.dat Littlefield, Matthew, 02 July 2012 11:19
handover_mu_only_eng_coords.txt (920 KB) handover_mu_only_eng_coords.txt Littlefield, Matthew, 02 July 2012 11:39
#1

Updated by Littlefield, Matthew over 11 years ago

  • Category set to Geometry
  • Target version set to Future MAUS release

This will be fixed by the new release which will be out very soon. So you can do some work in the mean time if you edit ParentGeometryFile.dat and replace the block which relates to the tracker (the part which is similar to the code below but says TrackerSingleStation.dat instead) with the code below this should work.

Module Tracker/Tracker1Station1.dat
                            { 
                                Position 12634.4100 0.0000 0.0000 mm 
                                Rotation  0.0 90.0 0.0 deg 
                            }

If you also have two modules by the names of TDm1152m9336.dat and TDm1152m9334.dat in ParentGeometryFile.dat then replace them with these two modules as well,

                    Module Ckov/Cherenkov.dat
                            { 
                                Position 5841.7442 0.0127 -0.1016 mm 
                                Rotation  0.0 90.0 0.0 deg 
                            }

                    Module TOF/TOF0.dat
                            { 
                                Position 5276.3100 -0.0000 -0.0000 mm 
                                Rotation  0.0 90.0 0.0 deg 
                            }

Or you could wait for the release :-) let me know if you have any more problems. I think I'll create an issue to catch that nasty Assertion Error and try to make it a little friendlier

#2

Updated by Lane, Peter over 11 years ago

Thanks, that got it running. Unfortunately the visualisation shows my beam coming in at about a 45 degree angle. Is there some adjustment to the beam definition that needs to be made as well?

#3

Updated by Littlefield, Matthew over 11 years ago

Yeah I had the same problem as well I created an issue for it
http://micewww.pp.rl.ac.uk/issues/924

Perhaps Chris could comment?

#4

Updated by Rogers, Chris over 11 years ago

Sorry I was off looking after sick babies (and getting sick myself).

  • New release: will try to bring out today.
  • Rotation: I will try to implement this, but as a fix you could rotate the geometry through 45 degrees.
#5

Updated by Littlefield, Matthew over 11 years ago

Thats OK I hope you and the babies are feeling better :-)

Peter, I think turning the geometry will be a hassle because you would have to calculate the new x,y and z coordinat7es to the new 45 degree angles. I suggest removing D2 and its field or positioning the beam between the quads somewhere as I think you are only interested in the detectors for global geometry right? The tag for D2 is TDm1152m9345 this will be in the parent geometry file.

#6

Updated by Rogers, Chris over 11 years ago

Up to you, but you can add an extra layer of configuration. So instead of

Configuration -> TDmblahblah

You have
Configuration -> Rotated Configuration -> TDmblahblah

which I think is reasonably easy to set up (though I haven't seen the files).

ps: IIRC D1 is a 60 degree bend and D2 is a 30 degree bend.

#7

Updated by Littlefield, Matthew over 11 years ago

Yeah that will do the trick as well. So its up to you Peter. I have used Chris's way before :-)

#8

Updated by Lane, Peter over 11 years ago

Matt, since you've done this before would you happen to have an example of how to wrap and rotate a configuration?

Just for reference I've attached the original and modified (see comment #1) parent geometry files.

#9

Updated by Rogers, Chris over 11 years ago

FYI 0.2.4 is now in lp:maus ... just preparing finishing touches for the release...

#10

Updated by Littlefield, Matthew over 11 years ago

Peter, have a look at this file. I've created a new volume and placed the parent geometry in there (this should be the one with the corrections which are already working) To change the rotation of the entire geometry you should change the angles in this file I've added. I'm not sure if the angle I've added is in the correct plane (i.e. x, y or z) but if it isn't you can change it to something like

Rotation 0.0 45.0 0.0 deg

Hope this helps :-)

#11

Updated by Rogers, Chris over 11 years ago

Is this closed?

#12

Updated by Littlefield, Matthew over 11 years ago

Not quite yet I need to sort out the field orientation.

#13

Updated by Lane, Peter over 11 years ago

Pavel also brought up an issue after he looked at my visualizations. The particle starts so far away that the geometry ought to include the pre-dipole focusing section of the lattice. Otherwise the particle should be fired from right before the dipole.

I'm including my configuration file as well as my top-level geometry file that rotates everything by 90 degrees. The rest of the configuration has been modified as per Matt's instructions above.

#14

Updated by Lane, Peter over 11 years ago

Stop the presses. The 90 degree file I uploaded only rotates by 60 degrees. I was trying to compensate for another issue that Pavel brought up: the beam has to hit the dipole at an angle of ~60 degrees in order to be bent properly. So the geometry rotation isn't as simple as just rotating by 90 degrees.

#15

Updated by Littlefield, Matthew over 11 years ago

OK I'll take a look and try to get things in order. I'll get back to you soon

#16

Updated by Littlefield, Matthew over 11 years ago

Chris,

What would I have to do to implement rotating the beam to specified angles? something like,

simulation_reference_particle = { # used for setting particle phase
    "position":{"x":0.0, "y":-0.0, "z":0.0},
    "rotation":{"x":0.0, "y":-0.0, "z":0.0},
    "momentum":{"x":0.0, "y":0.0, "z":1.0},
    "particle_id":-13, "energy":226.0, "time":0.0, "random_seed":10
}

I ask because this is proving to be a little tricky and I'm wondering if trying to alter the geometry is a little hacky and if I should spend this effort making the beam rotate?

#17

Updated by Littlefield, Matthew over 11 years ago

Peter,

I have made you a geometry with only detectors in it. Hopefully this will suit your needs until I have sorted out the beam rotation. This is my priority for the moment because it would be nice to have the official geometry in your simulations. :-) I'll update you with how I'm getting on. If there's anything else you need in this geometry please give me a shout.

#18

Updated by Lane, Peter over 11 years ago

Matt,

The Detectors.dat you posted isn't generating any sci_fi_hits in the output. In my limited experience I assumed this was because no SensitiveDetector modules were defined. Digging down into the hierarchy I see that Tracker/Tracker1Station1.dat contains Tracker/TrackerView[U|W|V].dat which in fact have SensitiveDetector modules defined. I also see tracks going through the single tracker station in the VRML visualization so I'm pretty clueless. Any ideas?

#19

Updated by Rogers, Chris over 11 years ago

There was a bug where the tracker stations were only 1 mm diameter. This is fixed in the trunk, I can't remember if it was in 0.2.5 or not... there was probably an issue tracker on it.

#20

Updated by Littlefield, Matthew over 11 years ago

Ah OK. I got the same thing actually so maybe their updated tracker isn't in our simulation or I'm using the wrong one. I'll ask Adam and see what he says. Peter, you could change that single station model to just the normal tracker as it makes no difference which one is there for you global recon.

#21

Updated by Lane, Peter over 11 years ago

Chris,

I updated to the latest trunk and now get the following error when trying to run Matt's Detector.dat:

Traceback (most recent call last):
  File "/home/lane/Development/maus/maus/src/common_py/ErrorHandler.py", line 159, in HandleCppException                                                        
    raise(CppError(error_message))                                              
ErrorHandler.CppError: Couldn't find property Tracker in module Detectors.dat at MiceModule::propertyInt                                                        
TRANSFORM/MERGE/OUTPUT:  Processed 1 spills so far, 1 spills in buffer.         

*** G4Exception : KeyExists
      issued by : G4VisListManager<T>::Register(T* ptr) 
Key Unspecified already registered                      
*** Fatal Error In Argument *** core dump ***           

*** G4Exception: Aborting execution ***
Aborted (core dumped)                  

Matt,

Could you elaborate. I don't understand what you're suggesting I do as a temporary workaround while you consult Adam.

#22

Updated by Littlefield, Matthew over 11 years ago

OK, I've just tried running the following configuration file (see attached) all I've done is put the legacy model of the Tracker as a whole in there. I get a failure with this of the following

python: src/common_cpp/DetModel/SciFi/SciFiSD.cc:95: virtual G4bool SciFiSD::ProcessHits(G4Step*, G4TouchableHistory*): Assertion `abs(chanNo-old_chanNo) < 2' failed.
Aborted

This is a problem with the tracker SciFi senstive detector code which I don't know anything about. Apologies but I think this will need to be discussed with Ed and Adam as I'm sure they will be able to help. I have asked them before what model of the tracker they are using and they said it was this one in the attached file. If its different I'll be happy to change the file for you :-)

Above is what I meant by adding the tracker have a go with this new .dat file and see if it works. I'm a little baffled by your error

ErrorHandler.CppError: Couldn't find property Tracker in module Detectors.dat at MiceModule::propertyInt

This looks like you don't have the tracker file in the location $MAUS_ROOT_DIR/src/legacy/FILES/Models/Modules/Tracker

Would you have a look to see if there is a Tracker1Station1.dat file there?

#23

Updated by Littlefield, Matthew over 11 years ago

Just edited the last comment

#24

Updated by Lane, Peter over 11 years ago

Yes, the directory is there. So for documentation purposes, here is the configuration file and modified simulate_mice.py...

#25

Updated by Littlefield, Matthew over 11 years ago

hmm that is strange that it can't see the tracker file. Perhaps try changing Tracker/Tracker blah blah in Detector.dat to the full path of that file and see if that works?

#26

Updated by Lane, Peter over 11 years ago

Yeah, tried that already. No joy.

#27

Updated by Littlefield, Matthew over 11 years ago

bummer, was it the same error message? I think we need to harass Ed and Adam ....

#28

Updated by Littlefield, Matthew over 11 years ago

Peter, try this set up that I've attached. It works for me ....

#29

Updated by Lane, Peter over 11 years ago

I'm running up against something similar to issue #978:

  • G4Exception : KeyExists
    issued by : G4VisListManager<T>::Register(T* ptr)
    Key Unspecified already registered
  • Fatal Error In Argument * core dump *
  • G4Exception: Aborting execution ***
    Aborted (core dumped)

With the default beam definition I get exactly 29 WRL files before this happens. With my single-particle beam this happens after two WRLs. Unfortunately this doesn't tell me where the error is being generated. I have the latest trunk.

#30

Updated by Littlefield, Matthew over 11 years ago

OK, well try using my configuration file?

I've just run it here and it goes to 29 WRLs then it finishes and this is with the default beam. It seems that there are only 29 created. Would you mind attaching your ConfiguratioDefaults.py file? I think I may have seen this error before but not entirely sure.

#31

Updated by Lane, Peter over 11 years ago

Something in your config file solved the problem. I can try to step through it at some point to isolate the cause. At any rate, included is my config file.

#32

Updated by Littlefield, Matthew over 11 years ago

I can't see why except maybe the accumulate_tracks tag is in mine? Would you mind posting src/common_py/ConfigurationDefaults.py please? I want make sure that it isn't to do with the coloured particles which is where I think I saw your previous error. Cheers

#33

Updated by Lane, Peter over 11 years ago

My ConfigurationDefaults.py is the same as the trunk. Attached.

#34

Updated by Littlefield, Matthew over 11 years ago

Fair enough, in that case I don't know we will have to look into it further

#35

Updated by Littlefield, Matthew over 11 years ago

Hey Peter,

I owe you an apology when doing the rotation stuff to get the beam line correct I forgot a line of code which meant it was harder than it should have been. However, to get the correct rotation of the geometry using the file I've attached and replace the code at the top of ParentGeometryFile.dat with the following

Volume Box
Dimensions 50000.0 50000.0 50000.0 mm
PropertyString Material AIR  
PropertyDouble G4StepMax 5.0 mm
PropertyBool Invisible 1

this will rotate the axis so that the cooling channel axis is along the z axis. :-) Pavel has also created G4BL file of particles which are rotated so the fire into the centre of D2s aperture. I'm working on rotating the beam in maus as well and shall let you know when its ready.

Oh, simulate on the file that is attached because using this set up ParentGeomeryFile.dat is placed within this.

To answer you email to me about the single station geometry you sent me on Sat. This geometry isn't the CAD transferred geometry it is one I have made by hand just so we have something in the ConfigDB of the single station. The actual single station geometry is being created by Jason at the moment and should include TOF1 and the other points you raised in the email :-)

Hope this is ok.

#36

Updated by Littlefield, Matthew over 11 years ago

forgot to add the G4BL file so here it is. The starting position is upstream of D2

#37

Updated by Snopok, Pavel over 11 years ago

To be more precise: right now it is 0.5 m upstream of the front face of D2 along the center line of the incoming beam, the origin of the coordinate system is at the intersection of the two straight lines corresponding to the incoming and outgoing trajectories, $z$ is the longitudinal coordinate directed towards MICE; $x$ is the horizontal transverse coordinate (pointing "to the left"), $y$ is the vertical transverse coordinate.

#38

Updated by Littlefield, Matthew about 11 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100
#39

Updated by Rogers, Chris about 11 years ago

  • Target version changed from Future MAUS release to MAUS-v0.4.0

Also available in: Atom PDF