Michael,
I checked in the larger bgrid as its own filename, but kept the new
smaller one as bgrid2.blast, since it really is a fix. You can always
check out previous versions as different names.
--Chris
Michael Kohl wrote:
> Hi Chris,
>
> please give the large map a different name that will be specified in
> .blastrc. Also, Doug's new map should be bgrid3.blast. Different versions
> in CVS with the same filename are only justified if there are bugfixes to
> an existing map.
>
> Regards,
>
> Michael
>
>
>
> On Tue, 4 Oct 2005, Chris Crawford wrote:
>
>
>>Hi Doug,
>> I copied the file to
>>/home/daq/blast/pro2004/Blast_Params/bgrid2.blast, and checked it in
>>(version 1.9). Note that cvs_v3/Blast_Params is not used, and also the
>>'2' in bgrid2.blast, and #2 in the first line refer to the file format,
>>not version of the map. I also fixed the first line.
>> I started 'setenv ANALDIR test-2005-10-04; lrn +SQL 12144' from the
>>blast acct to test the new field.
>> We can either check the larger map as a new version of bgrid2.blast,
>>or with a new name like 'bgrid2.large', making it easier to switch back
>>and forth. Which do you think would be better?
>>--Chris
>>
>>
>>Douglas Kenneth Hasell wrote:
>>
>>>Hi,
>>>
>>> I have put a file "bgrid3.blast" into the Blast_Params sub-
>>>directory of the blast account. I have not done anything else and hope
>>>someone who knows what they are doing can take the appropriate action.
>>>
>>> This file has the same ranges (ie size) as the previous grid files
>>>so no changes are needed to the code other than whatever is necessary
>>>to have the field calculating code point at this file rather than
>>>bgrid2.blast.
>>>
>>> The new file "bgrid3.blast" is based on the field mapping data from
>>>Abby Goodhue "TOT.dat". I used her results but edited to remove any
>>>point which differed by more than 200 G from the Biot-Savard
>>>calculation (this had the effect of removing about 150 bad points). I
>>>then fit the mapped data allowing the coils to move and obtained a
>>>good fit with R = -8.1 mm, Z = 8.09 mm, and some small angle changes.
>>>
>>> I then filled the desired grid with the closest mapped result if
>>>one existed and with the offset coil calculated result if no mapped
>>>data was close. If the calculated point is greater than 4000 G (which
>>>can happen close to the coils) I fix its magnitude to 4000 G to reduce
>>>the non-linearities near the coil. Then, since the mapped values are
>>>not exactly on the grid points I loop over the grid points and
>>>determined the field at the grid point by fitting a second order
>>>polynomial in x, y, and z to the 27 points surrounding the desired grid
>>>point. I do this so long as at least one point of the 27 was a
>>>measured value. If all 27 are calculated there is no need to do the fit.
>>>
>>> I am now calculating a new grid following the same procedure as
>>>above but changing the ranges so that the grid extends to the TOF's in
>>>x, y, and z and also extends back to Z = -1.2 m to include the BAT's
>>>
>>> The old range was
>>>
>>> -200 <= x <= 200
>>> -70 <= y <= 70
>>> -10 <= z <= 290
>>>
>>> The new range I am calculating now is:
>>>
>>> -250 <= x <= 250, 101 grid steps
>>> -90 <= y <= 90, 37 grid steps
>>> -120 <= z <= 380, 101 grid steps
>>>
>>> For comparison the y component of the field at
>>>
>>> x = 200, y = 0, z = 0 is -454 G
>>> x = 250, y = 0, z = 0 is -95 G (near face of back angle TOF)
>>>
>>> x = 130, y = 0, z = 290 is -269 G
>>> x = 130, y = 0, z = 380 is 10 G (near face of forward angle TOF)
>>>
>>> This new grid will be approximately 2.6 times larger. If anyone
>>>thinks this too large please let me know.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Douglas
>>>
>>>26-415 M.I.T.
>>>Tel: +1 (617) 258-7199
>>>77 Massachusetts Avenue Fax: +1 (617)
>>>258-5440
>>>Cambridge, MA 02139, USA E-mail:
>>>hasell@mit.edu
>>
>>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST