Dear George,
as Stefan has told you, EDep2D.dat is a file created as an input to gnuplot,
and it is not intended to be examined by a user.
If you want to look at the binning results as an ASCII file, use the
program $FLUPRO/flutil/usbrea, which converts binary results (with .bnn
extension if produced by Flair) to ASCII. You will get the results as two
tables: the second one contains the errors.
Alberto
> From: Stefan Roesler <Stefan.Roesler_at_cern.ch>
> Date: Mon, 17 Mar 2014 18:16:41 +0000
> Hi George
> Probably for gnuplot plotting reasons (most likely it needs lower and upper
> bin limit for *each* bin, i.e. also the last one) in both plot coordinates
> there is a repetition in the end, i.e. also in the horizontal coordinate which
> is the last 4 lines in your example (that's why you observe 12 lines). It may
> become clearer when you run with more statistics and see non-zero scoring
> values as you will see that the lines (that are repeated with the upper bin
> limit) carry the same scoring values as the previous ones.
> The first column is the horizontal coordinate of the plot, the second is the
> vertical and the last column is the error on the mean of the projection in
> percent.
> Cheers
> Stefan
On Mon, 17 Mar 2014, Georgios Dedes wrote:
> Hi all,
>
> I used USRBIN ENERGY to calculate energy deposit in a target of
> 2x2x2cm3. The USRBIN was spanning exactly over the same volume as my
> target and with 3 bins in x, 2 in y and 2 in z. The 2D xy plot
> (attached), as well as the numbers I get from the ASCII file of the
> USRBIN are all consistent and correct. I would like to have the values
> of the 2D plot in a form of x y energy table and I realized that the
> .dat file created when plotting (with the same name as the plot), short
> of contains that info but it gives me:
>
> -1.0000000000000000 -1.0000000000000000 3.95135302E-03
> 99.000000
> -1.0000000000000000 -0.33333333333333337 3.54278437E-03
> 99.000000
> -1.0000000000000000 0.33333333333333326 0.0000000
> 0.0000000
> -1.0000000000000000 0.99999999999999989 0.0000000
> 0.0000000
>
> 0.0000000000000000 -1.0000000000000000 0.0000000
> 0.0000000
> 0.0000000000000000 -0.33333333333333337 0.0000000
> 0.0000000
> 0.0000000000000000 0.33333333333333326 0.0000000
> 0.0000000
> 0.0000000000000000 0.99999999999999989 0.0000000
> 0.0000000
>
> 1.0000000000000000 -1.0000000000000000 0.0000000
> 0.0000000
> 1.0000000000000000 -0.33333333333333337 0.0000000
> 0.0000000
> 1.0000000000000000 0.33333333333333326 0.0000000
> 0.0000000
> 1.0000000000000000 0.99999999999999989 0.0000000
> 0.0000000
>
> which is not 6 "pixels" (I expect 6 as I have 2x3 bins in x,y) but 12.
> It seems that the first column is y and the second is x, am I right? It
> also seems that the combination of the first two columns (y,x) indicates
> the lower left corner of a "pixel", but it always adds one more in each
> dimension. For example the first line of the dat file (-1.00,-1.00) is
> the lower left edge of the black voxel, the second line is the lower
> left edge of the red pixel. What I would guess as the last "pixel" in
> the x dimension has a lower left corner (-1.00,0.33), but it adds
> another one (-1.00,0.99). Can anybody comment on that? Is there any
> other source of this info in ASCII form?
>
> Last question, what is exactly the meaning of the 4th column which is
> either 0 or 99 for the filled "pixels"?
>
> Thanks in advance,
> George
>
>
--
Alberto Fasso`
SLAC-RP, MS 48, 2575 Sand Hill Road, Menlo Park CA 94025
Phone: (1 650) 926 4762 Fax: (1 650) 926 3569
fasso_at_slac.stanford.edu
Received on Tue Mar 18 2014 - 16:12:04 CET