[neutron-mc] Neutron parameters and EXTEND
Emmanuel FARHI
farhi at ill.fr
Sat Mar 29 10:33:46 CET 2008
Hi again Aaron,
The storage and reading are indeed sequential. However, I can't figure out
what you really want to do. I had the impression that you want to store
the interaction xyz, and read them afterwards in a monitor. You can not
use the Virtual_output and input with the same file in an instrument as
the writing of these files is done by blocks (not one by one) to improve
the stream efficiency. The PreMonitor_nD does pass the neutron state from
one position to an other Monitor_nD.
The SPLIT works perfectly with PowderN, and the interaction point is
different each time (but should be on a same line for the 10 repetitions).
I here want to emphasize a similar issue you had with your 'flag'. If you
use your own variables, make sure that the state when reaching the SPLIT
point is forwarded the same for each repeated neutron. This means that the
SPLIT point should better be just before the PowderN, and an EXTEND there
will set flag=0. Then PowderN may change it, but you'll be sure that the
flag value form one repetition is not sent to the next neutron without
being re-initialized to 0.
Emmanuel.
> I'm not sure this is entirely what I need.
>
> The big questions are:
>
> Does the virtual_output component store neutron data sequentially?
> Does the virtual_input component read neutron data from the file
> sequentially?
>
> Here's another question regarding SPLIT, because I'd like to use the
> method
> on a PowderN with SPLIT 10:
>
> Does each of the 10 neutron events in the sample interact with the same
> sample area (i.e. would I get the same xp, yp, zp for the 10 neutrons
> coming
> from the split command), or is the selection of the interaction point
> calculated separately for each?
>
> Would the current method work with the SPLIT keyword?
>
> If each instance interacts with the same xp, yp, zp in the sample, could I
> simply add a counter (perhaps using another IF statement or a FOR loop) to
> then only store xp, yp, zp, IF it was scattered by the sample, IF is hit
> the
> detector and IF is a counter going from 1 to 10 was say 1.
>
> Many thanks again, your help is greatly appreciated.
>
> Aaron
>
> On Fri, Mar 28, 2008 at 4:12 PM, Emmanuel FARHI <farhi at ill.fr> wrote:
>
>> Hi Aaron,
>>
>> I guess what you think of is quite close from what PreMonitor_nD can do.
>> It stores neutron state at some point, and this can be used in any
>> further
>> instance of Monitor_nD. It thus makes a correlation between neutron
>> state
>> at some position, and the detection somewhere else, just as what you did
>> with your EXTENDs. The Monitor_nD may store that state as well as a
>> source
>> with e.g. options="source" or "list all, x y z vx vy vz t sx sy sz",
>> which
>> is indeed a Virtual_output.
>>
>> Emmanuel.
>>
>> > Hello again,
>> >
>> > Excellent. Glad the source of the problem was found.
>> >
>> > I would like to extend this ability one step further. What I would
>> like
>> > to
>> > do is somehow "pass" the x, y, z variables of interaction position
>> with
>> > the
>> > PowderN through a virtual_output component. I can immediately think
>> of
>> > two
>> > ways to do this:
>> >
>> > 1) Write x,y,z as a list in a file (much like the virtual_output
>> output
>> > file). Then when the virtual_input is used, add and EXTEND and make
>> use
>> > of
>> > the read_table-lib to read from the x,y,z data file and once again
>> attach
>> > these variables to each neutron.
>> >
>> > This would only work if the virtual_input picks neutrons from the
>> > virtual_output file sequentially. Moreover, the virtual_out must also
>> > store
>> > the neutron data sequentially (but I think this is the case).
>> >
>> > 2) Append the x,y,z variables to each neutron stored by the
>> virtual_out
>> > (giving each line in the . Then read these as neutron states are read
>> by
>> > the virtual_input.
>> >
>> > I would be inclined to say that option 1 might be the easiest, but it
>> > requires that neutron state are store and the read sequentially.
>> Option
>> 2
>> > would make the output file larger and might not be as easy to employ.
>> >
>> > Any insight?
>> >
>> > Aaron
>> >
>> > On Fri, Mar 28, 2008 at 3:26 AM, Emmanuel FARHI <farhi at ill.fr> wrote:
>> >
>> >> Hi Aaron,
>> >>
>> >> you are right, the intersection test is with the whole cylinder, and
>> so
>> >> does the SCATTERED flag. I may fix that today in the CVS
>> >>
>> >> E.
>> >>
>> >>
>> >> > Hi Emmanuel,
>> >> >
>> >> > I used your suggestions; I hadn't realized that the x, y, z names
>> >> referred
>> >> > to local coordinates, which is exactly what I needed.
>> >> >
>> >> > Still, for some reason I am getting many more printf neutron x,y,z
>> >> > parameters than are recorded in the detector. In a recent run I
>> had
>> >> 785
>> >> > printf parameters and "monitor_N=202" output on similation end.
>> I'm
>> >> not
>> >> > clear as to why this might be happening. It seems as though both
>> >> > conditions
>> >> > in the IF statement in the EXTEND of the detector should only allow
>> >> printf
>> >> > for neutrons that are scattered and intersect the detector. On
>> second
>> >> > thought, this might not be the case. I recall seeing "intersect"
>> as
>> a
>> >> > flag
>> >> > in the component definition for Monitor_nD. However, could it be
>> >> possible
>> >> > that SCATTERED is allowing any rays that intersect the entire
>> >> cylindrical
>> >> > shell of the detector (i.e. as if on theta: limits = [0, 360])? I
>> >> changed
>> >> > the limits to [10, 170] to see if this would change the results.
>> This
>> >> > worked! The number of neutrons intersected in the detector now
>> >> matches
>> >> > the
>> >> > number give by the printf.
>> >> >
>> >> > So it appears that SCATTERED it TRUE when a neutron intersects any
>> >> part
>> >> of
>> >> > the cylinder and not just the part defined by limits on theta.
>> >> >
>> >> > As a side note, the gauge volume that I am seeing looks strange.
>> >> However,
>> >> > it is arranged in such a way that might explain the problems I've
>> been
>> >> > having with divergences from the PowderN component. I won't be
>> >> entirely
>> >> > confident on this until we fix the above problem and see what the
>> >> proper
>> >> > gauge volume is.
>> >> >
>> >> > Here are the source, sample and detector components:
>> >> >
>> >> > COMPONENT source = Virtual_input(
>> >> > file = file, type = "text", verbose = 0, repeat_count = repeat,
>> >> > smooth = 1)
>> >> > AT (0, 0, 0) RELATIVE origin
>> >> > EXTEND
>> >> > %{
>> >> > flag=0;
>> >> > %}
>> >> >
>> >> > COMPONENT sample = PowderN(
>> >> > reflections = "Ni.laz", format = Lazy, d_phi = 8,
>> >> > radius = 0.006, yheight = 0.06, pack = 1, sigma_abs = 0,
>> >> > sigma_inc = 0, Delta_d = 0, frac = 0, tfrac = 0, DW = 0,
>> >> > concentric = 0, barns = 1)
>> >> > AT (0, 0, 0) RELATIVE sample_arm
>> >> > EXTEND
>> >> > %{
>> >> > flag=0;
>> >> > if(SCATTERED)
>> >> > {
>> >> > xp = x;
>> >> > yp = y;
>> >> > zp = z;
>> >> > flag = 1;
>> >> > }
>> >> > %}
>> >> >
>> >> > COMPONENT monitor = Monitor_nD(
>> >> > yheight = 0.133, xwidth = 2.794,
>> >> > options = "banana, theta limits=[10, 170], bins = 32")
>> >> > AT (0, 0, 0) RELATIVE sample_arm
>> >> > ROTATED (0, 0, 0) RELATIVE origin
>> >> > EXTEND
>> >> > %{
>> >> > if(flag==1 && SCATTERED)
>> >> > {
>> >> > printf("%g,%g,%g\n", xp,yp,zp);
>> >> > }
>> >> > %}
>> >> >
>> >> >
>> >> > On Thu, Mar 27, 2008 at 5:00 PM, Emmanuel FARHI <farhi at ill.fr>
>> wrote:
>> >> >
>> >> >> Hi Aaron,
>> >> >>
>> >> >> I can see a few comments to improve and understand the possible
>> >> problems
>> >> >> you face.
>> >> >>
>> >> >> 1- to extract the neutron stte parameters, you can not indeed
>> refer
>> >> >> explicitely to the 'x','y' and 'z' names as these are only defined
>> in
>> >> >> the
>> >> >> TRACE of each component. However, they should also be defined in
>> the
>> >> >> EXTEND, and they are already in the local component coordinate
>> frame.
>> >> >>
>> >> >> 2- if you want to extract coordinates from e.g. POS_A_CURRENT_COMP
>> >> >> (which
>> >> >> is a Coord structure), use the coords_get function (see Appendix
>> at
>> >> the
>> >> >> end of the User Manual). the 'A' in the name indicates this is
>> in
>> >> the
>> >> >> absolute coordinate frame. Better use the 'R' label,
>> >> POS_R_CURRENT_COMP.
>> >> >> The 'x' 'y' 'z' fields of the structure can not be accessed as the
>> >> names
>> >> >> xyz are redefined to point to the real name of the neutron
>> coordinate
>> >> >> which is e.g. 'mcnlx'.
>> >> >>
>> >> >> 3- I would rather write your code as follow.
>> >> >> At the source level (or virtual output), make an EXTEND that sets
>> the
>> >> >> flag
>> >> >> to 0. Suppose you have first a neutron that interacts with the
>> >> PowderN.
>> >> >> It
>> >> >> sets the flag. But now, let's say a second neutron misses the
>> sample.
>> >> >> The
>> >> >> extend block is NOT evaluated as the component is skipped (e.g. no
>> >> >> intersection with volume), and the flag value is the one from the
>> >> >> previous
>> >> >> neutron. You use a wrong flag value if that neutron reaches the
>> >> >> detector!
>> >> >>
>> >> >> Source=blah( ... )
>> >> >> EXTEND %{
>> >> >> flag=0;
>> >> >> %}
>> >> >>
>> >> >> Then you can have you sample extension, and use directly the xyz
>> >> values.
>> >> >> COMPONENT sample = PowderN( ... ) AT (0, 0, 0) RELATIVE sample_arm
>> >> >> EXTEND
>> >> >> %{
>> >> >> flag=0; // make sure we always define it when reaching sample
>> >> >> if(SCATTERED) {
>> >> >> xp = x; // local coords
>> >> >> yp = y;
>> >> >> zp = z;
>> >> >> flag = 1;
>> >> >> }
>> >> >> %}
>> >> >>
>> >> >> Try these modifications, and tell me. Using global variables in
>> >> EXTEND
>> >> >> may
>> >> >> get tricky as you are not sure to pass there. So, better make sure
>> >> you
>> >> >> control all variables, and this should be done at least at some
>> >> position
>> >> >> were all neutrons pass. There is a similar difficulty with the
>> SPLIT
>> >> >> keyword.
>> >> >>
>> >> >> Emmanuel.
>> >> >>
>> >> >>
>> >> >> > Hi all,
>> >> >> >
>> >> >> > I've been working on a way to essentially visualize the gauge
>> >> volume
>> >> >> in
>> >> >> a
>> >> >> > sample. I'll give a brief summary of my instrument and then the
>> >> >> problems
>> >> >> > that I've found:
>> >> >> >
>> >> >> > It's a simple 2-axis instrument, with such components as: a
>> >> >> > Source_Maxwell_3, a Monochromator_flat, a PowderN and a
>> Monitor_nD.
>> >> >> I've
>> >> >> > used a virtual_input/virtual_output to save neutron histories at
>> >> the
>> >> >> > sample
>> >> >> > incident slit. I can then continue these histories through
>> >> >> diffraction
>> >> >> > from
>> >> >> > the sample and to the detector.
>> >> >> >
>> >> >> > In order to visualize the gauge volume, I thought I could do the
>> >> >> > following:
>> >> >> >
>> >> >> > 1) Use EXTEND and if(SCATTERED) in the sample component to save
>> the
>> >> x,
>> >> >> y,
>> >> >> > z
>> >> >> > position of the scattering event in the sample and also create a
>> >> flag
>> >> >> if
>> >> >> > the
>> >> >> > neutron was scattered at the sample (example flag = 1 if
>> SCATTERED,
>> >> >> ELSE
>> >> >> > flag = 0)
>> >> >> >
>> >> >> > 2) Use EXTEND and if(flag==1 && SCATTERED) at the detector.
>> Then
>> >> >> printf
>> >> >> > the
>> >> >> > saved x, y, z positions of the scattering events in the sample
>> from
>> >> >> above.
>> >> >> > (here I am using printf for debugging, eventually I would like
>> to
>> >> use
>> >> >> the
>> >> >> > DETECTOR OUT 3D(...) macro).
>> >> >> >
>> >> >> > The problems that I'm having:
>> >> >> >
>> >> >> > 1) I cannot seem to find a variable(s) that define the location
>> of
>> >> the
>> >> >> > scattering event in the PowderN component. I have been using
>> >> simple
>> >> >> the
>> >> >> > global variables 'x' 'y' 'z', but I don't think this is working
>> >> >> correctly.
>> >> >> >
>> >> >> > 2) The printf is outputting many more neutron x,y,z than
>> actually
>> >> hit
>> >> >> the
>> >> >> > detector. My speculation is that the SCATTERED macro does not
>> work
>> >> in
>> >> >> > detectors?
>> >> >> >
>> >> >> > 3) A smaller problem. What I would like is the local x-y-z of
>> the
>> >> >> > scattered
>> >> >> > neutron in the sample. To do this, I've tried using the
>> >> >> > POS_A_CURRENT_COMP,
>> >> >> > but I can't seem to isolate the x,y,z components of this vector.
>> >> I've
>> >> >> > tried
>> >> >> > using POS_A_CURRENT_COMP.x to get the x-component, but this does
>> >> not
>> >> >> seem
>> >> >> > to
>> >> >> > work as I get the following error:
>> >> >> >
>> >> >> > In function `mcraytrace':
>> >> >> > 87: error: structure has no member named `mcnlx'
>> >> >> >
>> >> >> > Here is a sample of the EXTEND sections. ** indicates a comment
>> >> that
>> >> >> I've
>> >> >> > added for clarity:
>> >> >> >
>> >> >> > COMPONENT sample = PowderN(
>> >> >> > reflections = "Ni.laz", format = Lazy, d_phi = 8,
>> >> >> > radius = 0.006, yheight = 0.06, pack = 1, sigma_abs = 0,
>> >> >> > sigma_inc = 0, Delta_d = 0, frac = 0, tfrac = 0, DW = 0,
>> >> >> > concentric = 0, barns = 1)
>> >> >> > AT (0, 0, 0) RELATIVE sample_arm
>> >> >> > EXTEND
>> >> >> > %{
>> >> >> > if(SCATTERED)
>> >> >> > {
>> >> >> > **here I'm trying to get the location of the scattering event
>> >> (using
>> >> >> the
>> >> >> > state parameters x, y, z) and then put that into the local
>> >> coordinates
>> >> >> of
>> >> >> > the sample using the POS_A_CURRENT_COMP ***
>> >> >> > xp = x - POS_A_CURRENT_COMP.x;
>> >> >> > yp = y - POS_A_CURRENT_COMP.y;
>> >> >> > zp = z - POS_A_CURRENT_COMP.z;
>> >> >> >
>> >> >> > **the flag is later used in the detector to indicate that the
>> >> neutron
>> >> >> was
>> >> >> > scattered from the sample**
>> >> >> > flag = 1;
>> >> >> > }
>> >> >> > else
>> >> >> > {
>> >> >> > flag = 0;
>> >> >> > }
>> >> >> > %}
>> >> >> >
>> >> >> > COMPONENT monitor = Monitor_nD(
>> >> >> > yheight = 0.133, xwidth = 2.794,
>> >> >> > options = "banana, theta limits=[88.75, 91.25], bins = 32")
>> >> >> > AT (0, 0, 0) RELATIVE sample_arm
>> >> >> > ROTATED (0, 0, 0) RELATIVE origin
>> >> >> > EXTEND
>> >> >> > %{
>> >> >> >
>> >> >> > **Here the xp, yp, zp from above should only be printed if the
>> >> neutron
>> >> >> was
>> >> >> > scattered from the sample and intersected the detector
>> >> >> > if(flag==1 && SCATTERED)
>> >> >> > {
>> >> >> > printf("%g,%g,%g\n", xp,yp,zp);
>> >> >> > }
>> >> >> > %}
>> >> >> > --
>> >> >> > *************************************************
>> >> >> > Aaron M. Percival
>> >> >> > M.Sc. Candidate
>> >> >> > Dept. of Physics, Engineering Physics & Astronomy
>> >> >> > Queen's University
>> >> >> > Kingston, Ontario, Canada, K7L 3N6
>> >> >> > Office: 613-533-6000 ext. 74789
>> >> >> > Fax: 613-533-6463
>> >> >> > *************************************************
>> >> >> > _______________________________________________
>> >> >> > neutron-mc mailing list
>> >> >> > neutron-mc at risoe.dk
>> >> >> > http://mailman.risoe.dk/mailman/listinfo/neutron-mc
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> FARHI Emmanuel <farhi at ill.fr>
>> >> >> Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35
>> >> >> ILL, Grenoble
>> >> >>
>> >> >> _______________________________________________
>> >> >> neutron-mc mailing list
>> >> >> neutron-mc at risoe.dk
>> >> >> http://mailman.risoe.dk/mailman/listinfo/neutron-mc
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > *************************************************
>> >> > Aaron M. Percival
>> >> > M.Sc. Candidate
>> >> > Dept. of Physics, Engineering Physics & Astronomy
>> >> > Queen's University
>> >> > Kingston, Ontario, Canada, K7L 3N6
>> >> > Office: 613-533-6000 ext. 74789
>> >> > Fax: 613-533-6463
>> >> > *************************************************
>> >> > _______________________________________________
>> >> > neutron-mc mailing list
>> >> > neutron-mc at risoe.dk
>> >> > http://mailman.risoe.dk/mailman/listinfo/neutron-mc
>> >> >
>> >>
>> >>
>> >> --
>> >> FARHI Emmanuel <farhi at ill.fr>
>> >> Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35
>> >> ILL, Grenoble
>> >>
>> >> _______________________________________________
>> >> neutron-mc mailing list
>> >> neutron-mc at risoe.dk
>> >> http://mailman.risoe.dk/mailman/listinfo/neutron-mc
>> >>
>> >
>> >
>> >
>> > --
>> > *************************************************
>> > Aaron M. Percival
>> > M.Sc. Candidate
>> > Dept. of Physics, Engineering Physics & Astronomy
>> > Queen's University
>> > Kingston, Ontario, Canada, K7L 3N6
>> > Office: 613-533-6000 ext. 74789
>> > Fax: 613-533-6463
>> > *************************************************
>> > _______________________________________________
>> > neutron-mc mailing list
>> > neutron-mc at risoe.dk
>> > http://mailman.risoe.dk/mailman/listinfo/neutron-mc
>> >
>>
>>
>> --
>> FARHI Emmanuel <farhi at ill.fr>
>> Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35
>> ILL, Grenoble
>>
>> _______________________________________________
>> neutron-mc mailing list
>> neutron-mc at risoe.dk
>> http://mailman.risoe.dk/mailman/listinfo/neutron-mc
>>
>
>
>
> --
> *************************************************
> Aaron M. Percival
> M.Sc. Candidate
> Dept. of Physics, Engineering Physics & Astronomy
> Queen's University
> Kingston, Ontario, Canada, K7L 3N6
> Office: 613-533-6000 ext. 74789
> Fax: 613-533-6463
> *************************************************
>
--
FARHI Emmanuel <farhi at ill.fr>
Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35
ILL, Grenoble
More information about the mcstas-users
mailing list