[Clas_offline] b-field parameterization/calculation

[Mac Mestayer]

Hello Alex;

You might be right.  I may not improve time.  I was thinking
that to achieve the same accuracy we could use a coarser grid, with
fewer grip points spaced further apart, and still achieve the same
accuracy.  I was thinking that a smaller table would be faster
to look up, but I was thinking of the case of a non-indexed table,
like the link table, where you have to sort through the table.
A b-field table would probably be indexed by position and have
every table element filled, so it would take the same time to
find a value in a large indexed table as in a small one.

There may still be a savings in computer time if we can use
a linear interpolation method rather than a 2nd-order one.

 				- Mac

"mestayer at jlab.org", (757)-269-7252

On Wed, 11 Nov 2009, Alexander Vlassov wrote:

> Mac Mestayer wrote:
>> Hello folks;
>> 
>> Here is my suggestion for a useful, self-contained software
>> project for Sebouh in the context of his Java-ization of SOCRAT.
>> 
>> I understand that a fair fraction of tracking computing time is
>> devoted to estimating the magnetic field along a trajectory.
>> One way to estimate the field is to fill a table with pre-calculated
>> values of the B field components on a grid of space points, and
>> then to interpolate between grid points to estimate the field value
>> at any arbitrary space point.  The speed of such a process varies
>> with the grid size and with the order of interpolation (linear, 2nd
>> order, etc.).
>> 
>> In the summer, Peter Bosted made a good suggestion.  Since the
>> dominant kinematic trend of the B-field for a toroidal magnet is
>> a 1/r dependence, he suggested that we tabulate r*B instead of
>> B itself.
>> 
>> If folks agree, I'd like to see Sebouh investigate this.
>> The project would have several stages.  First, simply isolate
>> and modularize the existing B-field estimation part of SOCRAT into
>> an independent module.  Secondly, measure how much time the
>> B-field estimation is taking for a wide variety of typical tracks.
>> Thirdly, create a new table with r*B as the tabulated values instead
>> of B, and time this (it shouldn't be any faster if we don't change
>> anything else).  Now we can play around with reducing the number of
>> grid points by making a coarser binning and see how this affects
>> the computing time.  Likewise, we can investigate using a lower-order
>> interpolation scheme.  As well as measuring computing time, we need
>> a measure of the loss of resolution due to coarsening the grid, so
>> we'll also have to keep track of the momentum and angular resolution
>> of the reconstructed tracks.
>> 
>> Any comments on the importance of such a project or on its implementation?
>>
>>  				- Mac
>> 
>> "mestayer at jlab.org", (757)-269-7252
>> 
>> 
>> _______________________________________________
>> Clas_offline mailing list
>> Clas_offline at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/clas_offline
>> 
> Hi,
> I can understand, that making of a table B*r instead of B may improve 
> accuracy,
> but how can it affect the alculating time ?
> - Alex.
>
>