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