[neutron-mc] Neutron parameters and EXTEND
Aaron M. Percival
percival at physics.queensu.ca
Sat Mar 29 03:44:36 CET 2008
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
*************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20080328/13e900a2/attachment.html>
More information about the mcstas-users
mailing list