hi aki,
by the sounds of it, it is just for performance. the blast field is
implemented as a look-up table, which is a lot faster than an analytical
code. so the holding field is only calculated where it is needed.
if performance is an issue, we may consider just adding the value of
the holding field into the points of bgrid2.blast. there is a script in
'exp/commis/fieldmap' which generates the fieldmap, so it wouldn't be
very hard to do.
--chris
Akihisa Shinozaki wrote:
> 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