Re: New BLAST magnetic field grid.

From: Chris Crawford (chris2@lns.mit.edu)
Date: Fri Oct 07 2005 - 12:54:51 EDT


that's right. the original bgrid.blast (defined in only half of the
left sector, relying on symmetry) has been 'cvs rm'. ,You can find it in
the Attic or check it out '-r 1.1'. However, it is essentially the same
map as bgrid2.blast -r 1.1, just 4 times smaller.
--Chris

Chi Zhang wrote:
> Hi, I can answer the second question. there are two field maps,
> bgrid.blast and bgrid2.blast. bgrid2.blast is NOT a second version of
> bgrid.blast!! They have different format and are handled in the code
> differently. Among the first few lines of each file, there is an field
> indicating the format, for example the first line of bgrid2.blast is "#2".
> The codes use if/else blocks to select proper subroutines to read the
> files. So bgrid.blast is NOT the "original" bgrid2.blast. Today, one can
> still use bgrid.blast is we can still figure out the format.
>
> I believe the codes, at least BlastLib2 can be used as is, since as Chris
> pointed out, the size of the grid is dynamic. the first 3 lines of
> bgrid2.blast indicates the minimal X,Y,Z, the step size and the number of
> grid points in each direction. BlastLib2 creates the grid accordingly.
>
> I do not know how blastmc would cope with an expanded grid. Is it still
> possible to get Aaron to weigh in? :)
>
> I like bgrid2.large or bgrid2.mapped and found bgrid3.** conceptually
> wrong. but I found this arguement too "academic".
>
> I understand Chris already checked in Doug's map as a new version of
> bgrid2.blast. I suggest accept the current state of the repository.
>
> one can simply do the following: copy current bgrid2.blast to say,
> bgrid2.biosavart (bgrid2.abby or whatever), and then update. this way,
> you have a copy of current bgrid2.blast and the new one two. to select
> the file to be used, simple change the entry in $BLAST_PARAMS/blastrc.
>
> Chi
>
> On Wed, 5 Oct 2005, Michael Kohl wrote:
>
>
>>Hi Chris,
>>
>>ok, if you think that additional 2.4MB is too much for a T1 connection,
>>you win. It is only that people who are not so familiar with cvs features
>>but who prefer to only type "cvs co . " will find it harder to get to the
>>desired map. Anyways, those experts who do use both maps are probably also
>>familiar enough with cvs commands.
>>
>>BTW, was there originally also a "bgrid.bast" ? Or what does the "2" stand
>>for?
>>
>>Regards,
>>
>> Michael
>>
>>
>>
>>
>>
>>On Wed, 5 Oct 2005, Chris Crawford wrote:
>>
>>
>>>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
>>>>>>>
>>>>>>>
>>>
>>--
>>
>>+-------------------------------------+--------------------------+
>>| Office: | Home: |
>>|-------------------------------------|--------------------------|
>>| Dr. Michael Kohl | Michael Kohl |
>>| Laboratory for Nuclear Science | 5 Ibbetson Street |
>>| MIT-Bates Linear Accelerator Center | Somerville, MA 02143 |
>>| Middleton, MA 01949 | U.S.A. |
>>| U.S.A. | |
>>| - - - - - - - - - - - - | - - - - - - - - -|
>>| Email: kohlm@mit.edu | K.Michael.Kohl@gmx.de |
>>| Work: +1-617-253-9207 | Home: +1-617-629-3147 |
>>| Fax: +1-617-253-9599 | Mobile: +1-978-580-4190 |
>>| http://blast.lns.mit.edu | |
>>+-------------------------------------+--------------------------+
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>



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