From hsvornl at gmail.com Mon Oct 11 19:29:27 2010 From: hsvornl at gmail.com (Santos-Villalobos, Hector J.) Date: Mon, 11 Oct 2010 13:29:27 -0400 Subject: [mcstas-users] Problem with McGUI Help(McDoc) -> Test McStas Installation Message-ID: Dear all, Thanks for all your effort on McStas. Forgive me, if my problem was already posted/solved in a previous thread. I searched the mailing list for an answer, but could not find a solution. THE PROBLEM: When I run the self-test from McGui the test fails. However, when I run the test from ?mcrun --test? the test succeeds. I noticed that McGui self-test has the ?single? and ?scan? parameters set to zero; while mcrun sets the parameters to 10,000 and 1000, respectively. Below is the output from the self-test ran from McGui. I?m running McGui on 64-bit MacOS Snow Leopard. I believe this is an installation issue, or a configuration file issue. I would like to solve this problem, so I can be sure that the simulations are correct. Thanks, Hector Santos # McStas self-test (mcrun --test='compatible graphics') McStas version 1.12b - Jul. 15, 2010 # Installing 'selftest' directory in /Users/hv5 # Copying instruments from /usr/local/lib/mcstas/examples/ # Counts: single=0, scans=0 # Output format: McStas # Start Date: Mon Oct 11 10:40:36 2010 Executing: mcrun --dir=prisma2a prisma2.instr --ncount=0 TT=-30 PHA=22 PHA1=-3 PHA2=-2 PHA3=-1 PHA4=0 PHA5=1 PHA6=2 PHA7=3 TTA=44 [FAILED] ISIS prisma2: in focusing mode: (256): Executing: mcplot -psc linup_1_45 [Warning] Plot of Scan of parameters with Risoe TAS1 monochromator rocking curve (no collimator): (512): [FAILED] Plot of Scan of parameters with Risoe TAS1 monochromator rocking curve (no collimator) Executing: mcplot -psc h8_test [Warning] Plot of Single simulation with Brookhaven H8 Termal TAS with vanadium sample: (512): [FAILED] Plot of Single simulation with Brookhaven H8 Termal TAS with vanadium sample # Installation check: FAILED. McStas has not been properly installed. # >> Check that you have a C compiler, perl, and perl-Tk installed. # End Date: Mon Oct 11 10:40:38 2010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkwi at risoe.dtu.dk Mon Oct 11 20:53:32 2010 From: pkwi at risoe.dtu.dk (Peter Willendrup) Date: Mon, 11 Oct 2010 14:53:32 -0400 Subject: [mcstas-users] Problem with McGUI Help(McDoc) -> Test McStas Installation In-Reply-To: References: Message-ID: <64B86D39-91AE-43FE-A34E-9BE3578EDD6A@risoe.dtu.dk> Hello Hector, Thanks for pointing this out - it is indeed a bug. A ticket has been created on our Trac to fix this: http://trac.mccode.org/ticket/32 I just had a quick look: The problem seems to be there across platforms. - And is likely related to the test running inside the mcgui perl shell, with improper initialization of variables as a result, as you point out with zero ncount's. As you point out, mcrun --test works, and hence you can safely trust your simulations. Sorry for the inconvenience and thanks again for pointing out the problem. Best regards, Peter Willendrup -- ------------------------------------------------------------------- Peter Willendrup - Development engineer RIS? DTU Materials Research Division Frederiksborgvej 399 DK-4000 Roskilde Tlf.: (+45) 4677 5862 Mobil.: (+45) 2125 4612 Fax.: (+45) 4766 5758 Email: pkwi at risoe.dtu.dk ------------------------------------------------------------------- On 11/10/2010, at 13.29, Santos-Villalobos, Hector J. wrote: > Dear all, > > Thanks for all your effort on McStas. Forgive me, if my problem was already posted/solved in a previous thread. I searched the mailing list for an answer, but could not find a solution. > > THE PROBLEM: When I run the self-test from McGui the test fails. However, when I run the test from ?mcrun --test? the test succeeds. I noticed that McGui self-test has the ?single? and ?scan? parameters set to zero; while mcrun sets the parameters to 10,000 and 1000, respectively. Below is the output from the self-test ran from McGui. I?m running McGui on 64-bit MacOS Snow Leopard. I believe this is an installation issue, or a configuration file issue. I would like to solve this problem, so I can be sure that the simulations are correct. > > Thanks, > Hector Santos > > # McStas self-test (mcrun --test='compatible graphics') > McStas version 1.12b - Jul. 15, 2010 > > # Installing 'selftest' directory in /Users/hv5 > # Copying instruments from /usr/local/lib/mcstas/examples/ > # Counts: single=0, scans=0 > # Output format: McStas > # Start Date: Mon Oct 11 10:40:36 2010 > Executing: mcrun --dir=prisma2a prisma2.instr --ncount=0 TT=-30 PHA=22 PHA1=-3 PHA2=-2 PHA3=-1 PHA4=0 PHA5=1 PHA6=2 PHA7=3 TTA=44 > [FAILED] ISIS prisma2: in focusing mode: (256): > Executing: mcplot -psc linup_1_45 > [Warning] Plot of Scan of parameters with Risoe TAS1 monochromator rocking curve (no collimator): (512): > [FAILED] Plot of Scan of parameters with Risoe TAS1 monochromator rocking curve (no collimator) > Executing: mcplot -psc h8_test > [Warning] Plot of Single simulation with Brookhaven H8 Termal TAS with vanadium sample: (512): > [FAILED] Plot of Single simulation with Brookhaven H8 Termal TAS with vanadium sample > # Installation check: FAILED. McStas has not been properly installed. > # >> Check that you have a C compiler, perl, and perl-Tk installed. > # End Date: Mon Oct 11 10:40:38 2010 > > _______________________________________________ > mcstas-users mailing list > mcstas-users at mcstas.org > http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From skoulatos at gmail.com Thu Oct 21 13:49:18 2010 From: skoulatos at gmail.com (Markos Skoulatos) Date: Thu, 21 Oct 2010 13:49:18 +0200 Subject: [mcstas-users] negative counts and peaks in McStas 1.12b Message-ID: Dear all, we are modeling a cold neutron triple axis spectrometer in McStas (for the FLEX upgrade in Berlin) and in the last few days I noticed some unusual behaviour in the complete instrument (consisting of source--->guides--->velocity selector--->more guides--->doubly focusing PG monochromator--->V sample--->horizontally curved PG analyser--->monitors). The most striking of all is the fact I get negative counts on my energy monitors, after the sample, for long wavelengths (below ki=1.36 A^-1) . I initially thought there is something wrong with the V sample (which still might be the case) until I noticed that the problem happens when the absolute value of the 2*theta angle of the monochromator (defined as A2 on this attached instrument) gets greater than roughly 90 degrees. So perhaps the monochromator has something to do with this. I tried extensively changing the A4 angle (2-theta angle of the sample) as well as instrument configurations (ie scattering senses at sample and analyser) in order to find some values where the program can run. I failed to make it run for cold wavelengths. My results for debugging purposes can be summarised as follows: 1. For ki>1.37 A^-1 things seem to run smoothly 2. At ki=1.36 A^-1 peaks start going below zero 3. In the magic range 1.35>ki>1.33 the energy monitors after the sample and at the detector are negative, however the monitor after the analyser is positive!! 4. For ki<1.32 all monitors after the V sample are inverted (negative). I attach a picture where you can see what I mean negative counts (simulation with ~1e7 trajectories). Has anybody some experience on simulations at colder wavelengths with monochromator take off angles above 90 degrees or has anyone noticed these negative counts? Perhaps McStas doesn't like this angle to be above 90 because then neutrons have a backward direction (back-scattering)? Even if I have some mistake in my file I can't see why my program runs at specific wavelengths (for example ki=1.55 is fine). In any case I think negative counts should not be there. cheers, Markos Skoulatos -------------- next part -------------- A non-text attachment was scrubbed... Name: FLEX2112_horiz_foc.instr Type: application/octet-stream Size: 18321 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: negative counts k is 1.256.bmp Type: image/bmp Size: 2082302 bytes Desc: not available URL: From pkwi at risoe.dtu.dk Thu Oct 21 15:09:12 2010 From: pkwi at risoe.dtu.dk (Peter Willendrup) Date: Thu, 21 Oct 2010 15:09:12 +0200 Subject: [mcstas-users] negative counts and peaks in McStas 1.12b In-Reply-To: References: Message-ID: <70A66617-644F-412A-AF37-9758F6DCDA67@risoe.dtu.dk> Hello Markos, Thanks for pointing this out. First of all, you are right: Negative events should never occur! :) My feeling is indeed that this relates to V_sample in the sense that this component uses the runtime function randvec_target_rect - which returns a solid-angle multiplier... (Some vector-geometry calculations internal to randvec_target_rect likely has a missing fabs() somewhere...) I haven't looked yet, but my guess is that the immediate workaround is to use focus_r instead of focus_rw and focus_yh. I will have a closer look and fix this - likely next week... In turn, this likely means another update release, 1.12c... Cheers, Peter -- ------------------------------------------------------------------- Peter Willendrup - Development engineer RIS? DTU Materials Research Division Frederiksborgvej 399 DK-4000 Roskilde Tlf.: (+45) 4677 5862 Mobil.: (+45) 2125 4612 Fax.: (+45) 4766 5758 Email: pkwi at risoe.dtu.dk ------------------------------------------------------------------- On 21/10/2010, at 13.49, Markos Skoulatos wrote: > Dear all, > > we are modeling a cold neutron triple axis spectrometer in McStas (for > the FLEX upgrade in Berlin) and in the last few days I noticed some > unusual behaviour in the complete instrument (consisting of > source--->guides--->velocity selector--->more guides--->doubly > focusing PG monochromator--->V sample--->horizontally curved PG > analyser--->monitors). > The most striking of all is the fact I get negative counts on my > energy monitors, after the sample, for long wavelengths (below ki=1.36 > A^-1) . I initially thought there is something wrong with the V sample > (which still might be the case) until I noticed that the problem > happens when the absolute value of the 2*theta angle of the > monochromator (defined as A2 on this attached instrument) gets greater > than roughly 90 degrees. So perhaps the monochromator has something to > do with this. I tried extensively changing the A4 angle (2-theta angle > of the sample) as well as instrument configurations (ie scattering > senses at sample and analyser) in order to find some values where the > program can run. I failed to make it run for cold wavelengths. > My results for debugging purposes can be summarised as follows: > 1. For ki>1.37 A^-1 things seem to run smoothly > 2. At ki=1.36 A^-1 peaks start going below zero > 3. In the magic range 1.35>ki>1.33 the energy monitors after the > sample and at the detector are negative, however the monitor after the > analyser is positive!! > 4. For ki<1.32 all monitors after the V sample are inverted (negative). > > I attach a picture where you can see what I mean negative counts > (simulation with ~1e7 trajectories). > Has anybody some experience on simulations at colder wavelengths with > monochromator take off angles above 90 degrees or has anyone noticed > these negative counts? Perhaps McStas doesn't like this angle to be > above 90 because then neutrons have a backward direction > (back-scattering)? > Even if I have some mistake in my file I can't see why my program runs > at specific wavelengths (for example ki=1.55 is fine). In any case I > think negative counts should not be there. > > cheers, > Markos Skoulatos > _______________________________________________ > mcstas-users mailing list > mcstas-users at mcstas.org > http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users From skoulatos at gmail.com Fri Oct 22 16:28:28 2010 From: skoulatos at gmail.com (Markos Skoulatos) Date: Fri, 22 Oct 2010 16:28:28 +0200 Subject: [mcstas-users] negative counts and peaks in McStas 1.12b In-Reply-To: <70A66617-644F-412A-AF37-9758F6DCDA67@risoe.dtu.dk> References: <70A66617-644F-412A-AF37-9758F6DCDA67@risoe.dtu.dk> Message-ID: Hi Peter, thank you very much, indeed your suggested workaround works. I checked various wavelengths, especially extreme cases and everything seems fine. Klaus Habicht pointed out another solution which strangely enough still enables one to use focus_xw and focus_yh but the target should be defined as "target_x = ..., target_y = ..., target_z = ..." instead of "target_index = +..." (so it seems to be quite a combination that I managed to set up and get these negative events!) cheers, Markos On Thu, Oct 21, 2010 at 3:09 PM, Peter Willendrup wrote: > Hello Markos, > > > Thanks for pointing this out. > > First of all, you are right: Negative events should never occur! :) > > My feeling is indeed that this relates to V_sample in the sense that this component uses the runtime function randvec_target_rect - which returns a solid-angle multiplier... (Some vector-geometry calculations internal to randvec_target_rect likely has a missing fabs() somewhere...) > > I haven't looked yet, but my guess is that the immediate workaround is to use focus_r instead of focus_rw and focus_yh. > > I will have a closer look and fix this - likely next week... In turn, this likely means another update release, 1.12c... > > Cheers, > > Peter > > > -- > ------------------------------------------------------------------- > Peter Willendrup - Development engineer > > RIS? DTU > Materials Research Division > Frederiksborgvej 399 > DK-4000 Roskilde > > Tlf.: (+45) 4677 5862 > Mobil.: (+45) 2125 4612 > Fax.: (+45) 4766 5758 > Email: pkwi at risoe.dtu.dk > ------------------------------------------------------------------- > > > > On 21/10/2010, at 13.49, Markos Skoulatos wrote: > >> Dear all, >> >> we are modeling a cold neutron triple axis spectrometer in McStas (for >> the FLEX upgrade in Berlin) and in the last few days I noticed some >> unusual behaviour in the complete instrument (consisting of >> source--->guides--->velocity selector--->more guides--->doubly >> focusing PG monochromator--->V sample--->horizontally curved PG >> analyser--->monitors). >> The most striking of all is the fact I get negative counts on my >> energy monitors, after the sample, for long wavelengths (below ki=1.36 >> A^-1) . I initially thought there is something wrong with the V sample >> (which still might be the case) until I noticed that the problem >> happens when the absolute value of the 2*theta angle of the >> monochromator (defined as A2 on this attached instrument) gets greater >> than roughly 90 degrees. So perhaps the monochromator has something to >> do with this. I tried extensively changing the A4 angle (2-theta angle >> of the sample) as well as instrument configurations (ie scattering >> senses at sample and analyser) in order to find some values where the >> program can run. I failed to make it run for cold wavelengths. >> My results for debugging purposes can be summarised as follows: >> 1. For ki>1.37 A^-1 things seem to run smoothly >> 2. At ki=1.36 A^-1 peaks start going below zero >> 3. In the magic range 1.35>ki>1.33 the energy monitors after the >> sample and at the detector are negative, however the monitor after the >> analyser is positive!! >> 4. For ki<1.32 all monitors after the V sample are inverted (negative). >> >> I attach a picture where you can see what I mean negative counts >> (simulation with ~1e7 trajectories). >> Has anybody some experience on simulations at colder wavelengths with >> monochromator take off angles above 90 degrees or has anyone noticed >> these negative counts? Perhaps McStas doesn't like this angle to be >> above 90 because then neutrons have a backward direction >> (back-scattering)? >> Even if I have some mistake in my file I can't see why my program runs >> at specific wavelengths (for example ki=1.55 is fine). In any case I >> think negative counts should not be there. >> >> cheers, >> Markos Skoulatos >> _______________________________________________ >> mcstas-users mailing list >> mcstas-users at mcstas.org >> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users > > > From farhi at ill.eu Fri Oct 29 19:22:37 2010 From: farhi at ill.eu (Emmanuel FARHI) Date: Fri, 29 Oct 2010 19:22:37 +0200 Subject: [mcstas-users] Fwd: neutron focusing optics Message-ID: <4CCB02DD.1020306@ill.eu> Hello dear fellow McStas simulators here is a post-doc position for the McStas amateurs. The proposed mirrors, which have been fabricated, can be used for SANS machines, and are built from concentric cylindrical mirrors. If you are interested, please contact directly the proposers below, and I'll also be able to tell you about new complex geometry features in McStas... Emmanuel FARHI. --- Post?doctoral position in neutron optics research at the MIT Nuclear Reactor Laboratory. MIT has a post?doctoral position available in neutron optics research. Experience and interest in neutron, x?ray, or light optics and instrumentation is an important prerequisite for this position. MIT has a long history of groundbreaking research in neutron science and currently several faculty members are involved in both applications of neutron scattering and neutron instrumentation. Recently neutron beam focusing has been demonstrated by axisymmetric mirror systems based on a pair of mirrors consisting of a confocal ellipsoid and hyperboloid. Such a system, known as a Wolter mirror configuration, is commonly used in x?ray telescopes. This position would emphasize the development of these novel optics for neutron applications such as SANS and imaging, with special interest in improving the performance of SNS instruments. The successful candidate will design and optimize focusing optics for particular neutron instruments, using both ray?tracing simulations and measurements of test mirrors. The design includes modeling and measurements the effects of figure errors and surface roughness. In parallel, the opportunity will exist to engage in an independent neutron research in condensed matter and materials science. The MIT Nuclear Reactor Laboratory has a new neutron spectrometer with an optics test station, which is used in this research program, along with visits to large user facilities. This project is conducted in collaboration with the x?ray optics group at NASA and with scientists at the Spallation Neutron Source. Contact: Dr. Boris Khaykovich bkh at mit.edu Professor David Moncton dem at mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: Postdoc position in neutron optics MIT Oct2010.pdf Type: application/pdf Size: 62678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: From x-rays to neutron mirrors_v8_press-quality.pdf Type: application/pdf Size: 2060504 bytes Desc: not available URL: From erkn at risoe.dtu.dk Fri Nov 5 17:10:05 2010 From: erkn at risoe.dtu.dk (Erik =?UTF-8?B?QmVyZ2LDpGNr?= Knudsen) Date: Fri, 05 Nov 2010 17:10:05 +0100 Subject: [mcstas-users] First release candidate of McXtrace xray tracing software package. Message-ID: <20101105171005.5931a474@idril> Hello everyone, The McXtrace developer team is happy to report that the first official alpha-release, mcxtrace-0.9alpha of our software is finally out. You can get the installer packages from http://download.mcxtrace.org. Installation via the binary distributions for Ubuntu (> =9.10), Mac OS X and Windows is generally recommended. On the Unix-like platforms, the code should peacefully co-exist with McStas - this is known NOT to be the case on Windows. For more information check the wiki at www.mcxtrace.org. Any reports of bugs, problems or indeed successes are much appreciated! Documentation is pending, but under way. The McXtrace component includes 21 components: misc/Progress_bar.comp monitors/E_monitor.comp monitors/L_monitor.comp monitors/PSD_monitor.comp monitors/PSD_monitor_4PI.comp optics/Arm.comp optics/Lens_elliptical.comp optics/Lens_parab.comp optics/Lens_simple.comp optics/Mirror_curved.comp optics/Mirror_elliptic.comp optics/Mirror_parabolic.comp optics/Slit.comp optics/Slit_N.comp samples/Powder_N.comp samples/Saxs_spheres.comp sources/Source_div.comp sources/Source_flat.comp sources/Source_gaussian.comp sources/Source_lab.comp sources/Source_pt.comp On behalf of the McXtrace team, Erik Knudsen -- Erik Bergb?ck Knudsen, Scientist | morituri AFM / Ris? DTU, Po. Box. 49, DK-4000 Roskilde, Denmark | te phone: (+45) 4677 5795, mobile: (+45) 2132 6655 | salutant From zmandelc at hotmail.com Thu Dec 9 16:33:52 2010 From: zmandelc at hotmail.com (chafik driouichi) Date: Thu, 9 Dec 2010 16:33:52 +0100 Subject: [mcstas-users] cross compiling mcstats Message-ID: Hello, I was looking into the possibility of cross-compiling mcstats but when I tried to run : 23057964:~/ess/mcstas-1.12b$ ./configure --prefix=/home/23057964/ess/ --with-cc=arm-none-linux-gnueabi-gcc checking for gcc... arm-none-linux-gnueabi-gcc configure: WARNING: using cross tools not prefixed with host triplet checking for C compiler default output file name... configure: error: in `/home/23057964/ess/mcstas-1.12b': configure: error: C compiler cannot create executables See `config.log' for more details. It seems that I have to set some kind of other variable. Is there somewhere where it describes how to cross-compile before I start digging into the build chain? I'm targeting an ARM architecture. Best regards, /Mandel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkwi at risoe.dtu.dk Fri Dec 10 12:52:51 2010 From: pkwi at risoe.dtu.dk (=?iso-8859-1?Q?Willendrup=2C_Peter_Kj=E6r?=) Date: Fri, 10 Dec 2010 12:52:51 +0100 Subject: [mcstas-users] cross compiling mcstats In-Reply-To: References: Message-ID: <1C341C2B9F4F6C44BE8F15F5EF43CBEB84E8E7@EXCHG-VS1.risoe.dk> Hello there, First of all, interesting that you want to compile for Arm - what is the target device? J (I did actually myself run a McStas simulation on a jailbroken iPhone with a complete gnu toolchain...) Nothing has explicitly/properly been set up for cross-compilation, but you are welcome to inspire from what is done for Win32 in our build script: http://trac.mccode.org/browser/branches/mcstas-1.x/mkdist - . /configure actually never runs, targeting the Win32 platform (most things are handled by platform-defines directly in our ISO C code) but our Linux build-host executes an explicit make target for Windows - from Makefile.in: mcstas.win32: $(COBJECTS) $(MINGW) -o mcstas.exe -DMCSTAS='"C:\\McStas\\lib"' $(CFLAGS) $(LDFLAGS) $(DEFS) $(COBJECTS) -lm $(USE_NEXUS) $(MINGW) -o mcformat.exe -DMCSTAS='"C:\\McStas\\lib"' $(CFLAGS) $(LDFLAGS) $(DEFS) mcformat.c -lm $(USE_NEXUS) Hope this helps, Peter Willendrup From: mcstas-users-bounces at mcstas.org [mailto:mcstas-users-bounces at mcstas.org] On Behalf Of chafik driouichi Sent: 9. december 2010 16:34 To: mcstas-users at mcstas.org Subject: [mcstas-users] cross compiling mcstats Hello, I was looking into the possibility of cross-compiling mcstats but when I tried to run : 23057964:~/ess/mcstas-1.12b$ ./configure --prefix=/home/23057964/ess/ --with-cc=arm-none-linux-gnueabi-gcc checking for gcc... arm-none-linux-gnueabi-gcc configure: WARNING: using cross tools not prefixed with host triplet checking for C compiler default output file name... configure: error: in `/home/23057964/ess/mcstas-1.12b': configure: error: C compiler cannot create executables See `config.log' for more details. It seems that I have to set some kind of other variable. Is there somewhere where it describes how to cross-compile before I start digging into the build chain? I'm targeting an ARM architecture. Best regards, /Mandel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkwi at risoe.dtu.dk Wed Dec 22 13:46:24 2010 From: pkwi at risoe.dtu.dk (pkwi at risoe.dtu.dk) Date: Wed, 22 Dec 2010 13:46:24 +0100 Subject: [mcstas-users] =?iso-8859-1?q?Season=27s_Greetings_from_Ris=F8_DT?= =?iso-8859-1?q?U?= Message-ID: <3EE8BE5416CB410892C94BF0134FCFF5@risoedmz.dk> Hello McStas users, Best wishes and seasonal greetings on behalf of the McStas team. Peter Willendrup Ris? DTU is the National Laboratory for Sustainable Energy. Our research focuses on development of energy technologies and sy- stems with minimal impact on climate, and it contributes to inno- vation, education and policy. Ris? has large experimental facili- ties and interdisciplinary research environments, and includes the national centre for nuclear technologies. Ris? National Laboratory for Sustainable Energy Technical University of Denmark Frederiksborgvej 399 DK-4000 Roskilde Denmark www.risoe.dtu.dk risoe at risoe.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: