[Clas_offline] [Fwd: Re: b-field parameterization/calculation]
Maurik Holtrop
maurik.holtrop at unh.edu
Thu Nov 12 12:52:24 EST 2009
Dear Mac and offline,
I'll throw in my opinion as well:
I wonder about the statement that "tracking spends a lot of time evaluating the magnetic field". How well is that established?
I think I would first run a profiler over the current version of the code to see exactly what routines are responsible for how much of the execution time.
A quick guestimate on the cost of a table lookup gives me the following for an indexed lookup table and linear or quadratic interpolation: For a linear interpolation I count about 6 floating point operations, for a quadratic about 18. If we count one Flop per clock cycle (just to get the order of magnitude), I could do 3 GFlops per second on one core. Maybe if the table is really big, the memory access times become very slow? Still, the 200 MB would fit in memory and memory access latency would be about 10 clock cycles, the three values you need are "next to each other" in memory, so you pay this only once. Then a lookup costs about 10 (latency) + 3 * 4 (memory load of 3 floats) + 18 = 40 clock cycles. In this case I could do about 75 Million lookups per second.
It seems to me this would be very difficult to do any faster, since a parametrization with a few terms in it will quickly cost you 40 cycles as well. If the magnetic field evaluations really are a big component of the computational cost, perhaps there are ways to call the routine less frequently?
As David points out, there is the load time of the table, but I didn't get the impression that this was the problem you were trying to solve.
Best,
Maurik
On Nov 12, 2009, at 11:47 AM, Sebastian Kuhn wrote:
> Just my 5 cents: making a grid of r*B(r,theta,phi) is probably the most efficient method. However, while this will give a "smoother" function in most places, close to the coils we will have a very complicated field so the full resolution and all higher-order terms will be needed there (a parametrization will not work).
>
> - Sebastian
>
> Alexander Vlassov wrote:
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: [Clas_offline] b-field parameterization/calculation
>> From:
>> Alexander Vlassov <vlassov at jlab.org>
>> Date:
>> Wed, 11 Nov 2009 15:50:06 -0500
>> To:
>> David Lawrence <davidl at jlab.org>
>>
>> To:
>> David Lawrence <davidl at jlab.org>
>>
>>
>> Hi,
>>
>> I do not think that the magnetic field can be parametrized at all (if we
>> want
>> reasonable accuracy). I can not imagine how many parameters will it needs.
>>
>> One of ideas (Kossov, actually) was to use B(r, theta, phy) instead of
>> B(x,y,z).
>> The argument was that field difference d B/d phy is about the same at
>> small and large r. That is if you use different cell sizes (in x,y,z)
>> for small and large
>> distances.
>>
>> - Alex.
>>
>>
>> David Lawrence wrote:
>>>
>>> Hi All,
>>>
>>> If the field were parameterized instead of tabulating it one could
>>> see performance enhancements in 2 areas:
>>>
>>> 1.) Startup time. A 3-D field map can easily be >200MB which does take
>>> some noticeable time to read in at startup
>>>
>>> 2.) Gradient calculation. Assuming the basis set for the
>>> parameterization is chosen so that one can easily take it's derivative.
>>>
>>> One could of course use a pre-calculated gradient table as well, but
>>> that would have the same size as the field map itself, simply moving
>>> the overhead incurred at every startup to different place, but not
>>> eliminating it.
>>>
>>> In principle, parameterizing r*B may result in fewer terms being
>>> needed for the parameterization, but that would have to be looked at.
>>>
>>> -David
>>>
>>> Mac Mestayer wrote:
>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Clas_offline mailing list
>>>> Clas_offline at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/clas_offline
>>>>
>>>
>>> --
>>>
>>> ------------------------------------------------------------------------
>>> David Lawrence Ph.D.
>>> Staff Scientist Office: (757)269-5567 [[[ [ [
>>> [ Jefferson Lab Pager: (757)584-5567 [ [
>>> [ [ [ [ http://www.jlab.org/~davidl davidl at jlab.org
>>> [[[ [[ [[ [[[
>>> ------------------------------------------------------------------------
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Clas_offline mailing list
>> Clas_offline at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/clas_offline
> _______________________________________________
> Clas_offline mailing list
> Clas_offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/clas_offline
More information about the Clas_offline
mailing list