From wokaoyan1981 at 126.com Thu Jan 10 13:45:23 2008 From: wokaoyan1981 at 126.com (wokaoyan1981) Date: Thu, 10 Jan 2008 20:45:23 +0800 (CST) Subject: [neutron-mc] How to set parameters "dist" and "xw/yh"? Message-ID: <3075224.1484331199969123169.JavaMail.coremail@bj126app41.126.com> Dear colleagues, Why is it necessary to set parameters "dist" ,"xw" and "yh" of the component Source_Maxwell_3? How to set them with regard to a source followed by a straight neutron guide? Please shed light on them thoroughly.Thank you! Tom Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From linda.udby at risoe.dk Thu Jan 10 14:26:37 2008 From: linda.udby at risoe.dk (Linda Udby) Date: Thu, 10 Jan 2008 14:26:37 +0100 (CET) Subject: [neutron-mc] How to set parameters "dist" and "xw/yh"? In-Reply-To: <3075224.1484331199969123169.JavaMail.coremail@bj126app41.126.com> References: <3075224.1484331199969123169.JavaMail.coremail@bj126app41.126.com> Message-ID: Dear Tom Chen, Usually you would want only to be concerned with the neutrons from the source that actually goes in the guide. Hence you would focus on the guide entrance. The 'xw' and 'yh' sets the size of the focusing rectangle (here it would be guide width/height), 'dist' is the down-stream distance from the source to the focusing rectangle (here distance from source to guide entrance). Hope this helps, otherwise you can always check the components manual at http://www.mcstas.org/download/components/ regards Linda Udby, AFM, Ris? On Thu, 10 Jan 2008, wokaoyan1981 wrote: > Dear colleagues, > > Why is it necessary to set parameters "dist" ,"xw" and "yh" of the component Source_Maxwell_3? > > How to set them with regard to a source followed by a straight neutron guide? > > Please shed light on them thoroughly.Thank you! > > Tom Chen > > -- M.Sc. Linda Udby Materials Science Department Ris? National Laboratory, DTU DK-4000 tel: +45 46 77 58 65 From wokaoyan1981 at 126.com Sun Jan 13 13:00:19 2008 From: wokaoyan1981 at 126.com (wokaoyan1981 at 126.com) Date: Sun, 13 Jan 2008 20:00:19 +0800 (CST) Subject: [neutron-mc] Thank you Linda! In-Reply-To: References: <3075224.1484331199969123169.JavaMail.coremail@bj126app41.126.com> Message-ID: <31200922.332231200225619100.JavaMail.coremail@bj126app101.126.com> Dear Linda, Thank you very much for your help! regards Tom Chen, CAEP -------------- next part -------------- An HTML attachment was scrubbed... URL: From percival at physics.queensu.ca Thu Mar 27 20:52:46 2008 From: percival at physics.queensu.ca (Aaron M. Percival) Date: Thu, 27 Mar 2008 15:52:46 -0400 Subject: [neutron-mc] Neutron parameters and EXTEND Message-ID: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> 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 ************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From farhi at ill.fr Thu Mar 27 22:00:11 2008 From: farhi at ill.fr (Emmanuel FARHI) Date: Thu, 27 Mar 2008 22:00:11 +0100 (CET) Subject: [neutron-mc] Neutron parameters and EXTEND In-Reply-To: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> References: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> Message-ID: <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> 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 Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35 ILL, Grenoble From percival at physics.queensu.ca Thu Mar 27 23:34:38 2008 From: percival at physics.queensu.ca (Aaron M. Percival) Date: Thu, 27 Mar 2008 18:34:38 -0400 Subject: [neutron-mc] Neutron parameters and EXTEND In-Reply-To: <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> References: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> Message-ID: <816e49cc0803271534hbb83461l2ee82faab80ef6c2@mail.gmail.com> 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 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 > 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: From farhi at ill.fr Fri Mar 28 08:26:21 2008 From: farhi at ill.fr (Emmanuel FARHI) Date: Fri, 28 Mar 2008 08:26:21 +0100 (CET) Subject: [neutron-mc] Neutron parameters and EXTEND In-Reply-To: <816e49cc0803271534hbb83461l2ee82faab80ef6c2@mail.gmail.com> References: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> <816e49cc0803271534hbb83461l2ee82faab80ef6c2@mail.gmail.com> Message-ID: <50736.193.49.43.124.1206689181.squirrel@195.83.126.3> 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 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 >> 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 Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35 ILL, Grenoble From percival at physics.queensu.ca Fri Mar 28 18:06:11 2008 From: percival at physics.queensu.ca (Aaron M. Percival) Date: Fri, 28 Mar 2008 13:06:11 -0400 Subject: [neutron-mc] Neutron parameters and EXTEND In-Reply-To: <50736.193.49.43.124.1206689181.squirrel@195.83.126.3> References: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> <816e49cc0803271534hbb83461l2ee82faab80ef6c2@mail.gmail.com> <50736.193.49.43.124.1206689181.squirrel@195.83.126.3> Message-ID: <816e49cc0803281006k592eb433p6cd2ed5394b45018@mail.gmail.com> 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 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 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 > >> 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 > 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: From farhi at ill.fr Fri Mar 28 21:12:43 2008 From: farhi at ill.fr (Emmanuel FARHI) Date: Fri, 28 Mar 2008 21:12:43 +0100 (CET) Subject: [neutron-mc] Neutron parameters and EXTEND In-Reply-To: <816e49cc0803281006k592eb433p6cd2ed5394b45018@mail.gmail.com> References: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> <816e49cc0803271534hbb83461l2ee82faab80ef6c2@mail.gmail.com> <50736.193.49.43.124.1206689181.squirrel@195.83.126.3> <816e49cc0803281006k592eb433p6cd2ed5394b45018@mail.gmail.com> Message-ID: <53482.193.49.43.124.1206735163.squirrel@195.83.126.3> 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 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 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 >> >> 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 >> 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 Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35 ILL, Grenoble From percival at physics.queensu.ca Sat Mar 29 03:44:36 2008 From: percival at physics.queensu.ca (Aaron M. Percival) Date: Fri, 28 Mar 2008 22:44:36 -0400 Subject: [neutron-mc] Neutron parameters and EXTEND In-Reply-To: <53482.193.49.43.124.1206735163.squirrel@195.83.126.3> References: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> <816e49cc0803271534hbb83461l2ee82faab80ef6c2@mail.gmail.com> <50736.193.49.43.124.1206689181.squirrel@195.83.126.3> <816e49cc0803281006k592eb433p6cd2ed5394b45018@mail.gmail.com> <53482.193.49.43.124.1206735163.squirrel@195.83.126.3> Message-ID: <816e49cc0803281944k1fdb81fftaec7782a0df3eac5@mail.gmail.com> 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 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 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 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 > >> >> 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 > >> 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 > 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: From farhi at ill.fr Sat Mar 29 10:33:46 2008 From: farhi at ill.fr (Emmanuel FARHI) Date: Sat, 29 Mar 2008 10:33:46 +0100 (CET) Subject: [neutron-mc] Neutron parameters and EXTEND In-Reply-To: <816e49cc0803281944k1fdb81fftaec7782a0df3eac5@mail.gmail.com> References: <816e49cc0803271252mc54b0f1q9df583dfe58123a7@mail.gmail.com> <41893.193.49.43.124.1206651611.squirrel@195.83.126.3> <816e49cc0803271534hbb83461l2ee82faab80ef6c2@mail.gmail.com> <50736.193.49.43.124.1206689181.squirrel@195.83.126.3> <816e49cc0803281006k592eb433p6cd2ed5394b45018@mail.gmail.com> <53482.193.49.43.124.1206735163.squirrel@195.83.126.3> <816e49cc0803281944k1fdb81fftaec7782a0df3eac5@mail.gmail.com> Message-ID: <44814.193.49.43.124.1206783226.squirrel@195.83.126.3> 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 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 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 >> 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 >> >> >> 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 >> >> 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 >> 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 Groupe DS/CS, ILL4/156, Tel 04 76 20 71 35 ILL, Grenoble