From farhi at ill.fr Mon Jul 4 17:11:22 2005 From: farhi at ill.fr (Emmanuel FARHI) Date: Mon, 04 Jul 2005 17:11:22 +0200 Subject: [neutron-mc] College I is waiting for you ! Message-ID: <42C9519A.1070203@ill.fr> An HTML attachment was scrubbed... URL: From j.voigt at fz-juelich.de Tue Jul 12 17:19:22 2005 From: j.voigt at fz-juelich.de (=?iso-8859-1?q?J=F6rg_Voigt?=) Date: Tue, 12 Jul 2005 17:19:22 +0200 Subject: [neutron-mc] Problems with FermiChopper.comp & Chopper_fermi.comp Message-ID: <200507121719.22724.j.voigt@fz-juelich.de> I encountered several problems with the 2 fermi chopper components mentioned above. FermiChopper.comp located in contrib: If I use 2 choppers I can not compile, because several variables (xstrich, zstrich) are already defined. chopper_fermi.comp located in optics: I try to mimic a straight Fermi chopper, therefore I set the radius of curvature to large values like 1e6. Problems arise, if I put a small width for individual slits. E.g. for w=0.005 and n=20 I get a flux of 3e7 for a radius of 0.05. Changing w=0.001 and n=100 yields flux zero for the same radius, while w=0.002 and n=50 gives 0.6e6. I don't understand what really triggers the transmission of the component. Thank you for any help with the two components J?rg -- ====================== Dr.J?rg Voigt Institut f?r Streumethoden Forschungszentrum J?lich 52424 J?lich Deutschland Tel: +49 2461 616020 Fax: +49 2461 612610 Mobil: +49 160 8479827 Email: j.voigt at fz-juelich.de ====================== From James.Huang at nrc.gc.ca Fri Aug 12 18:28:16 2005 From: James.Huang at nrc.gc.ca (Huang, James - NRC) Date: Fri, 12 Aug 2005 12:28:16 -0400 Subject: [neutron-mc] mcrun.pl parameter scan problem Message-ID: Dear Mcstas experts, I was trying to do an exercise with the McStas 1.8 package in a Win XP environment. When I issued the command in a dos window: "C:\mcstas\lib\examples>mcrun.pl -N5 vanadium_example.instr rot=0,10" I got the following error message: "mcrun: Could not run simulation. at C:\mcstas\lib/tools/perl/mcrunlib.pl line 150." I tried to use the mcgui to do the same scan but still got the same error message. Anybody got a clue to help me out here? Thanks, James Dr. James Huang Visiting Fellow Canadian Neutron Beam Centre (CNBC) Chalk River Laboratories, Bldg. 459, Stn. 18 Chalk River, ON K0J 1J0 Canada CONFIDENTIAL AND PRIVILEGED INFORMATION NOTICE This e-mail, and any attachments, may contain information that is confidential, subject to copyright, or exempt from disclosure. Any unauthorized review, disclosure, retransmission, dissemination or other use of or reliance on this information may be unlawful and is strictly prohibited. AVIS D'INFORMATION CONFIDENTIELLE ET PRIVIL?GI?E Le pr?sent courriel, et toute pi?ce jointe, peut contenir de l'information qui est confidentielle, r?gie par les droits d'auteur, ou interdite de divulgation. Tout examen, divulgation, retransmission, diffusion ou autres utilisations non autoris?es de l'information ou d?pendance non autoris?e envers celle-ci peut ?tre ill?gale et est strictement interdite. -------------- next part -------------- An HTML attachment was scrubbed... URL: From R.M.Dalgliesh at rl.ac.uk Fri Aug 19 11:02:20 2005 From: R.M.Dalgliesh at rl.ac.uk (Dalgliesh, RM (Robert)) Date: Fri, 19 Aug 2005 10:02:20 +0100 Subject: [neutron-mc] McStas Polarisation details Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B29F29F9@exchange27.fed.cclrc.ac.uk> Dear Peter and Emmanuel, I've succesfully implemented polarising supermirrors, channeled guides and detectors using mcstas-1.8 over the past few days in a simple way but am now reaching the more technical details. I can rotate a component such as a single mirror through 90? but for the polarisation part of the calculation of the reflectivity the mirror needs to know what direction it is pointing in. The method of rotating the coordinate frame of the mirror doesn't allow me to know where things are pointing. Is there a way within mcstas to access the rotation matrix that has been applied to a component within that component. Best regards Rob ----------------------------------- Dr Robert Dalgliesh ISIS Rutherford Appleton Labortory Chilton Didcot Oxfordshire UK OX11 0QX Tel: +44 (0)1235 445687 Fax: +44 (0)1235 445720 e-mail: r.m.dalgliesh at rl.ac.uk From peter at willendrup.org Fri Aug 19 11:18:37 2005 From: peter at willendrup.org (Peter Willendrup) Date: Fri, 19 Aug 2005 11:18:37 +0200 Subject: [neutron-mc] McStas Polarisation details In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B29F29F9@exchange27.fed.cclrc.ac.uk> References: <57BFD82EEF0CDE41A72C4EDADF8A01B29F29F9@exchange27.fed.cclrc.ac.uk> Message-ID: <1124443117.385.13.camel@localhost.localdomain> Hi Robert, On Fri, 2005-08-19 at 10:02 +0100, Dalgliesh, RM (Robert) wrote: > I've succesfully implemented polarising supermirrors, channeled > guides and detectors using mcstas-1.8 over the past few days in > a simple way but am now reaching the more technical details. I > can rotate a component such as a single mirror through 90? but > for the polarisation part of the calculation of the reflectivity > the mirror needs to know what direction it is pointing in. The > method of rotating the coordinate frame of the mirror doesn't > allow me to know where things are pointing. Is there a way within > mcstas to access the rotation matrix that has been applied to a > component within that component. This is indeed great news! We will be very happy to include your work in the project in some way if you agree to do so? Are the changes you've made related to components only or do you reach into runtime / language features aswell? Yes, a feature like the one you need does exist, have a look in e.g. Source_flux_lambda.comp - the key is the rotation matrix ROT_A_CURRENT_COMP - in this source component used to define rectangular focusing (rectangular focusing is always gravitation-parallel in mcstas). Also, have a look at the mcstas-r.h and mcstas-r.c in the share part of the lib/ section, definition of the rotation axes etc. should be stated in there. If I can help in some other way, please let me know. Good work, Peter -- Peter Willendrup From R.M.Dalgliesh at rl.ac.uk Fri Aug 19 12:54:06 2005 From: R.M.Dalgliesh at rl.ac.uk (Dalgliesh, RM (Robert)) Date: Fri, 19 Aug 2005 11:54:06 +0100 Subject: [neutron-mc] McStas Polarisation details Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B29F29FD@exchange27.fed.cclrc.ac.uk> Peter, Thanks for this. This is all component based. I've not even considered thinking about magnetic fields and things like flippers. That has the potential to be very nasty. I simply wanted to do some checks for polarising components and look at the effects of absorbing layers, divergence and beamline configuration to start with. I'll do some thorough checking and attempt to generalise the components as best I can. Currently I've implemented a function to approximate the polarisation of the two spin states but I may well speak to Stuart Ansell about making use of input files and some interpolation as this is potentially much more flexible. All the best Rob -----Original Message----- From: neutron-mc-bounces at risoe.dk [mailto:neutron-mc-bounces at risoe.dk] On Behalf Of Peter Willendrup Sent: 19 August 2005 10:19 To: McStas users list at neutron.risoe.dk Subject: Re: [neutron-mc] McStas Polarisation details Hi Robert, On Fri, 2005-08-19 at 10:02 +0100, Dalgliesh, RM (Robert) wrote: > I've succesfully implemented polarising supermirrors, channeled guides > and detectors using mcstas-1.8 over the past few days in a simple way > but am now reaching the more technical details. I can rotate a > component such as a single mirror through 90? but for the polarisation > part of the calculation of the reflectivity the mirror needs to know > what direction it is pointing in. The method of rotating the > coordinate frame of the mirror doesn't allow me to know where things > are pointing. Is there a way within mcstas to access the rotation > matrix that has been applied to a component within that component. This is indeed great news! We will be very happy to include your work in the project in some way if you agree to do so? Are the changes you've made related to components only or do you reach into runtime / language features aswell? Yes, a feature like the one you need does exist, have a look in e.g. Source_flux_lambda.comp - the key is the rotation matrix ROT_A_CURRENT_COMP - in this source component used to define rectangular focusing (rectangular focusing is always gravitation-parallel in mcstas). Also, have a look at the mcstas-r.h and mcstas-r.c in the share part of the lib/ section, definition of the rotation axes etc. should be stated in there. If I can help in some other way, please let me know. Good work, Peter -- Peter Willendrup _______________________________________________ neutron-mc mailing list neutron-mc at risoe.dk http://neutron.risoe.dk/mailman/listinfo/neutron-mc From R.M.Dalgliesh at rl.ac.uk Fri Aug 19 17:30:09 2005 From: R.M.Dalgliesh at rl.ac.uk (Dalgliesh, RM (Robert)) Date: Fri, 19 Aug 2005 16:30:09 +0100 Subject: [neutron-mc] McStas Polarisation details Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B29F2A0A@exchange27.fed.cclrc.ac.uk> Sorry for the deluge of e-mails of Peter, I'm learning quite a lot here. It looks as if the neutron polarisation direction is rotated with the objects. There is a mccoordschange_polarisation function defined in mcstas-r.c which I presume is applied whenever ROTATED is applied. Unfortunately for the situation of a polarising mirror, where the polarisation direction is confined to the plane of the mirror, this isn't particularly useful as I want the neutron polarisation direction to remain fixed and mirror polarisation direction to change. If I want the neutron polarisation direction change I will then force the change by knowing the relationship between the incident polarisation direction and the component itself. I think I'm going to have to try and decouple this functionality somehow but this is now into the nuts and bolts of the mcstas instrument build process. Is there a more detailed manual anywhere with handy hints about doing such things or is just a case of ploughing my way throught the code? My guess would be that the best way of doing this is to ensure that the neutron polarisation direction remains unchanged throughout the instrument unless changed by a component in some way. I would be interested to here other people's thoughts on this especially with regards to He3 cells. Thanks Rob ----------------------------------- Dr Robert Dalgliesh ISIS Rutherford Appleton Labortory Chilton Didcot Oxfordshire UK OX11 0QX Tel: +44 (0)1235 445687 Fax: +44 (0)1235 445720 e-mail: r.m.dalgliesh at rl.ac.uk -----Original Message----- From: neutron-mc-bounces at risoe.dk [mailto:neutron-mc-bounces at risoe.dk] On Behalf Of Peter Willendrup Sent: 19 August 2005 10:19 To: McStas users list at neutron.risoe.dk Subject: Re: [neutron-mc] McStas Polarisation details Hi Robert, On Fri, 2005-08-19 at 10:02 +0100, Dalgliesh, RM (Robert) wrote: > I've succesfully implemented polarising supermirrors, channeled guides > and detectors using mcstas-1.8 over the past few days in a simple way > but am now reaching the more technical details. I can rotate a > component such as a single mirror through 90? but for the polarisation > part of the calculation of the reflectivity the mirror needs to know > what direction it is pointing in. The method of rotating the > coordinate frame of the mirror doesn't allow me to know where things > are pointing. Is there a way within mcstas to access the rotation > matrix that has been applied to a component within that component. This is indeed great news! We will be very happy to include your work in the project in some way if you agree to do so? Are the changes you've made related to components only or do you reach into runtime / language features aswell? Yes, a feature like the one you need does exist, have a look in e.g. Source_flux_lambda.comp - the key is the rotation matrix ROT_A_CURRENT_COMP - in this source component used to define rectangular focusing (rectangular focusing is always gravitation-parallel in mcstas). Also, have a look at the mcstas-r.h and mcstas-r.c in the share part of the lib/ section, definition of the rotation axes etc. should be stated in there. If I can help in some other way, please let me know. Good work, Peter -- Peter Willendrup _______________________________________________ neutron-mc mailing list neutron-mc at risoe.dk http://neutron.risoe.dk/mailman/listinfo/neutron-mc From peter.willendrup at risoe.dk Mon Aug 22 11:43:48 2005 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Mon, 22 Aug 2005 11:43:48 +0200 Subject: [neutron-mc] McStas Polarisation details In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B29F2A0A@exchange27.fed.cclrc.ac.uk> References: <57BFD82EEF0CDE41A72C4EDADF8A01B29F2A0A@exchange27.fed.cclrc.ac.uk> Message-ID: <1124703828.25615.18.camel@localhost.localdomain> Hi Robert, On Fri, 2005-08-19 at 16:30 +0100, Dalgliesh, RM (Robert) wrote: > Sorry for the deluge of e-mails of Peter, No need to excuse, its' what I'm here for and what the list is there for. > It looks as if the neutron polarisation direction is rotated with the objects. > There is a mccoordschange_polarisation function defined in mcstas-r.c which I > presume is applied whenever ROTATED is applied. Unfortunately for the situation > of a polarising mirror, where the polarisation direction is confined to the plane > of the mirror, this isn't particularly useful as I want the neutron polarisation > direction to remain fixed and mirror polarisation direction to change. If I want > the neutron polarisation direction change I will then force the change by knowing > the relationship between the incident polarisation direction and the component itself. > I think I'm going to have to try and decouple this functionality somehow but this is > now into the nuts and bolts of the mcstas instrument build process. Is there a more > detailed manual anywhere with handy hints about doing such things or is just a case > of ploughing my way throught the code? Well. The rotation of the spins ofcourse (and by symmetry the neutron coordinates) only happens to allow working in a local component oriented coordinate system (where interactions between component and neutron are handled in an easier way). With my current overview of the package, regarding spin variables and polarisation, only the infrastructure is there. No existing component really changes the spin state, spins initially set parrallel to gravity it seems. Interacting with the neutron spin would (by symmetry as in the case of neutron coordinates) happen by simply setting the sx,sy,sz variables within the component (x,y,z / vx,vy,vz in the case of neutron coordinates). As far as I know, there is next to no documentation anywhere in manuals etc., only the basic infrastructure was added. So basically, any input added from you and others will serve as the basis for what we decide to implement. I think that the possibility to use interpolated magnetic field input files (mentioned by you elsewhere) is a reasonably flexible solution, currently exising in the Vitess package (some of Geza's components work this way). > My guess would be that the best way of doing this is to ensure that the neutron polarisation > direction remains unchanged throughout the instrument unless changed by a component in some > way. I would be interested to here other people's thoughts on this especially with regards > to He3 cells. I agree, it is very relevant to hear opinions on what to focus at before we really get going. So people, make your remarks! :-) Regards, Peter -- ------------------------------------- Peter Kjaer Willendrup, cand. scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- From kn at sifira.dk Mon Aug 22 12:00:56 2005 From: kn at sifira.dk (Kristian Nielsen) Date: Mon, 22 Aug 2005 12:00:56 +0200 Subject: [neutron-mc] McStas Polarisation details In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B29F2A0A@exchange27.fed.cclrc.ac.uk> References: <57BFD82EEF0CDE41A72C4EDADF8A01B29F2A0A@exchange27.fed.cclrc.ac.uk> Message-ID: <7s8xyuthnr.fsf@ash.int.sifira.dk> "Dalgliesh, RM (Robert)" writes: > It looks as if the neutron polarisation direction is rotated with the > objects. Now, it is admittedly a long time since I've been active with McStas :-) But it looks to me as if you fundamentally misunderstand the use of ROTATED in McStas. When you say ROTATED in the instrument file, it means that you physically change the orientation of the component. When you turn your coffe cup upside down, certainly all other properties of the cup changes orientation with it, _except_ for gravity which doesn't change and so your coffe spills out! If on the other hand you want to control the polarisation direction of a polarised mirror relative to the mirror geometry itself, that needs to be given as a parameter to the component, and the component code must handle the appropriate calculation itself. That would correspond to programming a coffe cup where the orientation of the handle could be changed. Hope this helps, and sorry if after five years of no McStas work I am talking complete nonsense. - Kristian. From R.M.Dalgliesh at rl.ac.uk Mon Aug 22 13:12:23 2005 From: R.M.Dalgliesh at rl.ac.uk (Dalgliesh, RM (Robert)) Date: Mon, 22 Aug 2005 12:12:23 +0100 Subject: [neutron-mc] McStas Polarisation details Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE1@exchange27.fed.cclrc.ac.uk> Hi Kristian, Peter, You make a good analogy. On further thought there is a bit of a problem here. I need to know the absolute relationship between the two polarisation directions in order to define the reflected intensity. If I rotate a mirror where the polarisation direction has been fixed in the x axis direction and the mirror is horizontal (x-z plane) then a 90 degree rotation process means that the plane of the mirror is now in the y-z plane. Then without an operation on the defined polarisation direction of the mirror it will still think it is in the x direction. Rotation of the polarisation vector does then make sense if I take a dot product as the two directions will now be at 90. This doesn't make much sense intuitively however. My personal preference would still be to define a polarisation direction within a component (similar to that of the neutron) which would then be rotated such that the polarisation direction of the neutron can be left unchanged. I admit that this will need an extra part to the rotation process that would only be invoked if polarisation is turned on. However, I think this would be likely to lead to fewer mistakes later on such as when further polarising components are added. I can foresee particular problems when components are position absolutely in space but a rotation of one component has been necessary, e.g. with a channelled guide. Rob ________________________________ From: neutron-mc-bounces at risoe.dk on behalf of Kristian Nielsen Sent: Mon 22/08/2005 11:00 To: McStas users list at neutron.risoe.dk Subject: Re: [neutron-mc] McStas Polarisation details "Dalgliesh, RM (Robert)" writes: > It looks as if the neutron polarisation direction is rotated with the > objects. Now, it is admittedly a long time since I've been active with McStas :-) But it looks to me as if you fundamentally misunderstand the use of ROTATED in McStas. When you say ROTATED in the instrument file, it means that you physically change the orientation of the component. When you turn your coffe cup upside down, certainly all other properties of the cup changes orientation with it, _except_ for gravity which doesn't change and so your coffe spills out! If on the other hand you want to control the polarisation direction of a polarised mirror relative to the mirror geometry itself, that needs to be given as a parameter to the component, and the component code must handle the appropriate calculation itself. That would correspond to programming a coffe cup where the orientation of the handle could be changed. Hope this helps, and sorry if after five years of no McStas work I am talking complete nonsense. - Kristian. _______________________________________________ neutron-mc mailing list neutron-mc at risoe.dk http://neutron.risoe.dk/mailman/listinfo/neutron-mc -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5473 bytes Desc: not available URL: From peter.willendrup at risoe.dk Mon Aug 22 15:04:00 2005 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Mon, 22 Aug 2005 15:04:00 +0200 Subject: [neutron-mc] McStas Polarisation details In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE1@exchange27.fed.cclrc.ac.uk> References: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE1@exchange27.fed.cclrc.ac.uk> Message-ID: <1124715840.25615.50.camel@localhost.localdomain> Hi again, On Mon, 2005-08-22 at 13:12 +0200, Dalgliesh, RM (Robert) wrote: > You make a good analogy. On further thought there is a bit of a problem here. > I need to know the absolute relationship between the two polarisation directions > in order to define the reflected intensity. If I rotate a mirror where the > polarisation direction has been fixed in the x axis direction and the mirror > is horizontal (x-z plane) then a 90 degree rotation process means that the > plane of the mirror is now in the y-z plane. Then without an operation on the > defined polarisation direction of the mirror it will still think it is in the > x direction. Rotation of the polarisation vector does then make sense if I take > a dot product as the two directions will now be at 90. This doesn't make much > sense intuitively however. Possibly I am missing a point here, but: It seems to me that since components interacting with the neutron spin are physical device e.g. with little mounted magnets, it does not make much sense to define a 'polarisation direction' relative to the global coordinate system (meaning the e.g. the global 'x' direction). Better would be to define this direction within the local coordinate system, i.e., rotating the component will rotate the component polarisation direction since rotating the little physical magnets or coils. It seems to me that the description above mixes the global coordinate system of the instrument with that of the component (in which we are almost always handeling the neutron - in samples for instance, we are to first order dependent on local geometry, not on where the source component was situated). Regards, Peter > My personal preference would still be to define a polarisation direction > within a component (similar to that of the neutron) which would then be > rotated such that the polarisation direction of the neutron can be left > unchanged. I admit that this will need an extra part to the rotation > process that would only be invoked if polarisation is turned on. However, > I think this would be likely to lead to fewer mistakes later on such as > when further polarising components are added. I can foresee particular > problems when components are position absolutely in space but a rotation of > one component has been necessary, e.g. with a channelled guide. -- ------------------------------------- Peter Kjaer Willendrup, cand. scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- From R.M.Dalgliesh at rl.ac.uk Mon Aug 22 15:36:48 2005 From: R.M.Dalgliesh at rl.ac.uk (Dalgliesh, RM (Robert)) Date: Mon, 22 Aug 2005 14:36:48 +0100 Subject: [neutron-mc] McStas Polarisation details Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE4@exchange27.fed.cclrc.ac.uk> Peter, I suppose that's what I was trying to get to but wrote a totally garbled e-mail. If the field/polarisation direction is defined locally within the component then I guess we have got back to applying the ROT_A_CURRENT_COMP transform locally, as you first suggested. As far as I can see the ROT_A_CURRENT_COMP is a cumulative transform so this shouldn't be a problem but the neutron spin does then need to be decoupled from the ROTATED command. Regards Rob ________________________________ From: neutron-mc-bounces at risoe.dk on behalf of Peter Willendrup Sent: Mon 22/08/2005 14:04 To: McStas users list at neutron.risoe.dk Subject: RE: [neutron-mc] McStas Polarisation details Hi again, On Mon, 2005-08-22 at 13:12 +0200, Dalgliesh, RM (Robert) wrote: > You make a good analogy. On further thought there is a bit of a problem here. > I need to know the absolute relationship between the two polarisation directions > in order to define the reflected intensity. If I rotate a mirror where the > polarisation direction has been fixed in the x axis direction and the mirror > is horizontal (x-z plane) then a 90 degree rotation process means that the > plane of the mirror is now in the y-z plane. Then without an operation on the > defined polarisation direction of the mirror it will still think it is in the > x direction. Rotation of the polarisation vector does then make sense if I take > a dot product as the two directions will now be at 90. This doesn't make much > sense intuitively however. Possibly I am missing a point here, but: It seems to me that since components interacting with the neutron spin are physical device e.g. with little mounted magnets, it does not make much sense to define a 'polarisation direction' relative to the global coordinate system (meaning the e.g. the global 'x' direction). Better would be to define this direction within the local coordinate system, i.e., rotating the component will rotate the component polarisation direction since rotating the little physical magnets or coils. It seems to me that the description above mixes the global coordinate system of the instrument with that of the component (in which we are almost always handeling the neutron - in samples for instance, we are to first order dependent on local geometry, not on where the source component was situated). Regards, Peter > My personal preference would still be to define a polarisation direction > within a component (similar to that of the neutron) which would then be > rotated such that the polarisation direction of the neutron can be left > unchanged. I admit that this will need an extra part to the rotation > process that would only be invoked if polarisation is turned on. However, > I think this would be likely to lead to fewer mistakes later on such as > when further polarising components are added. I can foresee particular > problems when components are position absolutely in space but a rotation of > one component has been necessary, e.g. with a channelled guide. -- ------------------------------------- Peter Kjaer Willendrup, cand. scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- _______________________________________________ neutron-mc mailing list neutron-mc at risoe.dk http://neutron.risoe.dk/mailman/listinfo/neutron-mc -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 6273 bytes Desc: not available URL: From lieutena at ill.fr Mon Aug 22 16:32:19 2005 From: lieutena at ill.fr (Klaus Lieutenant) Date: Mon, 22 Aug 2005 16:32:19 +0200 Subject: [neutron-mc] McStas Polarisation details In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE4@exchange27.fed.cclrc.ac.uk> References: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE4@exchange27.fed.cclrc.ac.uk> Message-ID: <4309E1F3.7040303@ill.fr> Dear Robert, why should the neutron spin be decoupled from the ROTATED command ? This command takes care that all parameters (velocity, ...) of the neutron are transformed to the local co-ordinate system of the component. This is also necessary for the spin. Imagine you have polarised a beam into a certain direction and you like to analyse the polarisation direction afterwards with a component that is rotated relative to the polariser. For this analyser, you need to know the polarisation direction in its co-ordinate system, i.e. a rotation of the spin co-ordinates is necessary. Best regards, Klaus Dalgliesh, RM (Robert) wrote: >Peter, >I suppose that's what I was trying to get to but wrote a totally garbled e-mail. If the field/polarisation direction is defined locally within the component then I guess we have got back to applying the ROT_A_CURRENT_COMP transform locally, as you first suggested. As far as I can see the ROT_A_CURRENT_COMP is a cumulative transform so this shouldn't be a problem but the neutron spin does then need to be decoupled from the ROTATED command. > >Regards > >Rob > > From R.M.Dalgliesh at rl.ac.uk Mon Aug 22 17:03:55 2005 From: R.M.Dalgliesh at rl.ac.uk (Dalgliesh, RM (Robert)) Date: Mon, 22 Aug 2005 16:03:55 +0100 Subject: [neutron-mc] McStas Polarisation details Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE6@exchange27.fed.cclrc.ac.uk> Hi Klaus, It's exactly this sort of situation I'm trying to imagine. On CRISP (at ISIS) we make use of a horizontal polarisation direction and then analyse in the vertical so that we can probe off specular scattering from a horizontal sample. For this I would write a spin rotator component to do the same job as the physical device. This is very trivial. The problem I have with allowing the spin vector to be rotated is with what happens as more polarising components are added and if they are rotated with respect to one another or positioned absolutley. In the long run this is likely to get very messy. I thought that another alternative to do this would be to apply the inverse of ROT _A_CURRENT_COMP, as Peter originally suggested, in the component but as ROT _A_CURRENT_COMP is cummulative it would depend on where you polarised your beam as to what happens. Rob ________________________________ From: neutron-mc-bounces at risoe.dk on behalf of Klaus Lieutenant Sent: Mon 22/08/2005 15:32 To: McStas users list at neutron.risoe.dk Subject: Re: [neutron-mc] McStas Polarisation details Dear Robert, why should the neutron spin be decoupled from the ROTATED command ? This command takes care that all parameters (velocity, ...) of the neutron are transformed to the local co-ordinate system of the component. This is also necessary for the spin. Imagine you have polarised a beam into a certain direction and you like to analyse the polarisation direction afterwards with a component that is rotated relative to the polariser. For this analyser, you need to know the polarisation direction in its co-ordinate system, i.e. a rotation of the spin co-ordinates is necessary. Best regards, Klaus Dalgliesh, RM (Robert) wrote: >Peter, >I suppose that's what I was trying to get to but wrote a totally garbled e-mail. If the field/polarisation direction is defined locally within the component then I guess we have got back to applying the ROT_A_CURRENT_COMP transform locally, as you first suggested. As far as I can see the ROT_A_CURRENT_COMP is a cumulative transform so this shouldn't be a problem but the neutron spin does then need to be decoupled from the ROTATED command. > >Regards > >Rob > > _______________________________________________ neutron-mc mailing list neutron-mc at risoe.dk http://neutron.risoe.dk/mailman/listinfo/neutron-mc -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5261 bytes Desc: not available URL: From lieutena at ill.fr Tue Aug 23 11:06:50 2005 From: lieutena at ill.fr (Klaus Lieutenant) Date: Tue, 23 Aug 2005 11:06:50 +0200 Subject: [neutron-mc] McStas Polarisation details In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE6@exchange27.fed.cclrc.ac.uk> References: <57BFD82EEF0CDE41A72C4EDADF8A01B201492BE6@exchange27.fed.cclrc.ac.uk> Message-ID: <430AE72A.8050601@ill.fr> Hi Rob, I still think the best way is to treat the neutrons in the local co-ordinate system of a component and let the McStas kernel perform the transformation (of the neutron co-ordinates) to the following components, i.e. not to perform any additional transformation due to position or orientation of the component. This works fine with position and velocity; and (without looking into details) I do not see why it should fail with the spin. By the way, I am very interested in your work, because I will probably also write components for polarised neutrons in the near future. Maybe we should meet when I am at ISIS end of September. Klaus Dalgliesh, RM (Robert) wrote: >Hi Klaus, >It's exactly this sort of situation I'm trying to imagine. On CRISP (at ISIS) we make use of a horizontal polarisation direction and then analyse in the vertical so that we can probe off specular scattering from a horizontal sample. For this I would write a spin rotator component to do the same job as the physical device. This is very trivial. The problem I have with allowing the spin vector to be rotated is with what happens as more polarising components are added and if they are rotated with respect to one another or positioned absolutley. In the long run this is likely to get very messy. >I thought that another alternative to do this would be to apply the inverse of ROT _A_CURRENT_COMP, as Peter originally suggested, in the component but as ROT _A_CURRENT_COMP is cummulative it would depend on where you polarised your beam as to what happens. > >Rob > > From R.M.Dalgliesh at rl.ac.uk Tue Aug 23 15:00:53 2005 From: R.M.Dalgliesh at rl.ac.uk (Dalgliesh, RM (Robert)) Date: Tue, 23 Aug 2005 14:00:53 +0100 Subject: [neutron-mc] McStas Polarisation details Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B29F2A0C@exchange27.fed.cclrc.ac.uk> Hi Klaus, Peter, Kristian, Ok, I've done more testing with a series simple components that report the polarisation direction of the neutron and nothing else. After an hour or so of head scratching thankfully Klaus is right. Using simple components my main concern regarding what happens with absolute positioning appears not to be a problem. The polarisation matrix is only changed locally within each component and so the test instrument below does exactly as it should. i.e. if you rotate the first 2 pol_test components they report the polarisation direction along the y direction but the 3rd if left unrotated does not. It serves me right for diving in at the deep end. I will have to carefully check through my polariser component to work out exactly where I was going wrong with my polarisation definitions. Hopefully I will have a fully tested version soon. Thanks for the help and suggestions. Rob --------------------------------------------------- /*********************************************************************** ******** * * Component: pol_set * * %I * Written by: Robert Dalgliesh * Date: August 2005 * Version: $Revision: 0.5 $ * Origin: ISIS * * Component to define the polarisation of a neutorn beam * * %D * The routine defines the polarisation of a neutron beam * to be 50% +/- along either the x,y or z axes. * * Example: set_pol(sx1=1,sy1=0,sz1=0) * * %P * sx1: (1) Direction beam is to be polarised along x axis * sy1: (1) Direction beam is to be polarised along y axis * sz1: (1) Direction beam is to be polarised along z axis * * %E ************************************************************************ *******/ DEFINE COMPONENT pol_set DEFINITION PARAMETERS () SETTING PARAMETERS (sx1=1, sy1=0, sz1=0) STATE PARAMETERS (x,y,z,vx,vy,vz,t,s1,s2,p) POLARISATION PARAMETERS (sx,sy,sz) /* define random polarisation direction this can probably be done more quickly*/ TRACE %{ double norm,sumpol; sumpol=sx1+sy1+sz1; if (sumpol > 1) { fprintf(stderr,"pol_set: You have tried to define polarisation in more than one direction\n",NAME_CURRENT_COMP); exit(-1); } if(sx1 > 0){ do{ sx = randpm1(); norm = sx*sx; } while (norm > 1 || norm == 0); norm=sqrt(norm); sx /= norm; sy = 0.0; sz = 0.0; }else if(sy1 > 0){ do{ sy = randpm1(); norm = sy*sy; } while (norm > 1 || norm == 0); norm=sqrt(norm); sy /= norm; sx = 0.0; sz = 0.0; }else{ do{ sz = randpm1(); norm = sz*sz; } while (norm > 1 || norm == 0); norm=sqrt(norm); sz /= norm; sx = 0.0; sy = 0.0; } printf("pol_set: sx %f, sy %f, sz %f \n",sx,sy,sz); %} END ------------------------------------------------------- /*********************************************************************** ******** * * Component: pol_test * * %I * Written by: Robert Dalgliesh * Date: August 2005 * Version: $Revision: 0.1 $ * Origin: ISIS * * Do nothing * * %D * do nothing but print polarisation direction * * Example: set_test * * %P * * %E ************************************************************************ *******/ DEFINE COMPONENT pol_test DEFINITION PARAMETERS () SETTING PARAMETERS () STATE PARAMETERS (x,y,z,vx,vy,vz,t,s1,s2,p) POLARISATION PARAMETERS (sx,sy,sz) TRACE %{ if(abs(sy) > 1e-6){ printf("Pol along sy\n"); } printf("pol_test: sx %f, sy %f, sz %f \n",sx,sy,sz); %} END ------------------------------------------------------ DEFINE INSTRUMENT test(az1=0.0,az2=0.0,az3=0.0) DECLARE %{ %} INITIALIZE %{ %} TRACE COMPONENT Origin = Arm() AT (0,0,0) ABSOLUTE COMPONENT source1 = Source_flat_lambda( radius = 0.05, dist = 18.0, xw = 0.04, yh = 0.002, lambda_0 = 8.0, d_lambda = 7.5) AT (0.0, 0.0, 0.00001) RELATIVE Origin COMPONENT pol_set1 = pol_set( sx1 = 1, sy1 = 0, sz1 = 0) AT (0.0, 0.0, 0.01) RELATIVE source1 COMPONENT slit1 = Slit( xmin = -0.02, xmax = 0.02, ymin = -0.001, ymax = 0.001) AT (0.0, 0.0, 18.0) RELATIVE source1 COMPONENT ptest1 = pol_test( ) AT (0.0, 0.0, 1.0) RELATIVE slit1 ROTATED (0.0, 0.0, az1) RELATIVE slit1 COMPONENT ptest2 = pol_test( ) AT (0.0, 0.0, 0.1) RELATIVE ptest1 ROTATED (0.0, 0.0, az2) RELATIVE ptest1 COMPONENT ptest3 = pol_test( ) AT (0.0, 0.0, 1.2) RELATIVE slit1 ROTATED (0.0, 0.0, az3) RELATIVE slit1 FINALLY %{ %} END From farhi at ill.fr Wed Aug 24 11:09:57 2005 From: farhi at ill.fr (Emmanuel FARHI) Date: Wed, 24 Aug 2005 11:09:57 +0200 Subject: [neutron-mc] mcrun.pl parameter scan problem In-Reply-To: References: Message-ID: <430C3965.3040604@ill.fr> An HTML attachment was scrubbed... URL: From farhi at ill.fr Fri Sep 30 11:43:49 2005 From: farhi at ill.fr (Emmanuel FARHI) Date: Fri, 30 Sep 2005 11:43:49 +0200 Subject: [neutron-mc] Re: McStas on OS X In-Reply-To: References: Message-ID: <433D08D5.2090607@ill.fr> An HTML attachment was scrubbed... URL: From j.voigt at fz-juelich.de Fri Sep 30 15:05:36 2005 From: j.voigt at fz-juelich.de (=?iso-8859-1?q?J=F6rg_Voigt?=) Date: Fri, 30 Sep 2005 15:05:36 +0200 Subject: [neutron-mc] Curved monochromator Message-ID: <200509301505.36727.j.voigt@fz-juelich.de> Dear mailing list subscribers, I try to model a curved monochromator for thermal neutrons with horizontal and vertical focussing. The monochromator is fairly large, 40 cm wide and 30 cm high. Using a Cu (220) monochromator, D=1.28 A, I end up with an Bragg angle of 23 deg. Now the problem, the focus of monochromator is not exactly at 2*Braggangle. Using a psd Monitor relative to the scattered beam, the offset is always in negative x direction and larger the smaller the horizontal radius of curvature becomes, i.e. for a stronger curved monochromator. Did this happen already to anybody? Thank you -- ====================== Dr.J?rg Voigt Institut f?r Streumethoden Forschungszentrum J?lich 52424 J?lich Deutschland Tel: +49 2461 616020 Fax: +49 2461 612610 Mobil: +49 160 8479827 Email: j.voigt at fz-juelich.de ====================== -------------- next part -------------- A non-text attachment was scrubbed... Name: in4type_050930.instr Type: text/x-csrc Size: 8280 bytes Desc: not available URL: From lieutena at ill.fr Fri Sep 30 20:20:57 2005 From: lieutena at ill.fr (Klaus Lieutenant) Date: Fri, 30 Sep 2005 20:20:57 +0200 Subject: [neutron-mc] Curved monochromator In-Reply-To: <200509301505.36727.j.voigt@fz-juelich.de> References: <200509301505.36727.j.voigt@fz-juelich.de> Message-ID: <433D8209.4070500@ill.fr> Hi Joerg, this happened to me and probably to several other McStas users. The problem is: with the monitors 'DivergenceMonitorguide' and 'GuideExitLambda' prior to the monochromator you propagate the neutrons to a plane perpendicular to the incoming beam positioned at the centre of the monochromator. As this is rotated by 23 deg, half of the neutrons have now already passed the monochromator and are lost. The rest will be reflected on one half of the monochromator; but of course the focus will be shifted, as practically only one side of the monochromator is illuminated. One solution is to position the monitors in front of the monochromator. The latest McStas version also offers the possibility to allow a 'back propagation' of the neutrons. You need to add EXTEND %{ ALLOW_BACKPROP; %} to the component directly before the monochromator. It sets the flag 'back propagation is allowed' for the next propagation. After this propagation, the flag is automatically reset. Regards, Klaus