Hi Michael,
The problem is that when people update from CVS, it would then
download each copy of the field. There have been many different
versions of the field: the TOSCA map, Abby's fieldmap, my corrected
version of hers, Doug's, etc., and each one represents a large fraction
of the entire CVS. Bates is connected to the outside world by only a
T1, which would make checkouts painfully slow. Also, the old fieldmap
is not pure B-S, but a little of each.
Here is a simle command to check out a previous version as a new
name, which I ran in the directory blast:$BLAST_PARAM:
cvs up -p -r1.7 bgrid2.blast > bgrid2.bs
The '-p' pipes the output instead of updating the file.
Karen, the closest we have to a real biot-savart is -r1.1, which was
the Tosca map used for a long time. However, we could generate one from
Doug's code imported into libBlast.so if needed.
--Chris
Michael Kohl wrote:
> Chris,
>
> the old bgrid2.blast was based on Biot-Savart calculations, while the new
> one is based on the measured field map. This is not just a bugfix. It
> would be good to have both maps with different filenames checked in.
> Especially if one wants to directly compare results from the two maps, it
> is better to have them both in BLAST_PARAM directory rather than having to
> modify the checked-out cvs directory. So please, either give the new map
> another name or rename the old map to bgrid2_bs.blast (Biot-Savart) or so!
>
> Regards,
>
> Michael
>
>
>
> On Wed, 5 Oct 2005, Chris Crawford wrote:
>
>
>>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