Project

General

Profile

Feature #1284

Spin Tracking

Added by Rogers, Chris over 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
Simulation
Target version:
Start date:
05 June 2013
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

We would like to enable spin tracking.

#1

Updated by Rogers, Chris over 8 years ago

In order to enable spin tracking in MAUS we need to:

  1. Edit src/legacy/Simulation/MICEDetectorConstruction.(hh,cc) to enable spin tracking according to instructions here Investigate whether there is an electromagnetic+spin equation of motion. Write tests to check that spin tracking works in dipole and electrostatic field. Spin tracking should be controlled via an option "enable_spin_tracking" in configuration defaults. Write tests.
  2. Edit src/common_cpp/Simulation/MICEPrimaryGeneratorAction.(hh,cc) and src/common_cpp/Datastructure/Primary.hh,cc to add sx, sy, sz to primaries. Write tests.
  3. Edit src/map/MapPyBeamMaker/beam.py to add polarisation as an option in beam generation. Spin is distributed over a sphere of radius 1 in sx, sy, sz space. Should parameterise the distribution and enable to set polarisation levels (to be investigated how to do this). Write tests.
  4. Edit src/common_cpp/Simulation/VirtualPlanes.hh,cc and src/common_cpp/Simulation/VirtualHit.hh to add polarisation as an output from virtual planes. Write or modify existing tests.
  5. Add an integration test at tests/integration/test_simulation/test_spin_tracking.py which generates a polarised beam, tracks it through an electromagnetic field map and writes it to virtual detector. Verify that the beam generated is polarised; that the output beam is polarised; and that the polarisation processes in the expected way.
#2

Updated by Rogers, Chris over 8 years ago

  • Category set to Simulation
  • Assignee set to Middleton, Sophie
  • Target version set to Future MAUS release
#3

Updated by Rogers, Chris over 8 years ago

On item 1. It looks like there is an EM spin tracker G4EqEMFieldWithSpin.hh. Tests should be at unit level, presumably at first we can only check that spin tracking equation of motion is enabled. Subsequently presumably we can make the tests (item 5 in list above). I notice the Geant4 documentation talks about ClassicalRK4, we should check that things work with the other steppers (or throw an exception if it doesnt and make appropriate tests).

Tests should be added in tests/cpp_unit/Simulation/MICEDetectorConstructionTest.cc

Let me know when you have finished this, have all the tests ready and we can look at the code you have written then go on to think about item 2.

(But finish the MCS and energy loss work you are doing before starting this new work).

#4

Updated by Rogers, Chris about 8 years ago

Following r982 that implements #1293, there has been some cleanup of the code in simulation. src/legacy/Simulation/MICEDetectorConstruction.(hh,cc) has been moved to src/common_cpp/Simulation/DetectorConstruction.hh and tests have been extended.

Note also the useful documentation at

http://micewww.pp.rl.ac.uk/projects/maus/wiki > MAUS Documentation > Running the Monte Carlo

explains the general set up of the Geant4 stuff and beam definition. Probably we will want to go through this at some point.

#5

Updated by Rogers, Chris almost 8 years ago

By email from Sophie:

I've added some code to the Detector Consturction.cc which creates a "spintacker" as a stepper type using the code in the link provided on Mice 1284 . I've
started writing tests but not really sure how to test this for dipole and electrostatic fields so am reading around this now.

Well, do what you can - it may be that to get output you need to modify e.g. src/common_cpp/DataStructure/Step.(hh,cc) and code in src/common_cpp/Simulation/MAUSSteppingAction.(hh,cc). Then step through in verbose stepping mode. For an example see the tests in tests/cpp_unit/Simulation/DetectorConstructionTest.cc - note I pushed this code to the trunk only on Tuesday or Wednesday last week.

#6

Updated by Rogers, Chris almost 8 years ago

I think the concept of beam.py is to sample e.g. momentum from some user-chosen pdf. So I would implement two options:

  • polarisation is sampled from a flat distribution (randomly assigned direction)
  • polarisation is sampled from a distribution with some direction, and width
    • Hmm, this looks quite complicated: https://en.wikipedia.org/wiki/Kent_distribution?
    • Given that we just want a direction and some spread, it might be more expedient to:
      1. Make a vector like (Gauss(x), Gauss(y), Gauss(z))
      2. Normalise to unit length

The normal input in ConfigDefaults.py looks like

    { # as above...
        "reference":{
            "position":{"x":0.0, "y":-0.0, "z":-6400.0},
            "momentum":{"x":0.0, "y":0.0, "z":1.0},
            "particle_id":-11, "energy":200.0, "time":0.0, "random_seed":10
        },
        "random_seed_algorithm":"incrementing_random",
        "weight":8.,
       "transverse":{"transverse_mode":"constant_solenoid", "emittance_4d":6.,
            "normalised_angular_momentum":0.1, "bz":4.e-3},
       "longitudinal":{"longitudinal_mode":"sawtooth_time",
                   "momentum_variable":"p",
                   "sigma_p":25.,
                   "t_start":-1.e6,
                   "t_end":+1.e6},
        "coupling":{"coupling_mode":"none"}
    }

You should maintain backwards compatibility, so if polarisation is not specified polarisation is assumed to be backwards compatible. If polarisation is specified, for example if you implement routine above, you could make the user interface like this:

    {
        "reference":{
... etc as above ...
        "coupling":{"coupling_mode":"none"}
        "beam_polarisation":{
             "polarisation_mode":"Gaussian_Unit_Vectors",
             "sigma_x":1.,
             "mean_x":0.,
             "sigma_y":1.,
             "mean_y":0.,
             "sigma_z":1.,
             "mean_z":0.
        }
    }

On 10/10/13 10:43, Middleton, Sophie wrote:> Hi,

I'm still working on item 3 on the list and getting polarisation into beam.py. I've created two functions get polarisation and set polarisation. the get will just return a value and the set will hopefully set the polarisation of some hit i've made. Does this sound like a good way to go about this?

Thanks,
Sophie

#7

Updated by Rogers, Chris over 7 years ago

Extra job - need to add polarised decays as per

geant4/examples/extended/field/field05 

This should be added in src/common_cpp/Simulation/MAUSPhysicsList.cc at MAUSPhysicsList::SetSpecialProcesses and controlled by a boolean flag like polarised_decay set from MAUSPhysicsList::Setup

#8

Updated by Rogers, Chris over 7 years ago

Polarised decays were added. Control is via the control variables

  • spin_tracking
  • polarised_decays
  • beam/beam_polarisation

Documentation to follow...

#9

Updated by Rogers, Chris over 7 years ago

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

Code pushed in r714; Documentation pushed in r715

#10

Updated by Rajaram, Durga over 7 years ago

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

Also available in: Atom PDF