Hi all, 

Concerning the RF, let me volunteer some 'plots' we would like to produce in MICE step V or VI. 

-- momentum in tracker  II, P2, divided by  momentum in tracker I, P1,  vs particle time in TOF1 wrt RF clock. 
(alternatively best momentum measurement available for P1  using  combination of tracker and TOF0/1, and P2 using tracker and EMR) -- this should be done for p, pz and pt

-- ibid using particle time in TOF2 or some optimal combination of TOF1 and TOF2. 

-- using suitable cuts on P1, this could be used as a way to optimize the RF phase of individual cavities wrt a global phase reference. 

-- similar plots for the helix phases Phi1 and Phi2 of the muon in the two tracker reference planes 

-- or more sophisticated quantities such as particle amplitudes A1 A2, etc.. 

Thus it seems essential that the RF clock and the RF amplitude are known on an event basis.  (this is a challenge for the controls and DAQ jobs). The phase of individual cavities wrt the reference clock for the given run are necessary too. 

I do not see (yet) the need to organize tracking of individual particles in the RF field by the reconstruction program, but this statement could be wrong if someone has a smart idea that shows this to provide a definite advantage -- I just dont see it at the moment. 

I believe on the other hand that careful modelling in the MC of the RF field vs RF phase and tracking in this field for each simulated particle is very important and should get full attention. 

my two cents. 

Alain 

 






________________________________________
From: MAUS developer mailing list [[log in to unmask]] on behalf of Christopher Tunnell [[log in to unmask]]
Sent: 11 May 2011 12:54
To: [log in to unmask]
Subject: Re: RF modelling in software

We should make a clear distinction about what parts of what we're
doing is for the 'measurement' and what parts are for the 'theory'.

I think that we should aim for having the features of spill structure,
accurate RF including it's duty cycle, etc..  However, the RF timing
is something that should probably happen at the analysis step rather
than the reconstruction step.  I say that because our life gets much
much simpler if we treat the cooling channel as a black box from the
reconstruction perspective.

The RF phases, fields, etc., is one of the things we want to measure
in MICE.  For MC truth you'll know when the RF happened using the wide
range of functionality that is in G4MICE and what you're data should
look like and will choose your null hypothesis accordingly.  MC and
data only need to agree with respect to modeling the non-cooling
channel components.  I guess I view the cooling channel as something
requiring a 'theory' that's you're statistically testing.

I guess I think digitizing the MC slow controls should be thought
about a bit before being done.

The data we'll have at the end is: 4-vector x_in and x_out, 4-vector
p_in and p_out, PID.  We will want to formulate some theory that fits
these data and that theory can depend on the geometry, RF times,
magnet currents, etc.. For data, beyond providing the information on
what we think the RF time is -- which JSG said would be in the
datastream -- so people can incorporate it in their theory, I don't
see what else we need to do.  We'll input that RF time into the
software (or some equation) to build a model that fits the data.

I hope I'm understanding you right.  Most of these accelerator tools
are useful for the analysis and R&D stuff.  'Reconstruction' can be
done either in the particle physics way or accelerator physics way
since you're just solving some equation of motion but I view that as
something logically different than what's going on in the cooling
channel.

If there's a better or different way of thinking about this, then
agreeing on this type of thing helps keep the code consistent.

On 11 May 2011, at 10:38, Chris Rogers wrote:

> Just wanted to throw out some ideas about what we do in MICE
> software to
> model the RF cavities.
>
> RF functionality exists in old G4MICE to either
> * generate a RF cavity field map either ideal pill box or SuperFish
> text
> file
> * automatically generate relative RF cavity timings for ideal phasing
> (using reference particle)
> * input relative timings for RF cavities by hand
> * input particles with arbitrary time (+ position, momentum etc)
>
> The former is what we do for all the theoretical stuff. We can hack
> together simulation of most of the "real" RF system using this
> functionality. To make it pretty, we might want to add:
>
> Monte Carlo
> -----------
> * Automatically generate a beam with MICE-like time structure
> * Model the RF pulse structure (ramp, flat top, fall off)
> * Take RF timings from data stream (presumably it will be written
> spill-by-spill in hardware)
>
> Reconstruction
> --------------
> * Modelling of RF signals from Monte Carlo? How complicated is the
> phase
> and peak E-field measurement? Do we need to model it to estimate the
> error?
> * "Reconstruction" of the RF pulse structure using particle energy
> change in the cooling channel to figure out what really happened.
>
> Are these sensible things to do? Most accelerator experiments don't
> model in the sort of detail we intend to, so I realise that this might
> be a bit more than accelerator guys are used to.
>
> There's a philosophical question - do we want to digitise slow
> controls?
> But also I don't know how the RF monitoring works, what will be
> measured.
>
> Comments?
>
> Regards,
> Chris
>
> --
> ASTeC Intense Beams Group
>
> tel: +44 (0)1235 44 6983
> fax: +44 (0)1235 44 5607
>
> Building R2,
> Rutherford Appleton Laboratory,
> Harwell Science and Innovation Campus,
> Didcot.
> OX11 0QX