Re: [BLAST_ANAWARE] holding field classes into BlastLib2

From: Akihisa Shinozaki (shino@lns.mit.edu)
Date: Fri Jan 21 2005 - 18:22:51 EST


Hello Chi,

Thank you very much for your announcement. But I feel ashamed if I made
a pressure to somebody to make some compliments because of my narrow
minded message. (In fact, it is Karen who contacted to me just after
the first distribution and I realized I should use her data.) However, I
do congratulate you for your quick implementations and results.

Maybe somebody else would tell us why Chi needs "fabs(x)>50" line,
because I was surprised to see that he needs it. I mean, if the line is
necessary for x, then it should also needs the similar line for z,
because the computations are perfectly symmetric under the exchange
between x and z. (longitudinal and transverse, in other words).

Thank you,
Aki

Chi Zhang wrote:

>Hi, holding field codes written by Aki are checked into BlastLib2.
>
>please see BlastLib2/HoldField_BiotSavart.{h,cc} and
> HoldCoil_BiotSavart.{h,cc}
>
>An interface class TBLHoldField is added to the library,
>HoldField_BiotSavart is made to inherit from it. should anyone come up
>other models of holding field, one should conform to the interface defined
>in TBLHoldField.
>
>TBLMagField is changed so that it adds holding field to computed
>BlastField. and the way we handle the field in recon, this is pretty much
>the only place to put the holding field.
>
>Blast_Param/blastrc is changed to add a switch MagField.HoldField to
>control the on and off of the holding field functions. an file iron.bh is
>added to Blast_Param too which is required for HoldCoil_BiotSavart.
>
>There seems to be an slight overhead due to the addition of holdfield. I
>added a switch in HoldField_BiotSavart::GetB() such that when X is larger
>than 50 cm, it returns 0 field anyway. We should probably reevaluate this
>bound later.
>
>Ran on the first couple of event in run 12013. here are a comparison:
>
>event:
> p theta phi z
>2 0.333 54.333 190.711 -19.747 with holding field
> 0.333 54.268 190.975 -19.772 without holding field
>5 0.292 58.708 3.228 1.527
> 0.292 58.686 2.880 1.511
>14 0.352 56.209 176.377 -5.424
> 0.351 56.199 175.970 -5.440
>
>slight differences are seen, as Aki predicted, the change is phi is the
>largest and close to 1-sigma of our resolution.
>
>For details about the holding field algorithms, please consult Aki, their
>creator.
>
>I want to thank Aki for the marvelous codes which are very easy to work
>with and took only a half day incorporate into the existing library.
>
>Chi
>
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST