From pwilk-neutron at zenspider.com Fri Feb 14 15:09:20 2003 From: pwilk-neutron at zenspider.com (Philip Wilk) Date: Fri, 14 Feb 2003 06:09:20 -0800 Subject: [neutron-mc] mcstas 1.4.2 on freebsd Message-ID: <20030214140920.GA55371@greed.zenspider.com> MCSTAS 1.4.2 on freeBSD does not work either: /usr/home/pwilk/work/mcstas-1.4.2/examples> mcstas vanadium_example.instr parse error, expecting `TOK_ID' at line 31. Fatal error: Errors encountered during autoload of component Arm. Program aborted. What version should I use? 1.4.2 1.5 1.6-ill? Confused, From peter.willendrup at risoe.dk Fri Feb 14 16:29:01 2003 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Fri, 14 Feb 2003 16:29:01 +0100 (CET) Subject: [neutron-mc] mcstas 1.4.2 on freebsd In-Reply-To: <20030214140920.GA55371@greed.zenspider.com> Message-ID: Hello Philip, On Fri, 14 Feb 2003, Philip Wilk wrote: > What version should I use? > > 1.4.2 > 1.5 > 1.6-ill? Your problems are probably not related to the FreeBSD system. If you read the McStas News, shortly after the version 1.4.2 was released, an announce was issued as: > Message from the McStas site News 2001: > "April 26, 2001: A corrected version of Arm.comp is available" You can get it from , but the Arm.comp from version 1.5 will also do. Just copy it to the 1.4.2 lib/optics. To be sure, it is also attached with this mail. To answer the other question, Emmanuel Farhi and I are currently working on a new, common Risoe/ILL mcstas version, which will probably be out in aproximately two months. Hope this helps, Peter Willendrup -- ------------------------------------- Peter Kjaer Willendrup, Cand. Scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- -------------- next part -------------- /******************************************************************************* * * McStas, the neutron ray-tracing package: Arm component * Copyright 1997-2001 Risoe National Laboratory, Roskilde, Denmark * * %I * * Written by: Kim Lefmann and Kristian Nielsen * Date: September 1997 * Version: $Revision: 1.5 $ * Origin: McStas 1.4.2 * * Arm/optical bench * * %D * An arm does not actually do anything, it is just there to set * up a new coordinate system. * * %P * Input parameters: * * (none) * * %E *******************************************************************************/ DEFINE COMPONENT Arm DEFINITION PARAMETERS () SETTING PARAMETERS () STATE PARAMETERS () POLARISATION PARAMETERS (sx,sy,sz) TRACE %{ %} MCDISPLAY %{ /* A bit ugly; hard-coded dimensions. */ magnify(""); line(0,0,0,0.2,0,0); line(0,0,0,0,0.2,0); line(0,0,0,0,0,0.2); %} END From pwilk-neutron at zenspider.com Fri Mar 21 13:41:49 2003 From: pwilk-neutron at zenspider.com (Philip Wilk) Date: Fri, 21 Mar 2003 04:41:49 -0800 Subject: [neutron-mc] bender.comp issues and the new version? In-Reply-To: References: <20030214140920.GA55371@greed.zenspider.com> Message-ID: <20030321124149.GA69159@greed.zenspider.com> General questions on bender.comp: 1. How does one contact the author philipp.bernhardt now? 2. What the heck does he mean by concave and convex side of the beam tube? Which side is toward the bend? 3. Why does not the optional parameter "l" work? It should be l=r*Win, but if I supply l and r, it still complains about Win. 4. It says see http://neutron.risoe.dk/mcstas/support/misc/Bender.html for more information, but this page does not exist. > > What version should I use? > > > > 1.4.2 > > 1.5 > > 1.6-ill? > > To answer the other question, Emmanuel Farhi and I are currently > working on a new, common Risoe/ILL mcstas version, which will probably > be out in aproximately two months. How's this new version coming? - Philip at the FRMII From pwilk-neutron at zenspider.com Mon Mar 24 11:00:15 2003 From: pwilk-neutron at zenspider.com (Philip Wilk) Date: Mon, 24 Mar 2003 02:00:15 -0800 Subject: [neutron-mc] L_monitor.comp Message-ID: <20030324100015.GA6953@greed.zenspider.com> Which version of L_monitor.comp I should be using? I am using the mcstas version 1.6.4d executable and the 1.6.4e library. I am runing it all on a Win2K box with with free bcc compiler. This version includes a L_monitor.comp version 1.16, however, the MCSTAS website lists a version L_monitor.comp 1.4 for use with the MCSTAS 1.5 distribution. Now if this is not all confusing enough, I aways get a non-fatal "sqrt: DOMAIN error" when using either version. I have tracked it down to the "L_p[i] += p;" line in L_monitor.comp . It seems to still work fine, and sometimes when running the compiled simulation binary, I do not get this error; then when I run it again, I get the error. It always seems to generate reasonable results even with the error. I would really apprciate any insight or advice. Regards, Philip Wilk From peter.willendrup at risoe.dk Mon Mar 24 12:10:44 2003 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Mon, 24 Mar 2003 12:10:44 +0100 (CET) Subject: [neutron-mc] L_monitor.comp In-Reply-To: <20030324100015.GA6953@greed.zenspider.com> Message-ID: Hello Philip and mcstas users On Mon, 24 Mar 2003, Philip Wilk wrote: > Which version of L_monitor.comp I should be > using? I am using the mcstas version 1.6.4d executable and the 1.6.4e > library. I am runing it all on a Win2K box with with free bcc compiler. Regarding the 1.6.4 series: Everyone should notice that this is not a publicly available release - but a development version which has been provided to selected users for testing only. Bugs should be expected with this version, to be fixed in the oncomming official mcstas-1.7 version. > This version includes a L_monitor.comp version 1.16, however, > the MCSTAS website lists a version L_monitor.comp 1.4 for use with the > MCSTAS 1.5 distribution. Now if this is not all confusing enough, I > aways get a non-fatal "sqrt: DOMAIN error" when using either version. > I have tracked it down to the "L_p[i] += p;" line in L_monitor.comp . > It seems to still work fine, and sometimes when running the compiled > simulation binary, I do not get this error; then when I run it again, > I get the error. It always seems to generate reasonable results even > with the error. > > I would really apprciate any insight or advice. Here is a slightly technical answer to your question: In the 1.4 and 1.5 releases of mcstas, the L_N of neutron array was an int array. Event counts were later moved to double to pass the '1e9' long limit. This probably generates some alignement errors, that may be related to that sqrt error... We will ofcourse look into the problem, applying a fix to the code in the oncommming 1.7 release. To indicate a possible timeframe for the next release, note that Emmanuel Farhi and I are in the process of 'code freeze' - only very few more features will go into our current development version. Next, we'll have to do some more testing plus updates of the documentation... Regards, Peter Willendrup -- ------------------------------------- Peter Kjaer Willendrup, Cand. Scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- From M.J.Gutmann at rl.ac.uk Fri Mar 28 12:44:15 2003 From: M.J.Gutmann at rl.ac.uk (Gutmann, MJ (Matthias) ) Date: Fri, 28 Mar 2003 11:44:15 +0000 Subject: [neutron-mc] Single crystal peak in McStas1.6-ill Message-ID: <37CAC51AC5C1D211966100A0C9ED000A02AEED71@exchange07.rl.ac.uk> Hi, I am trying to use the single crystal together with a TOF detector and observe a strange peak shape for some parameter values in the simulation. The peak shape changes if an additional TOF monitor is inserted at the sample position. Is this to be expected? The instrument is as follows: 1) Flat lambda source. 2) An m=0 guide to mimic a rectangular collimator of 1cm^2 cross section at. 3) A TOF monitor before the entrance of that collimator. 4) A single crystal that is rotated by an angle theta with respect to the incident beam, fulfilling Bragg's law for a given wavelength (dspacing is calculated). 5) A TOF detector at the sample position (presently commented out). 6) A TOF monitor at a distance L2 to mimic a single pixel of a flat area detector. If the pixel is not in the center of the area detector (center positioned at an angle gamcen with respect to the incident beam) it is slightly tilted. The distance sample-pixel is recalculated as L2/cos(Gam - gamcen). Gam is the angle of the pixel with respect to the incindent beam. Input parameters are 1) Gam: Angle of pixel. 2) Gamcen: Angle of center of imaginary area detector. 3) L1: Distance source - sample. 4) L2: Distance sample - center of imaginary area detector. The "double peak" occurs e.g. for Gam = 60.0, Gamcen = 37.5, L1 = 8.3, L2 = 0.225. 10^8 neutrons were used. The shape changes if the TOF monitor at the sample position is uncommented. I've tried several things, e.g. taking the collimater out, changing the size of the focussing window, changing the size of the crystal, use different sources, untilted pixel. One thing I noticed is that the double peak occurs if the focussing window is smaller than the cross-section of the sample. It corresponds to the situation where the sample is not fully illuminated by the beam. The files used in the simulation are attached. Many thanks for your help, Matthias Gutmann -------------- next part -------------- A non-text attachment was scrubbed... Name: test.instr Type: application/octet-stream Size: 1965 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: YBaCuO4.dat Type: application/octet-stream Size: 34 bytes Desc: not available URL: From kn at sifira.dk Fri Mar 28 22:15:19 2003 From: kn at sifira.dk (Kristian Nielsen) Date: Fri, 28 Mar 2003 22:15:19 +0100 Subject: [neutron-mc] Single crystal peak in McStas1.6-ill In-Reply-To: <37CAC51AC5C1D211966100A0C9ED000A02AEED71@exchange07.rl.ac.uk> References: <37CAC51AC5C1D211966100A0C9ED000A02AEED71@exchange07.rl.ac.uk> Message-ID: <7sllyzry54.fsf@ash.int.sifira.dk> "Gutmann, MJ (Matthias) " writes: > and observe a strange peak shape for some parameter values in the > simulation. The peak shape changes if an additional TOF monitor is inserted > at the sample position. Is this to be expected? > 2) An m=0 guide to mimic a rectangular collimator of 1cm^2 cross section at. > 3) A TOF monitor before the entrance of that collimator. > L2 = 0.225. 10^8 neutrons were used. The shape changes if the TOF monitor > at the sample position is uncommented. Just a guess from my part, but your problem could be caused by components that are overlapping and/or written in the wrong sequence. McStas uses a simple (but fast) algorithm for propagating neutrons that assumes that components are passed by neutrons in exactly the order in which they are written in the instrument. Your instrument has a monitor which is physically before the collimator, but is written after the collimator in the instrument. Also your (commented) monitor overlaps the sample. Try to re-write the instrument so that no components overlap physically, and so that components appear in the instrument in the order that a neutron will encounter them. Remember to leave a small gap (say .1 mm) between adjacent components. Perhaps this will solve your problem; if not then perhaps someone else on the list can help. - Kristian. P.S. Good luck to all in the McStas community; it is nice to see the project I started still alive.