<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hi All,<br>
<br>
If the field were parameterized instead of tabulating it one could
see performance enhancements in 2 areas:<br>
<br>
1.) Startup time. A 3-D field map can easily be >200MB which does
take some noticeable time to read in at startup<br>
<br>
2.) Gradient calculation. Assuming the basis set for the
parameterization is chosen so that one can easily take it's derivative.<br>
<br>
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.<br>
<br>
In principle, parameterizing r*B may result in fewer terms being needed
for the parameterization, but that would have to be looked at.<br>
<br>
-David<br>
<br>
Mac Mestayer wrote:
<blockquote
cite="mid:Pine.LNX.4.64.0911111351030.2935@clasmacm.jlab.org"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:mestayer@jlab.org">"mestayer@jlab.org"</a>, (757)-269-7252
On Wed, 11 Nov 2009, Alexander Vlassov wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Mac Mestayer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:mestayer@jlab.org">"mestayer@jlab.org"</a>, (757)-269-7252
_______________________________________________
Clas_offline mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Clas_offline@jlab.org">Clas_offline@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/clas_offline">https://mailman.jlab.org/mailman/listinfo/clas_offline</a>
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Clas_offline mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Clas_offline@jlab.org">Clas_offline@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/clas_offline">https://mailman.jlab.org/mailman/listinfo/clas_offline</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist Office: (757)269-5567 [[[ [ [ [
Jefferson Lab Pager: (757)584-5567 [ [ [ [ [ [
<a class="moz-txt-link-freetext" href="http://www.jlab.org/~davidl">http://www.jlab.org/~davidl</a> <a class="moz-txt-link-abbreviated" href="mailto:davidl@jlab.org">davidl@jlab.org</a> [[[ [[ [[ [[[
------------------------------------------------------------------------
</pre>
</body>
</html>