From artus at obiwan.kri.physik.uni-muenchen.de Thu Nov 5 18:21:04 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Thu, 05 Nov 1998 18:21:04 +0100 (CET) Subject: First tries using McStas Message-ID: <01J48MCU7VTI8WWAUI@risoe.dk> Dear Kristian, in the last days since our return from Denmark I've installed your program McStas on my machine here. Right now I'm trying to get my first "instrument" running. I have some 'beginners problems' and now allow myself to ask for help. I wanted to simulate a simple straight neutron guide with m=2 for left and right faces and m=3 for top and bottom faces. But the component Guide only allows one kind of coating. It is not quite clear to me from the manual how to build such a guide out of four Mirror components. The manual says that Mirrors can be used to assemble a guide but it says also that a Mirror lies in the xy-plane. Wouldn't one need Mirrors lying parallel to the z-axis to build a guide? May be the use of different coatings within the same guide can be implemented within the Guide component in some future release? To make things easier I tried to set up the instrument with m=2 for all faces. But trying to compile it with McStas ends with: artus at obiwan:/home/artus/mcstas/resi1 > mcstas resi1.instr parse error, expecting `"AT"' at line 37. Errors encountered during parse. artus at obiwan:/home/artus/mcstas/resi1 > The AT is expected in the END line? I cannot find any error in resi1.instr: DEFINE INSTRUMENT RESI1() TRACE COMPONENT a1 = Arm() AT (0,0,0) ABSOLUTE COMPONENT source = Source_flat( radius = 0.050, dist = 2.000, xw = 0.020, yh = 0.060, E0 = 81.804, /* = 1A*/ dE = 1.0) /* =0.99394A - 1.00617A AT (0,0,0) RELATIVE a1 COMPONENT guide1 = Guide( w1 = 0.020 h1 = 0.060 w2 = 0.020 h2 = 0.060 l = 11.500 R0 = 1.0 Qc = 0.0214 alpha = 5.617 m = 2 W = 0.0033) AT (0,0,2) RELATIVE a1 COMPONENT mon = Monitor( xmin = -0.01, xmax = 0.01, ymin = -0.03, ymax = 0.03) AT (0,0,13.5) RELATIVE a1 END What is wrong with the input file? The example files on the CD unfortunately don't contain a Mirror or Guide component for comparison. Furthermore I've tried to use mcdisplay on the example files but this also ends with an error: artus at obiwan:/home/artus/mcstas/example > mcdisplay linup-1.instr Can't locate PGPLOT.pm in @INC (@INC contains: /usr/lib/perl5/i586-linux/5.00404 /usr/lib/perl5 /usr/lib/perl5/site_perl/i586-linux /usr/lib/perl5/site_perl .) at /usr/local/bin/mcdisplay line 6. BEGIN failed--compilation aborted at /usr/local/bin/mcdisplay line 6. artus at obiwan:/home/artus/mcstas/example > I have installed pgplot from the CD. The pgplot examples are running and PGPLOT_DIR="/usr/local/pgplot/"; export PGPLOT_DIR PGPLOT_DEV="/xwin"; export PGPLOT_DEV is added to my .bashrc file. I couldn't find the file PGPLOT.pm anywhere on the harddisk. I also didn't find any information about this in the installation guidelines of pgplot. What is wrong? Thank you very much for your help and best wishes from Garching, Georg ********************************************* Dr. Georg Artus Technische Universit?t M?nchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14018 Fax: +49 (0)89/289-12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Fri Nov 6 09:36:17 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 06 Nov 1998 09:36:17 +0100 Subject: First tries using McStas In-Reply-To: <13889.54936.150165.28077@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: <01J48MDF2ZDK8WWAUI@risoe.dk> > Dear Kristian, > > in the last days since our return from Denmark I've installed your > program McStas on my machine here. Right now I'm trying to get my > first "instrument" running. I have some 'beginners problems' and now allow > myself to ask for help. > I wanted to simulate a simple straight neutron guide with m=2 for left > and right faces and m=3 for top and bottom faces. But the component > Guide only allows one kind of coating. It is not quite clear to me > from the manual how to build such a guide out of four Mirror > components. The manual says that Mirrors can be used to assemble a > guide but it says also that a Mirror lies in the xy-plane. Wouldn't > one need Mirrors lying parallel to the z-axis to build a guide? May be You need to rotate the mirror appropriately. For the top and bottom, rotate around the X axis. For the sides, rotate around the Y axis. (And I need to add this info to the manual!). You must take care to use mirrors that are short enough that each neutron cannot hit a single mirror more than once. This is a simple example (not fully tested): ------------------------------------------------------------------------ /* 4cm by 10cm, 1m long guide build from mirrors. */ COMPONENT guide = Axis() AT (0,0,1.5) RELATIVE source COMPONENT mirrorh1 = Mirror(xlength = 0.04, yheight = 1.00, m = 3, Qc=0.02, W=0.0033, alpha=6.49, R0=1) AT (-0.02,-0.05,0) RELATIVE guide ROTATED (90,0,0) RELATIVE guide COMPONENT mirrorh2 = Mirror(xlength = 0.04, yheight = 1.00, m = 3, Qc=0.02, W=0.0033, alpha=6.49, R0=1) AT (-0.02,0.05,0) RELATIVE guide ROTATED (90,0,0) RELATIVE guide COMPONENT mirrorv1 = Mirror(xlength = 1.00, yheight = 0.1, m = 2, Qc=0.02, W=0.0033, alpha=6.49, R0=1) AT (-0.02,-0.05,0) RELATIVE guide ROTATED (0,90,0) RELATIVE guide COMPONENT mirrorv2 = Mirror(xlength = 1.00, yheight = 0.1, m = 2, Qc=0.02, W=0.0033, alpha=6.49, R0=1) AT (0.02,-0.05,0) RELATIVE guide ROTATED (0,90,0) RELATIVE guide ------------------------------------------------------------------------ > the use of different coatings within the same guide can be implemented > within the Guide component in some future release? I have added it on my "ToDo" list. You might want to try modifying the guide component yourself, it should not be difficult. What you need to do is: 1. Copy the file "Guide.comp" into your directory as "Guide2.comp" and edit the new file as follows: 2. Change the name of the component from "Guide" to "Guide2": DEFINE COMPONENT Guide2 3. Replace the "m" definition parameter with two others, "mh" and "mv": DEFINITION PARAMETERS (w1, h1, w2, h2, l, R0, Qc, alpha, mh, mv, W) 4. Look in the calculations to see that the variable "i" is set to 1 or 2 for intersection with vertical mirrors, and 3 or 4 for horizontal mirrors. Now find the calculation of the reflectivity and change it to use mv if i <= 2, and mh otherwise: double arg = (q - (i <= 2 ? mv : mh)*Qc)/W; That should be all! You can now use "Guide2" instead of "Guide" using "mh" and "mv" for horizontal and vertical m-value. I have put up a version of Guide with these modifications on the Web server that you may download from http://elu-alf-2.risoe.dk/~elu-krni/mcstas/support/misc/Guide2.comp > To make things easier I tried to set up the instrument with m=2 for > all faces. But trying to compile it with McStas ends with: > > artus at obiwan:/home/artus/mcstas/resi1 > mcstas resi1.instr > parse error, expecting `"AT"' at line 37. > Errors encountered during parse. > artus at obiwan:/home/artus/mcstas/resi1 > > > The AT is expected in the END line? > I cannot find any error in resi1.instr: The reason for the strange error message is that you have an unterminated comment: > dE = 1.0) /* =0.99394A - 1.00617A here -> ^^^ So the rest of the file is just a comment as far as McStas is concerned :-( Once you fix this, you also need to separate the arguments to "Guide" with commas: > COMPONENT guide1 = Guide( > w1 = 0.020 > h1 = 0.060 > w2 = 0.020 > h2 = 0.060 > l = 11.500 > R0 = 1.0 > Qc = 0.0214 > alpha = 5.617 > m = 2 > W = 0.0033) > AT (0,0,2) RELATIVE a1 This should be COMPONENT guide1 = Guide( w1 = 0.020, h1 = 0.060, w2 = 0.020, h2 = 0.060, l = 11.500, R0 = 1.0, Qc = 0.0214, alpha = 5.617, m = 2, W = 0.0033) AT (0,0,2) RELATIVE a1 > Furthermore I've tried to use mcdisplay on the example files but this > also ends with an error: > > artus at obiwan:/home/artus/mcstas/example > mcdisplay linup-1.instr > Can't locate PGPLOT.pm in @INC (@INC contains: /usr/lib/perl5/i586-linux/5.00404 /usr/lib/perl5 /usr/lib/perl5/site_perl/i586-linux /usr/lib/perl5/site_perl .) at /usr/local/bin/mcdisplay line 6. > BEGIN failed--compilation aborted at /usr/local/bin/mcdisplay line 6. > artus at obiwan:/home/artus/mcstas/example > You need to also install PgPerl, which is an interface that allows perl programs to use pgplot. PgPerl is included on the CD in the file external/PGPLOT-2.11.tar.gz > Thank you very much for your help and You are welcome! If you have any further questions, just mail me again and I will do my best to help. - Kristian. From agarrett at ccbsf0.kek.jp Tue Nov 10 07:37:23 1998 From: agarrett at ccbsf0.kek.jp (Andrew Garrett) Date: Tue, 10 Nov 1998 15:37:23 +0900 Subject: MCStas Message-ID: <01J48MDP2CR88WWAUI@risoe.dk> Kristian, As we'd discussed during the conference, I've been trying to get MCStas running under windows. I'm having a problem... The problem occurs in the yyparse function in instrume.c. This is the bison parser, and I'm having some trouble isolating the problem. My best guess at the moment is all the #line x "/usr/share/misc/bison.simple" since that file doesn't actually exist on my machine (OK, it's not the most difficult guess in the world). Do you know what that file is? Or where I can find a copy, preferably windows compatible? As to other changes that have been required, most have revolved around the file system, changing the separator '/' to '\'. Also, I had to declare the variable read_components in mcstas.h as extern, or I got an error for this being declared in every file. I'm not sure if that will cause problems down the road - was that defined anywhere else? Thanks for your help, Andrew Garrett From kristian.nielsen at risoe.dk Tue Nov 10 13:20:27 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Tue, 10 Nov 1998 13:20:27 +0100 Subject: MCStas In-Reply-To: <3647DF23.2326806C@ccbsf0.kek.jp> (message from Andrew Garrett on Tue, 10 Nov 1998 15:37:23 +0900) Message-ID: <01J48MDVMEAO8WWAUI@risoe.dk> > Kristian, > > As we'd discussed during the conference, I've been trying to get > MCStas running under windows. I'm having a problem... > > The problem occurs in the yyparse function in instrume.c. This is the > bison parser, and I'm having some trouble isolating the problem. My > best guess at the moment is all the > #line x "/usr/share/misc/bison.simple" > since that file doesn't actually exist on my machine (OK, it's not the > most difficult guess in the world). Do you know what that file is? Or > where I can find a copy, preferably windows compatible? This file is not related to your problem. The #line bit just tells your C compiler that the following code was copied from a file of that name, so that error messages can refer to the original file. You can safely delete all the #line's, but that is unlikely to make any difference. You do not give much information, perhaps you could send me the exact error message of the compiler (and perhaps also information on what compiler you are using)? As far as I know, with Microsoft visual C two problems occur, both in the linker phase. One is a missing strcasecmp() function and one is a missing alloca() function. I believe you can solve this by replacing strcasecmp() with stricmp() (or plain strcmp() if stricmp also does not work); and by having the compiler define the preprocessor symbol MSDOS (or put the line '#define MSDOS 1' in mcstas.h). > As to other changes that have been required, most have revolved around > the file system, changing the separator '/' to '\'. Also, I had to Yes. > declare the variable read_components in mcstas.h as extern, or I got an > error for this being declared in every file. I'm not sure if that will > cause problems down the road - was that defined anywhere else? Yes, this is a bug! I have fixed it in my source, it wil be in the next version. > Thanks for your help, You are welcome. Let me know what you find; once we get it working you should send me your changes so that the next version of McStas works with Windows. - Kristian. From agarrett at ccbsf0.kek.jp Wed Nov 11 07:48:40 1998 From: agarrett at ccbsf0.kek.jp (Andrew Garrett) Date: Wed, 11 Nov 1998 15:48:40 +0900 Subject: MCStas References: <01J40DBKDGAY91WAMR@risoe.dk> Message-ID: <01J48MEEUH2G8WWAUI@risoe.dk> Kristian, OK, this is coming along, well, sort of... MCStas is now opening and reading files properly, and the problem seems to be in mem... I've turned on verbose parser, and here are the last couple of lines that are coming out. Reducing via rule 25 (line 286), "COMPONENT" TOK_ID '=' TOK_ID actuallist place orientation -> component state stack now 0 2 5 7 11 15 22 34 45 54 58 61 Entering state 64 Reducing via rule 24 (line 279), complist component -> complist state stack now 0 2 5 7 11 15 22 34 45 54 58 Entering state 61 Reading a token: Next token is 262 ("COMPONENT") Shifting token 262 ("COMPONENT"), Entering state 63 Reading a token: Next token is 278 (TOK_ID) Shifting token 278 (TOK_ID), Entering state 66 Reading a token: Next token is 61 ('=') Shifting token 61 ('='), Entering state 67 Reading a token: Next token is 278 (TOK_ID) Shifting token 278 (TOK_ID), Entering state 68 Reading a token: Next token is 40 ('(') Shifting token 40 ('('), Entering state 69 Reading a token: Next token is 41 (')') Reducing via rule 32 (line 348), -> actuals Fatal error: memory exhausted during allocation of size 8000. Program aborted. The machine I'm using has 32 MB RAM, and I'm wondering if this is enough. I have not yet traced the memory handling all that well, I'll admit - and with DOS's insistence on stack vs. heap memory use, it is possible that I can fix this by playing around with the mem functions. Still, how much memory do you have on your machines, and do you have any measurement of how much you need? Thanks, Drew Garrett From kristian.nielsen at risoe.dk Wed Nov 11 14:56:38 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Wed, 11 Nov 1998 14:56:38 +0100 Subject: MCStas In-Reply-To: <36493348.BCF0DE3B@ccbsf0.kek.jp> (message from Andrew Garrett on Wed, 11 Nov 1998 15:48:40 +0900) Message-ID: <01J48MENXNQC8WWAUI@risoe.dk> > Fatal error: memory exhausted during allocation of size 8000. > > Program aborted. > > > The machine I'm using has 32 MB RAM, and I'm wondering if this is enough. I have > not yet traced the memory handling all that well, I'll admit - and with DOS's > insistence on stack vs. heap memory use, it is possible that I can fix this by > playing around with the mem functions. Still, how much memory do you have on your > machines, and do you have any measurement of how much you need? Hm, this sounds as if you are compiling in dos mode? In that case you are probably running up against the 64Kb limitation. I think you will need to compile McStas for 32 bit. Anyway, I just got Rene Moeller to help me compile mcstas for Windows 95/NT. This is compiled as a 32bit console application, so there should be no memory problems. You can download it from this URL: http://ELU-ALF-2.risoe.dk/~elu-krni/mcstas/support/misc/mcstas.exe To use it, you need to set the environment variable MCSTAS to point to the "lib" subdirectory of the mcstas distribution, eg: set MCSTAS=C:\mcstas\lib Let me know if it works so that I can make a proper Windows release of McStas. - Kristian. From agarrett at ccbsf0.kek.jp Tue Nov 10 22:56:20 1998 From: agarrett at ccbsf0.kek.jp (Andrew Garrett) Date: Wed, 11 Nov 1998 06:56:20 +0900 Subject: MCStas References: <01J40DBKDGAY91WAMR@risoe.dk> Message-ID: <01J48MF1N4SG8WWAUI@risoe.dk> Kristian, Thanks for getting back to me so quickly, I'd like to get this working. Pity it wasn't the #line comments, I had high hopes for that being it, since it looked fairly easy to fix... One mis-communication, though. I don't have a compiler error, the program compiles just fine (under Boorland C++ 4.52, BTW) I had to replace the srtcasecmp statements, but can handle alloca without any problems. The problem comes when I run the program, calling MCStas with an instrument file - I'm using linup-1, from your examples directory, renamed linup1.ins to avoid long name problems. I get an "illegal operation error" after starting the program, nothing more specific than that, I'm afraid. By inserting printf's into the main program, I've been trying to track down where this occurs. In general, but not always, the program gets to the line in main(), 'err = yyparse();' I cannot get the program to compile if I put printf's inside yyparse() though. When seraching for the component, it does make one call to try_open_component, and tries to find a file with a .comp extension, but then it fails after that, without making a second call. I'm still working on this, and will keep you informed. If you've got any ideas, please let me know. Thanks, Andrew Garrett > This file is not related to your problem. The #line bit just tells your > C compiler that the following code was copied from a file of that name, > so that error messages can refer to the original file. You can safely > delete all the #line's, but that is unlikely to make any difference. > > You do not give much information, perhaps you could send me the exact > error message of the compiler (and perhaps also information on what > compiler you are using)? > > As far as I know, with Microsoft visual C two problems occur, both in > the linker phase. One is a missing strcasecmp() function and one is a > missing alloca() function. I believe you can solve this by replacing > strcasecmp() with stricmp() (or plain strcmp() if stricmp also does not > work); and by having the compiler define the preprocessor symbol MSDOS > (or put the line '#define MSDOS 1' in mcstas.h). > > > As to other changes that have been required, most have revolved around > > the file system, changing the separator '/' to '\'. Also, I had to > > Yes. > > > declare the variable read_components in mcstas.h as extern, or I got an > > error for this being declared in every file. I'm not sure if that will > > cause problems down the road - was that defined anywhere else? > > Yes, this is a bug! I have fixed it in my source, it wil be in the next version. > > > Thanks for your help, > > You are welcome. Let me know what you find; once we get it working you > should send me your changes so that the next version of McStas works > with Windows. > > - Kristian. From agarrett at ccbsf0.kek.jp Thu Nov 12 03:46:40 1998 From: agarrett at ccbsf0.kek.jp (Andrew Garrett) Date: Thu, 12 Nov 1998 11:46:40 +0900 Subject: Windows McStas Message-ID: <01J48MF7LNWU8WWAUI@risoe.dk> Kristian, Thanks for the mail, and the link to the executable. I couldn't get the executable you supplied to run - well, it ran, but it couldn't find the components... But, with the hint you provided about compiling in 32 bit mode, I did get it to work. I'm guessing that the version you provided was still using forward slashes to separate directories, but maybe not... Anyway, I've got a working version. Now, problem 2. The output code from McStas has a problem, at least when compiling under DOS/Windows. It's a 1-line problem, but it does need to be fixed. The output code calls mcparseoptions from mcstas_main. In mcparseoptions, the first command is to allocate memory of 'mcnumipar * size...' I'm not too sure how mcnumipar is set, but when I ran this, it was set to 0. This is a problem, because the very next line checks to see if the memory was allocated, and ends the program if it was not. And, in DOS/Windows, memory allocation returns NULL if set to a size of 0. The simple fix is to change that line to say 'if (paramsetarray == NULL && mcnumipar != 0)' Then everything works fine. I'm just not sure where that's written from in the original MCStas. Thanks again for your help, Drew Garrett From kristian.nielsen at risoe.dk Thu Nov 12 08:41:39 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Thu, 12 Nov 1998 08:41:39 +0100 Subject: Windows McStas In-Reply-To: <364A4C0F.95DF1B11@ccbsf0.kek.jp> (message from Andrew Garrett on Thu, 12 Nov 1998 11:46:40 +0900) Message-ID: <01J48MFA273G8WWAUI@risoe.dk> > Thanks for the mail, and the link to the executable. I couldn't get > the executable you supplied to run - well, it ran, but it couldn't find > the components... But, with the hint you provided about compiling in 32 > bit mode, I did get it to work. I'm guessing that the version you > provided was still using forward slashes to separate directories, but > maybe not... Anyway, I've got a working version. The slashes should be ok (at least it worked for us ...). Probably the MCSTAS environment variable was not set correctly for you? Anyway, you got a working version, I assume you set the correct path for MC_SYS_DIR in the source when you fixed the forward/back slashes issue? > The output code calls mcparseoptions from mcstas_main. In > mcparseoptions, the first command is to allocate memory of 'mcnumipar * > size...' I'm not too sure how mcnumipar is set, but when I ran this, it > was set to 0. This is a problem, because the very next line checks to > see if the memory was allocated, and ends the program if it was not. > And, in DOS/Windows, memory allocation returns NULL if set to a size of > 0. Ah, another bug ... thanks for pointing that out. The mcnumipar variable is set to the number of instrument parameters (the list in "DEFINE INSTRUMENT name (...)" in the instrument definition). If the instrument has no parameters, it will be zero as you observed. > The simple fix is to change that line to say 'if (paramsetarray == > NULL && mcnumipar != 0)' Then everything works fine. I'm just not sure > where that's written from in the original MCStas. This code comes from the file "mcstas-r.c" in the "lib" subdirectory. I will fix this in the next version. - Kristian. From artus at obiwan.kri.physik.uni-muenchen.de Mon Nov 9 10:27:19 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Mon, 09 Nov 1998 10:27:19 +0100 (CET) Subject: First tries using McStas In-Reply-To: <01J3UKC887U291VR91@risoe.dk> References: <13889.54936.150165.28077@obiwan.kri.physik.uni-muenchen.de> <01J3UKC887U291VR91@risoe.dk> Message-ID: <01J48MFUP7PE8WWAUI@risoe.dk> Hello Kristian, thank you for your last mail and the first aid! I'm still tryping to get mcdisplay running but something is still missing. I've installed all packages (from the CD: PGPLOT, PDL, FLEX). Preinstalled with the Linux system were PERL5.00404 and the Bison parser. Now calling mcdisplay ends with artus at obiwan:/home/artus/mcstas/example > mcdisplay linup-1 Unquoted string "pgbbuf" may clash with future reserved word at /usr/local/bin/mcdisplay line 212. Unquoted string "pgpage" may clash with future reserved word at /usr/local/bin/mcdisplay line 239. Unquoted string "pgebuf" may clash with future reserved word at /usr/local/bin/mcdisplay line 241. Useless use of a constant in void context at /usr/local/bin/mcdisplay line 212. Useless use of a constant in void context at /usr/local/bin/mcdisplay line 239. Useless use of a constant in void context at /usr/local/bin/mcdisplay line 241. Unquoted string "pgend" may clash with future reserved word at /usr/local/bin/mcdisplay line 293. Useless use of a constant in void context at /usr/local/bin/mcdisplay line 293. Undefined subroutine &main::pgbegin called at /usr/local/bin/mcdisplay line 261. artus at obiwan:/home/artus/mcstas/example > What is this? I should mention that unfortunately I 'speak' neither perl nor C. Best wishes, Georg From artus at obiwan.kri.physik.uni-muenchen.de Tue Nov 10 14:53:26 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Tue, 10 Nov 1998 14:53:26 +0100 (CET) Subject: First tries using McStas In-Reply-To: <01J3UKC887U291VR91@risoe.dk> References: <13889.54936.150165.28077@obiwan.kri.physik.uni-muenchen.de> <01J3UKC887U291VR91@risoe.dk> Message-ID: <01J48MFYKOXA8WWAUI@risoe.dk> Hello Kristian, using xour component Guide2 for different coatings for left/right and top/bottom faces of a guide I have now a first set up which could be compared to a calculation with the program Beamline written by Jeremy Cook. Beamline is able to compute absolute fluxes. Is there any possibility to calculate absolute fluxes with McStas? Another possible comparison is the transmission. Within Beamline, the transmission is the number of neutrons detected divided by the number of neutrons entering the first guide section. To calculate an "equivalent" transmission with the output of McStas I divided the value mon_I by the solid angle at the source and divided the resulting value by the number of started neutrons. Is that correct? At the moment I'm trying to compare the profiles. Unfortunately we don't have MATLAB so I need a workaround. The spatial distribution of neutrons at the detector is no problem. How can I get the angular distribution with McStas? Best regards, Georg From kristian.nielsen at risoe.dk Thu Nov 12 15:13:27 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Thu, 12 Nov 1998 15:13:27 +0100 Subject: First tries using McStas In-Reply-To: <13896.13203.557267.61539@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: <01J48MG2AFLS8WWAUI@risoe.dk> Hi Georg, > using your component Guide2 for different coatings for left/right and > top/bottom faces of a guide I have now a first set up which could be > compared to a calculation with the program Beamline written by Jeremy Cook. Great! > Beamline is able to compute absolute fluxes. Is there any possibility > to calculate absolute fluxes with McStas? Yes, computing absolute fluxes is possible. The tricky part is to get the units right.Ian Anderson from ILL was here a couple of days before the Workshop. Together we set up a simple simulation of the in14 instrument at ILL and computed the absolute flux at the sample position. As the unit of measure for the flux at the source we use number of neutrons per square cm per solid angle in steradians per wavelength in Aangstroem: n/(cm*cm*st*AA). The component Source_flat models a source that emits N neutrons in the full 4PI solid angle, where N is the number of neutron histories simulated. Therefore, if delta_lambda is the range of wavelengths emitted from the source in AA and r is the radius of the source in cm, we can compute the total flux of the source simulated by McStas as follows: flux = N / (PI*r*r * 4PI * delta_lambda) To compare with another source of flux flux', the intensities in the detector computed by McStas should be multiplied by the factor (flux'/flux). Together with Ian I modified the Source_flat component to compute this factor, but it still needs some polishing. I will look at it and send it to you when it is ready. Note that the intensity in detectors in McStas is the sum of the statistical weights of incident neutrons. The actual number of neutron histories that reach the detector is not very meaningfull because of inportance sampling etc. > Another possible comparison is the transmission. Within Beamline, > the transmission is the number of neutrons detected divided by the > number of neutrons entering the first guide section. To calculate an > "equivalent" transmission with the output of McStas I divided the > value mon_I by the solid angle at the source and divided the resulting > value by the number of started neutrons. Is that correct? It would probably be simpler to place one monitor at the guide entrance and one at the exit. The transmission is then the ratio between the intensities in the two monitors, mon2_I/mon1_I. The monitor at the entrance must have the same dimensions as the guide opening, of course. You will probably also want to compare the formula for mirror reflectivity that McStas uses (page 30 in the manual) with the one used in your program. If they are different it might be difficult to compare results directly. > At the moment I'm trying to compare the profiles. Unfortunately we > don't have MATLAB so I need a workaround. The spatial distribution of > neutrons at the detector is no problem. How can I get the angular > distribution with McStas? You can use the angular divergence detector that Kim Lefmann just wrote today (for a simulation of our RITA spectrometer). It computes the intensity as a function of angular divergence. I have put it on our Web Page at the URL http://elu-alf-2.risoe.dk/~elu-krni/mcstas/support/misc/Divergence_monitor.comp > missing. I've installed all packages (from the CD: PGPLOT, PDL, I am a bit confused here. You say that you installed PGPLOT. Did you install both pgplot5.2.tar.gz and PGPLOT-2.11.tar.gz? Both are needed for mcdisplay to work. Btw, for pgplot5.2.tar.gz, the optional C bindings must also be installed. There should be a file "cpgdemo" that correctly displays a few graphs when run. When you install PGPLOT-2.11.tar.gz, after running "make", running "make test" should correctly display some simple examples in a window. > Unquoted string "pgend" may clash with future reserved word at /usr/local/bin/mcdisplay line 293. > Useless use of a constant in void context at /usr/local/bin/mcdisplay line 293. > Undefined subroutine &main::pgbegin called at /usr/local/bin/mcdisplay line 261. > artus at obiwan:/home/artus/mcstas/example > This looks as if the PGPLOT calls (pgend, pgbegin and so on) are not recognized by perl. This is a bit strange, given that perl apparently now does find the pgplot <-> perl interface file "PGPLOT.pm". In your first mail, you wrote that perl failed to find this file: > Can't locate PGPLOT.pm in @INC (@INC contains: > /usr/lib/perl5/i586-linux/5.00404 /usr/lib/perl5 > /usr/lib/perl5/site_perl/i586-linux /usr/lib/perl5/site_perl .) at > /usr/local/bin/mcdisplay line 6. > BEGIN failed--compilation aborted at /usr/local/bin/mcdisplay line 6. I assume that installing the PGPLOT-2.11.tar.gz package fixed this? Anyway, it appears that it did not install properly. When you installed PGPLOT-2.11.tar.gz, did the "make test" command run correctly and display a window? If I remove the "use PGPLOT;" line at the top of the mcdisplay file, I get the exact same error messages you do. Did you by any chance modify the mcdisplay file? It is a bit unfortunate that getting the graphics runnig is so difficult. Especially since future versions of McStas will have much better graphics. If you are able to give me a login account on your machine and want me to help, I can log in remotely and try to find out what the problem is. Hope this helps, - Kristian. From anderson at ill.fr Fri Nov 13 09:56:30 1998 From: anderson at ill.fr (Ian Anderson) Date: Fri, 13 Nov 1998 09:56:30 +0100 (MET) Subject: Absolute intensities and McStas In-Reply-To: <01J43BDVBEGU91WTRJ@risoe.dk> Message-ID: <01J48MGIU8EE8WWAUI@risoe.dk> Hi Kristian, Thanks for your MAIL. I am a little confused. Am I right in supposing that you have assumed a source flux which is constant with energy? If so what was the flux? Best wishes, Ian ____________________________________________________________________________ Ian Anderson _/ _/ _/ Head, Neutron Optics Lab. _/ _/ _/ Institut Laue-Langevin _/ _/ _/ B.P.156 _/ _/ _/ 38042 Grenoble Cedex 9 _/ _/_/_/_/ _/_/_/_/ France Telephone:(33) 4 76 20 71 37; Fax:(33) 4 76 20 77 00; email: anderson at ill.fr http://www.ill.fr/ ____________________________________________________________________________ From kristian.nielsen at risoe.dk Fri Nov 13 12:15:35 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 13 Nov 1998 12:15:35 +0100 Subject: Absolute intensities and McStas In-Reply-To: (message from Ian Anderson on Fri, 13 Nov 1998 09:56:30 +0100 (MET)) Message-ID: <01J48MGR1BOQ8WWAUI@risoe.dk> > Hi Kristian, > > Thanks for your MAIL. I am a little confused. Am I right in supposing that > you have assumed a source flux which is constant with energy? If so what > was the flux? Yes, the flux is constant with energy, with a value of 10^13 neutrons/(cm^2 * st * AA). I basically re-ran the example we did together before the workshop. The main message here is that the results we got then were a factor of two too low because we used the wrong value for the width of the energy distribution of the source component. Thus the results agree much better with experiments than we thought. It is also a good lesson in how important the correctness aspect of simulation is! I now have some ideas for how to model absolute intensities in a useful way. What I will do is to make a source component that takes as input a tabulation of the flux as a function of energy. The component will then set the initial neutron weights so that computed intensities will be absolute. - Kristian. From kristian.nielsen at risoe.dk Thu Nov 12 15:50:23 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Thu, 12 Nov 1998 15:50:23 +0100 Subject: First tries using McStas In-Reply-To: <13896.13203.557267.61539@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: <01J48MII7TIC8WWAUI@risoe.dk> Hi Georg, I finished the modified Source component and put it on the following URL: http://elu-alf-2.risoe.dk/~elu-krni/mcstas/support/misc/Source_flux.comp It is similar to the Source_flat component, but takes an extra parameter 'flux': the absolute flux of the source in neutrons per cm^2 per AA per steradian. It sets the initial weight of neutrons so that the intensities in detectors computed by McStas model absolute intensities. - Kristian. From artus at obiwan.kri.physik.uni-muenchen.de Thu Nov 12 16:38:18 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Thu, 12 Nov 1998 16:38:18 +0100 (CET) Subject: First tries using McStas In-Reply-To: <01J439UDU9W891WTRJ@risoe.dk> References: <13896.13203.557267.61539@obiwan.kri.physik.uni-muenchen.de> <01J439UDU9W891WTRJ@risoe.dk> Message-ID: <01J48P0X9N4M8WWBMB@risoe.dk> Hello Kristian, thanks for this huge amount of information! I'll try to use the new source and the new detector as soon as possible. Now to the problem with the graphics. I have to confess that I didn't realize that both PGPLOT packages are necessary! I thought it were just a newer and an older version (Sorry!). So I just tried to install 2.11 but 'make' stops with an error: make: *** [PGPLOT.c] Error 139 ?? Is the order of installation of the PGPLOT packages important? 'perl Makefile.PL' seems to be ok: obiwan:/usr/local/PGPLOT-2.11 # perl Makefile.PL Found compiler g77 ExtUtils::F77: Using system=Linux compiler=G77 Checking for gcc in disguise Compiler is gcc version 2.7.2.1ExtUtils::F77: Validating -L/usr/lib -L/usr/lib -lf2c -lm -L/usr/lib/gcc-lib/i686-pc-linux-gnulibc1/2.8.1 -lgcc [ok] ExtUtils::F77: Compiler: g77 ExtUtils::F77: Cflags: -O Checking if your kit is complete... Looks good Writing Makefile for PGPLOT Back to the guides: Following Murphy's law I interchanged the m's describing the different reflectivity for the faces within Guide2.comp! We here used the 'convention', that the side faces are connected to the HORIZONTAL path of the neutrons and therefor we use mh for the side faces. You use the terminology vice versa as I now assume? We ran across this problem earlier here and now we always talk of top and bottom and left and right to avoid misunderstandings... May be this is worth noticing in the future documentation of Guide2. > It would probably be simpler to place one monitor at the guide entrance and one at the exit. The transmission is then the ratio between the intensities in the two monitors, mon2_I/mon1_I. The monitor at the entrance must have the same dimensions as the guide opening, of course. Placing a monitor in front of the guide in fact is a good idea. Dividing the final sum of weights by (solid angle at source * 4pi) also gives the same as long as you assign xw and yh for Source_flat to the size of the guide entrance. I was a little bit astonished, that your slope alpha to describe the reflectivity for mirrors is positive? Beamline uses a slightly simpler way to describe the reflectivity. The only(?) difference is, that it doesn't model the sigmoid decay to reflectivity 0. It just uses a cutoff. But according to the numbers, this difference is negligible (if I didn't make any mistake): Guide Transmissions(%) McStas Beamline A 1.52 1.57 B 2.84 2.91 A: straight guide, 20x60, TB: m=3, LR: m=2, 11.5m long, 2 gaps B: focussing guide 40x85 -> 20x60, TB: m=3, LR: m=2, 11.5m long, 2 gaps I have also calculated three guides (straight section + diverging section, focussing guide, straight guide, m's = 1 and 3) for Ralph (he was also at the meeting) but I don't have his transmissions for beamline. But I remember that the numbers were also very close! Also all profiles looked absolutely the same! Have a nice evening, Georg From kim.lefmann at risoe.dk Mon Nov 16 12:15:20 1998 From: kim.lefmann at risoe.dk (Kim Lefmann) Date: Mon, 16 Nov 1998 12:15:20 +0100 (MET) Subject: Divergence_monitor Message-ID: <01J48P1P5UZI8WWBMB@risoe.dk> Hi Georg, I am glad to hear that you are working on McStas. I hope that you have had good progress in the past two weeks. I have included a preliminary manual entry for the component. This will answer one of you questions. The question about the coupling between the position and divergence I do not understand fully: Of cource if you illuminate a plane with a point source, there will be a correlation between the position and divergence (to take a simple example), but the detector does not care about that, it simply calculates the angle between the neutron path and the detector normal, whereever the neutron intersects this plane. Good luck with your simulations, Kim ----------------------------- The divergence sensitive monitor The component Divergence_monitor is a rectangular single monitor with an opening in the x-y plane, which is sensitive to the neutron divergence, i.e. the angle between the neutron path and the monitor surface normal. The divergence is divided into horisontal and vertical divergencies, which are calculated as h_div = atan(vx/vz) and v_div = atan(vy/vz), respectively. Only neutrons within a divergence window of h_div = (-h_maxdiv ; h_maxdiv), v_div = (-v_maxdiv ; v_maxdiv) are detected. The counts are binned in an array of nh x nv pixels. The input parameters for Divergence_monitor are the opening coordinates (xmin, xmax, ymin, ymax), the number of pixels (nh, nv), the parameters h_maxdiv, v_maxdiv defining the divergence interval, and a name of the file in which to store the detected intensities. Note that a divergence sensitive monitor with a small opening may be thought of as a non-reversing pinhole camera. From kim.lefmann at risoe.dk Wed Nov 18 10:01:52 1998 From: kim.lefmann at risoe.dk (Kim Lefmann) Date: Wed, 18 Nov 1998 10:01:52 +0100 (MET) Subject: Divergence_monitor Message-ID: <199811180901.KAA16964@fys-hp-1.risoe.dk> ------------- Begin Forwarded Message ------------- >From artus at obiwan.kri.physik.uni-muenchen.de Tue Nov 17 14:55:12 MET 1998 Received: from risvm1.risoe.dk (risvm1.risoe.dk [130.226.48.29]) by fys-hp-1.risoe.dk with ESMTP (8.7.6/8.7.1) id OAA12098 for ; Tue, 17 Nov 1998 14:55:11 +0100 (MET) From: artus at obiwan.kri.physik.uni-muenchen.de Received: from CONVERSION-DAEMON by risoe.dk (PMDF V5.1-10 #28173) id <01J4A8O5A40G8WWMC4 at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 17 Nov 1998 14:55:04 +0100 Received: from obiwan.kri.physik.uni-muenchen.de by risoe.dk (PMDF V5.1-10 #28173) with ESMTP id <01J4A8NR37I28WWMAE at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 17 Nov 1998 14:55:02 +0100 Received: (from artus at localhost) by obiwan.kri.physik.uni-muenchen.de (8.8.8/8.8.8) id OAA02707; Tue, 17 Nov 1998 14:52:11 +0100 Date: Tue, 17 Nov 1998 14:52:10 +0100 (CET) Subject: Re: Divergence_monitor In-reply-to: <199811161115.MAA24308 at fys-hp-1.risoe.dk> To: Kim Lefmann Message-id: <13905.31696.424448.866476 at obiwan.kri.physik.uni-muenchen.de> MIME-version: 1.0 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <199811161115.MAA24308 at fys-hp-1.risoe.dk> Content-Length: 1619 Status: RO Hello Kim, thank you for the quick answer! > I am glad to hear that you are working on McStas. I hope that you have had good progress in the past two weeks. Thanks, I have to say yes! The system is easy to use as soon as you got used to it. And getting used to McStas took less then a week which is not much regarding the complexity of the matter! So keep up the good work! I also have to confess that I still cannot use the graphics because the installation of PGPLOT makes some trouble I don't understand. > The question about the coupling between the position and divergence I do not understand fully: Of cource if you illuminate a plane with a point source, there will be a correlation between the position and divergence (to take a simple example), but the detector does not care about that, it simply calculates the angle between the neutron path and the detector normal, whereever the neutron intersects this plane. Ok, this answers my second question. I was thinking of the following: We have a rather short neutron guide (11.5m) with rather short wavelengths. So we don't expect a really isotropical angular and spatial distribution of neutrons at the end of the guide. There should be a large correlation between the angle of the neutrons trajectory and the coordinates, where the neutron hits the detector. And that of course is important for the further optics! This is why I thought of a more complex detector, which gives you the angular distribution depending on the coordinates. But I can approximate such a detector by using several neighboured divergence_monitors. Best wishes, Georg ------------- End Forwarded Message ------------- From artus at obiwan.kri.physik.uni-muenchen.de Thu Nov 19 13:35:00 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Thu, 19 Nov 1998 13:35:00 +0100 (CET) Subject: First tries using McStas In-Reply-To: <01J43B55T2N691WTRJ@risoe.dk> References: <13896.13203.557267.61539@obiwan.kri.physik.uni-muenchen.de> <01J43B55T2N691WTRJ@risoe.dk> Message-ID: <01J4D2IK5C1Y8WX1AN@risoe.dk> Hello Kristian, I'm making good progress with my calculations. Good in a sense, that I hope to be quite familiar with McStas now. 'Bad' in a sense, that the results already led to some changes to the instrument and we have a lot more work to do now... I have a small suggestion for the next version of McStas: It would be nice to get a rough estimate on the total calculation time needed at the beginning of any job. It should be no problem estimating the time for the calculation of 1E+8 neutrons after having calculated the first 100 neutrons. A short note on the screen would be nice. Did I tell you about the difference in the angular profiles between beamline and McStas at the end of the tapered guide? Beamline gives me a rather regular profile, while McStas calculates some extra maxima at about 11 minutes of arc (looks like Batman). The difference is not extreme but large enough to again think about the guide. I should send you the files if you want to have a look at them. I don't know what to do about the PGPLOT problem. May I refer to your offer of giving you an account here? Best wishes, Georg From kristian.nielsen at risoe.dk Thu Nov 19 15:35:30 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Thu, 19 Nov 1998 15:35:30 +0100 Subject: First tries using McStas In-Reply-To: <13908.3056.33799.267080@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: <01J4D2NZNT5M8WX1AN@risoe.dk> > I have a small suggestion for the next version of McStas: It would be > nice to get a rough estimate on the total calculation time needed at > the beginning of any job. It should be no problem estimating the time > for the calculation of 1E+8 neutrons after having calculated the > first 100 neutrons. A short note on the screen would be nice. Sounds like a good idea, I will make a note of that. > Did I tell you about the difference in the angular profiles between > beamline and McStas at the end of the tapered guide? Beamline gives me > a rather regular profile, while McStas calculates some extra maxima at > about 11 minutes of arc (looks like Batman). The difference is not > extreme but large enough to again think about the guide. I should send > you the files if you want to have a look at them. Yes, send them and I will take a look. Do you think that the difference is caused by a program bug (in McStas or Beamline), or in an error in the setup of the instrument definition? > I don't know what to do about the PGPLOT problem. May I refer to your > offer of giving you an account here? Yes indeed, it it is possible for you to provide me with an account, that would be the easiest way to solve the problem. I would really like to solve this problem, especially since future versions of McStas will provide some useful simple visualization built-in that will depend heavily on the Perl<->PGPLOT interface PgPerl that you experience problem with. - Kristian. From kristian.nielsen at risoe.dk Fri Nov 20 12:39:17 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 20 Nov 1998 12:39:17 +0100 Subject: New mailing list for neutron simulation Message-ID: <01J4EASV891I8WX9ZI@risoe.dk> Dear participant in the Monte Carlo RTD Workshop at Ris? Oct. 30, At the MC Workshop, it was agreed that Ris? would set up a web site and a mailing list for communication and collaboration between the various efforts in Monte Carlo simulation of neutron scattering. The site is now up, and you have been added to the mailing list "neutron-mc". To be removed from the list, use the World-Wide-Web form at http://neutron.risoe.dk/neutron-mc/ To send messages to the list, write email to the address neutron-mc at risoe.dk The possible subjects of e-mails posted to this list include - Announcements of new software releases, results, papers, etc. - Discussion of simulation techniques for neutron scattering. - Discussion on the use of particular simulation programs. - Anything else related to Monte Carlo simulation of neutron scattering. We suggest that questions on the use of McStas be directed to this list, rather than directly to the McStas authors. This will enable other people with interest in McStas to benefit from the discussion or contribute with answers. The list is archived on the World-Wide-Web at the address http://neutron.risoe.dk/neutron-mc/ where old messages posted to the list may be browsed or searched using a full-text search engine. We also invite discussions of other programs. It is our hope that this list will provide a forum for many different approaches to simulation, and not be restricted to the Ris? program McStas. The location of the Main World-Wide-Web page is http://elu-alf-2.risoe.dk/~elu-krni/mcstas/ If you have any material related to Monte Carlo simulation that you would like to be referenced on the page, send me an e-mail at kristian.nielsen at risoe.dk. Regards, Kristian Nielsen McStas development Ris? National Laboratory From kristian.nielsen at risoe.dk Fri Nov 20 13:08:44 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 20 Nov 1998 13:08:44 +0100 Subject: Energy_Monitor affects final intensity? In-Reply-To: <13908.5823.254805.170353@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: <01J4EBTDRPMU8WX0AY@risoe.dk> > Hello Kristian, > > I have just encountered a strange result with my last job: > > The instrument looks like source, guide, Cu monochromator and several > detectors at the sample position. To investigate more precisely what > happens to the energy distribution I added another E_monitor just in > front of the monochromator. But then the final intensity at the sample > position drops by a factor of about 2/3!!! This difference is a > factor of 20 larger then the error. This happens also with fixed > seed. Running with -s 2 gives > It seems as if the E_monitor is absorbing neutrons??? Isn't it > supposed not to do so!? Am I wrong somewhere? The problem is that in your instrument, the E_monitor is placed in the middle of the third guide section: > COMPONENT part3 = Guide2( > w1 = 0.038644, > h1 = 0.072392, > w2 = 0.020, > h2 = 0.060, > l = 9.500, ... > AT (0,0,4.202) RELATIVE a1 > COMPONENT enmon = E_monitor( ... > AT (0,0,9.88) RELATIVE a1 ^^^ I suspect that you meant to say "RELATIVE part3" here, which would place the monitor after the end of the guide, but then it would overlap the monochromator! You need to put the E_monitor "AT(0,0,9.7) RELATIVE part3" or something similar to put it between the guide section and the monochromator. This is a common "gotcha" of McStas, I am afraid, and I will look into finding a way for McStas to help catch these kinds of errors (I have a few ideas already). I will look into your profile problem later. I also investigated the PgPerl problem by logging in to the account you supplied me with. On my system (Debian/GNU Linux), PgPerl is preinstalled, so I had no problems. I tried installing it manually first on your machine and then on my own, and both fail in the same way! So yes, there is a problem, and I will sort it out as soon as I can (should be early next week at the latest). I will also investigate the strange beam profile you mentioned. - Kristian. From anderson at ill.fr Fri Nov 20 13:10:54 1998 From: anderson at ill.fr (Ian Anderson) Date: Fri, 20 Nov 1998 13:10:54 +0100 (MET) Subject: MC In-Reply-To: Message-ID: Hello fellow list members, Did anyone ever recieve a copy of the "standard neutron description" from our friends in the USA? Ian ____________________________________________________________________________ Ian Anderson _/ _/ _/ Head, Neutron Optics Lab. _/ _/ _/ Institut Laue-Langevin _/ _/ _/ B.P.156 _/ _/ _/ 38042 Grenoble Cedex 9 _/ _/_/_/_/ _/_/_/_/ France Telephone:(33) 4 76 20 71 37; Fax:(33) 4 76 20 77 00 email: anderson at ill.fr http://www.ill.fr/ ____________________________________________________________________________ From kristian.nielsen at risoe.dk Fri Nov 20 13:17:52 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 20 Nov 1998 13:17:52 +0100 Subject: MC In-Reply-To: (message from Ian Anderson on Fri, 20 Nov 1998 13:10:54 +0100 (MET)) Message-ID: <01J4EC5O7ML08WXA7K@risoe.dk> > Hello fellow list members, > > Did anyone ever recieve a copy of the "standard neutron description" from > our friends in the USA? Ken sent it to me a little while ago; you will find it on the McStas home page (in PDF / Adobe Acrobat format): http://elu-alf-2.risoe.dk/~elu-krni/mcstas/Draft_standards.pdf Note that there was another meeting last week where the standard was revised. I will make the new draft available on the page when I receive it. - Kristian. From artus at obiwan.kri.physik.uni-muenchen.de Fri Nov 20 13:18:04 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Fri, 20 Nov 1998 13:18:04 +0100 (CET) Subject: MC In-Reply-To: References: Message-ID: <13909.23790.546270.763981@obiwan.kri.physik.uni-muenchen.de> Ian Anderson writes: > Hello fellow list members, > > Did anyone ever recieve a copy of the "standard neutron description" from > our friends in the USA? > > Ian > > ____________________________________________________________________________ > Ian Anderson > _/ _/ _/ Head, Neutron Optics Lab. > _/ _/ _/ Institut Laue-Langevin > _/ _/ _/ B.P.156 > _/ _/ _/ 38042 Grenoble Cedex 9 > _/ _/_/_/_/ _/_/_/_/ France > > Telephone:(33) 4 76 20 71 37; Fax:(33) 4 76 20 77 00 > email: anderson at ill.fr http://www.ill.fr/ > ____________________________________________________________________________ > Hello MC-Users, I didnt' hear anything from the states! Since the Risoe meeting I started using McStas and I would like to know who else already uses this program? Georg ********************************************* Dr. Georg Artus Technische Universit?t M?nchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14018 Fax: +49 (0)89/289-12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Mon Nov 23 13:50:02 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Mon, 23 Nov 1998 13:50:02 +0100 Subject: McStas In-Reply-To: (message from Laszlo Pusztai on Fri, 20 Nov 1998 11:36:48 +0100 (MET)) Message-ID: <01J4IK5LQ6FG8WXIHL@risoe.dk> Dear Laszlo, > 2. This course would be necessary for me, since I cannot get through > the 'make install' step of the installation. I get an (obviously) error > message saying > "instrument.l", line 278.12: 1506-030 (S) Identifier parse_restricted > cannot be redeclared. I believe you found a small bug in McStas. To fix it, make the following two changes: Line 278 in file instrument.l reads static int parse_restricted = FALSE; remove the sord 'static' so that it reads int parse_restricted = FALSE; Line 2088 in file lex.yy.c similarly reads static int parse_restricted = FALSE; change it as before to read int parse_restricted = FALSE; Depending on your setup, making either just the first or just the second of these changes may be sufficient. However, if you change first 'instrument.l' and then 'lex.yy.c' you should be safe. Anyway, try it and let me know if it fixes the problem or not. - Kristian. From kristian.nielsen at risoe.dk Mon Nov 23 14:22:17 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Mon, 23 Nov 1998 14:22:17 +0100 Subject: absolute flux and M2 In-Reply-To: <13913.20880.414524.792607@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: <01J4IL9LQECY8WXFW3@risoe.dk> > Hello Kristian, > now that I'm using the E_monitor I'm a little bit confused about the > output. The E_monitor's output consist of 4 numbers in the file. They > should be Energy, number of neutrons, sum of the weights and sum of > the squared weights (E, N, I, M2). I'm not sure how to read these > values when I use Source_flux. Then M2 is much higher than I. > E.g. source_flat: > > 80.992 425 0.00177358 2.13035e-08 > > same file, but source_flux (flux=3.63E+12): > > 80.992 384 127625 1.14823e+08 This looks fine, but I think I understand your confusion. A common mistake (at least I made it many times while working on McStas) is to think of the weights as probabilities, ie. numbers smaller than one. Weights are NOT probabilities and they may well be greater than one. For example, for the Source_flux example above, N=384 and I=127625, so the average neutron weight is a bit more than 300. In fact, we can see that between the two sets of numbers, I increses by a factor of about 10**8, while M2 increses with a factor of about 10**16 = (10**8)**2. This fits well since M2 is the sum of the squares of the weights (I = sum(p_i) and M2 = sum(p_i**2)). You still get a good estimate of the statistical error from the square root of M2. Does that clarify matters for you? > The values for I can be transformed using flux and solid > angle (2.387E-4). How about M2? The square root of M2 can be transformed the same way as I, I should think. > What are the units of I and M2 for any monitor when I use source_flux? > I assume it is n/cm**2/s/AA? It is n/cm**2/time/st/AA, where the 'st' means steradian (units of solid angle), and 'time' is the same unit as the one supplied for the 'flux' parameter of the component (McStas does not really have any comcept of the duration of an experiment). When you say 'transform using solid angle', I am not quite sure what you mean; the Source_flux component itself makes a correction for the solid angle in which neutrons are emitted ... ? > According to the manual all monitors should give N, I and M2 in the > output. But using PSD_monitor or Divergence_monitor I have only one > number in the file? The E_monitor is the only one which produces all 3 > numbers? Yes, the manual should probably be clearer about this. The two-dimensional detectors do not output N and M2, since that would mess up the output (a M x N x 3 array is not easily representable in plain ASCII format). The output file format should improve vastly once we switch to NeXus. For now, the two-dimensional detectors store the N and M2 arrays as output parameters, so you can insert code in the FINALLY section of the instrument definitions to write them out to separate files. Let me know if you need more assistance on this. > Here two smaller remarks for any future revision of the manual: > 4.5.6. not dE but nchan hast to be given > 4.1.2 wrong formula for I in last sentence Ok, thanks. - Kristian. From artus at obiwan.kri.physik.uni-muenchen.de Mon Nov 23 16:43:18 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Mon, 23 Nov 1998 16:43:18 +0100 (CET) Subject: absolute flux and M2 In-Reply-To: <01J4IL9LQECY8WXFW3@risoe.dk> References: <13913.20880.414524.792607@obiwan.kri.physik.uni-muenchen.de> <01J4IL9LQECY8WXFW3@risoe.dk> Message-ID: <13913.25909.624018.921402@obiwan.kri.physik.uni-muenchen.de> Hello Kristian, > This looks fine, but I think I understand your confusion. A common > mistake (at least I made it many times while working on McStas) is to > think of the weights as probabilities, ie. numbers smaller than > one. Weights are NOT probabilities and they may well be greater than > one. For example, for the Source_flux example above, N=384 and I=127625, > so the average neutron weight is a bit more than 300. > > In fact, we can see that between the two sets of numbers, I increses by > a factor of about 10**8, while M2 increses with a factor of about > 10**16 = (10**8)**2. This fits well since M2 is the sum of the squares > of the weights (I = sum(p_i) and M2 = sum(p_i**2)). You still get a good > estimate of the statistical error from the square root of M2. > > Does that clarify matters for you? Yes, thanks. My error was to ignore that sigma**2 is calculated. I somehow supressed that ... > When you say 'transform using solid angle', I am not quite sure what you > mean; the Source_flux component itself makes a correction for the solid > angle in which neutrons are emitted ... ? > The solid angle in my example COMPONENT source = Source_flux( radius = 0.050, dist = 2.000, xw = 0.040, yh = 0.075, E0 = 81.804, dE = 1.636, flux = 3.63E+12) is 2.387E-4. 0.04 * 0.075 are exactly width an height of my guide. If according to my example I(flux)=3.66E+6 and I(flat)=0.0496 then I(flux) = I(flat) * flux * solid angle / 4 / pi (The numbers don't fit exactly because I didn't use the same seed for the two calculations.) Georg From kristian.nielsen at risoe.dk Tue Nov 24 14:13:03 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Tue, 24 Nov 1998 14:13:03 +0100 Subject: First tries using McStas In-Reply-To: <13908.3056.33799.267080@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: <01J4JZ8I18XG8WXVD1@risoe.dk> > I don't know what to do about the PGPLOT problem. May I refer to your > offer of giving you an account here? I finally managed to solve this. PgPerl is now installed properly and the mcdisplay program should work (at least it worked for me). Turns out that there were two problems. The one you experienced is actually a known problem and a fix was available on the web page for PgPerl. The next problem was a lot harder to find; apparently you have a rather new g77 compiler where 'libf2c' has been renamed to 'libg2c'; PgPerl tried to link with 'libf2c' and that fails. So, to summarize, what I did was to edit the Makefile: add '-nolinenumbers' as suggested in the fix on the web page, and change all occurences of 'f2c' to 'g2c'. I also had to recompile pgplot again, since you had forgotten to include the 'xserv' graphics driver, but that was a minor issue. - Kristian. From agarrett at ccbsf0.kek.jp Thu Nov 26 07:16:47 1998 From: agarrett at ccbsf0.kek.jp (Andrew Garrett) Date: Thu, 26 Nov 1998 15:16:47 +0900 Subject: Fermi Chopper Message-ID: <365CF24F.150AE6DA@ccbsf0.kek.jp> The following is a routine to simulate a fermi chopper. The math is set up to work in the accelerated frame of reference in which the chopper is at rest. By working in this frame, the computer can quickly reject a large fraction of the incoming neutrons. Only those neutrons that have a reasonable likelihood of passing through the chopper take up processing time. If a neutron deviates by less that 1 slit width in its passage through the chopper, its probability is adjusted according to its actual deviation. This allows for a greater number of neutrons to pass through the chopper than absorbing those that hit a blade. The blades separating the slits are currently held to be infinitely thin and perfectly absorbing. I have tested this routine for choppers whose curvature is optimized for 50, 100, 200, and 400 meV, and have compared the resolution to calculated values taken mostly from Adv. Colloid Interface Sci, 71-72 (1997) 209-232. Transmission values were obtained from an unpublished calculation, with calculated values comparing favorably at energies below the optimized energies, but reduced at higher energies. Our current belief is that the theoretical values are incorrect, due to an inappropriate small angle approximation, and that the values obtained from this routine are better. I would appreciate hearing about any other test results obtained from this routine. Thank you, Andrew Garrett -------------- next part -------------- A non-text attachment was scrubbed... Name: Curve_Fe.cmp Type: application/x-unknown-content-type-cmp_auto_file Size: 5575 bytes Desc: not available URL: From kristian.nielsen at risoe.dk Thu Nov 26 10:33:41 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Thu, 26 Nov 1998 10:33:41 +0100 Subject: The first one to unsubscribe ? In-Reply-To: <365B9DB3.8BACE4E3@neutron-server.kek.jp> (message from Mark Hagen on Wed, 25 Nov 1998 06:03:31 +0000) Message-ID: <01J4MK66YNZW8WY25C@risoe.dk> > Hi Kristian, > > I don't know if you keep a watchful eye on your mailing list ? If you > do you may be insulted to see that I do (the system sends me an e-mail). I did see your new address being added to the list, but I never saw the old one being removed, and in fact pha70 at cc.keele.ac.uk is still on the list. Apparently there is some list problem? > The ALLOCA problem. > We tried to install Mcstas on a Hewlett Packard Workstation (HPUX) he has and > it failed because it objected to alloca. Ok, I fixed (I hope) the alloca problem. Now mcstas should no longer use the alloca() function at all. I just checked, and mcstas now compiles on our HP box using the HP compiler (we normally use gcc). I already fixed the strcasecmp/stricmp problem in my sources. For Windows (32 bit) a few other minor details needs fixing, see the list archive for details. My current sources compile cleanly in Visual C (it is necessary to define the C preprocessor macro "WIN32"). In the end quite a few files have small changes, so rather than sending individual files I will build a beta of "McStas v1.01" and put it on the web page later today. > The good news, Mcstas works fine under Digital Unix, I loaded it on my Keele DEC > Unix Alpha with no problems. Ditto Slackware Linux, the only subtlety is that one > needs to run the final exe files via ./program for some reason. Great. The reason for the "./program" thing is that "." (the current directory) is not included in the $PATH variable, probably for security reasons. I think that is even in the manual :-). > Collimator + Energy monitor. Okay so a flat energy distribution from say 5meV > to 100meV. But it wasn't flat in the energy detector. Reason being, as Drew > explained to me, your source emits as a uniform velocity distribution ? In other > words you convert the low and high energy ranges to velocities and then use a > 0 t 1 random number generator in the range of velocities ? Velocity is a funny Ouch! We fixed this in the Source_flat component, but missed it in the Moderator component. I will fix this and include it in the McStas beta. > The mailing list looks very nice, my man from Metro. Univ. was very impressed and > signed on to it. Another suggestion, for your benefit, well Risoes. On the sign on > page, in the form, ask people to supply their names and normal mail addresses as > well. When it comes time to write a report for the EU about how wonderful all this > Mcstas work is, you'll be able to supply a list of "Mcstas users" from around the > world showing what a great success it is. A list of e-mail addresses doesn't have > the same impact. Also it provides a mailing list for any future MC meetings. If > you're unsure about this ask Kurt what he thinks, I think he'll see the "political" > advantages to keeping such a record. Also record the number of hits and downloads > from the web page. Again will look nice and impressive in a report to Brussels in > the future. Recording rela name and address sounds good, it is now on my ToDo list. The hits and downloads can be deduced from the server logfiles. Thanks for all your helpful comments, - Kristian. From kristian.nielsen at risoe.dk Thu Nov 26 13:05:54 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Thu, 26 Nov 1998 13:05:54 +0100 Subject: McStas v1.01 BETA 1 Message-ID: <01J4MPGXL7AO8WYE61@risoe.dk> A BETA release of McStas, version 1.01 BETA 1, is now available from the McStas home page. This release fixes some problems that have come up since the first release (v1.0). The main change is the addition of support for 32-bit Windows operating systems. It also fixes the energy distribution problem in the time-of-flight source component that Mark Hagen mentioned recently. NOTE: There is no need to upgrade unless you experience some of the specific problems that are addressed by this release. See http://elu-alf-2.risoe.dk/~elu-krni/mcstas/support/beta/1.01b1.html for more information. Please report any problems to the list so that they can be fixed. - Kristian. From artus at obiwan.kri.physik.uni-muenchen.de Mon Nov 30 14:23:53 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Mon, 30 Nov 1998 14:23:53 +0100 (CET) Subject: small theta and sample size Message-ID: <13922.39207.904771.987298@obiwan.kri.physik.uni-muenchen.de> Hello Kristian, I just wanted to simulate the peak profile of a reflection with theta=10? at the sample. I'm using the monochromator component for a single crystal sample. With a sample size of 5mm I would have to set zmin and zmax to (-+)0.0144! I'm wondering whether the simulation ist still meaningful with such a 'long' sample!? Is there any chance to avoid this? Best wishes, Georg ********************************************* Dr. Georg Artus Technische Universit?t M?nchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14018 Fax: +49 (0)89/289-12112 E-mail: gartus at ph.tum.de From artus at obiwan.kri.physik.uni-muenchen.de Thu Nov 19 14:19:36 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Thu, 19 Nov 1998 14:19:36 +0100 (CET) Subject: Energy_Monitor affects final intensity? In-Reply-To: <01J43B55T2N691WTRJ@risoe.dk> References: <13896.13203.557267.61539@obiwan.kri.physik.uni-muenchen.de> <01J43B55T2N691WTRJ@risoe.dk> Message-ID: <13908.5823.254805.170353@obiwan.kri.physik.uni-muenchen.de> Hello Kristian, I have just encountered a strange result with my last job: The instrument looks like source, guide, Cu monochromator and several detectors at the sample position. To investigate more precisely what happens to the energy distribution I added another E_monitor just in front of the monochromator. But then the final intensity at the sample position drops by a factor of about 2/3!!! This difference is a factor of 20 larger then the error. This happens also with fixed seed. Running with -s 2 gives Detector: psdsamar_I=2.11443e+06 psdsamar_ERR=44571.6 Detector: psdsam_I=213670 psdsam_ERR=14286.2 Detector: divsamar_I=1.90489e+06 divsamar_ERR=43010.2 Detector: divsam_I=200795 divsam_ERR=13871.7 with E_mon in front of the monochromator and Detector: psdsamar_I=3.58938e+06 psdsamar_ERR=57710.6 Detector: psdsam_I=364115 psdsam_ERR=18388.7 Detector: divsamar_I=3.11014e+06 divsamar_ERR=54681.8 Detector: divsam_I=333511 divsam_ERR=17787.5 without. It seems as if the E_monitor is absorbing neutrons??? Isn't it supposed not to do so!? Am I wrong somewhere? Attached is the input file with E_mon in front of the monochromator: Georg ************* DEFINE INSTRUMENT 4075M23CU422() DECLARE %{ /* Mosaicity used on monochromator */ double mono_mosaic_v = 20; double mono_mosaic_h = 20; /* Q vector for bragg scattering with monochromator */ double mono_q = 8.517; /* Cu 422 1AA */ double mono_r0 = 0.3; double thetam = 42.67; double tthetam; %} INITIALIZE %{ tthetam = 2 * thetam; %} TRACE COMPONENT a1 = Arm() AT (0,0,0) ABSOLUTE COMPONENT source = Source_flux( radius = 0.050, dist = 2.000, xw = 0.040, yh = 0.075, E0 = 81.804, /* = 1A*/ dE = 1.636, /* entspricht deltalambda / lambda = 1E-02 */ flux = 3.63E+12) AT (0,0,0) RELATIVE a1 COMPONENT part1 = Guide2( w1 = 0.040, h1 = 0.075, w2 = 0.038644, h2 = 0.073982, l = 0.780, R0 = 1.0, Qc = 0.0214, alpha = 5.617, mh = 3, mv = 2, W = 0.0033) AT (0,0,2) RELATIVE a1 COMPONENT part2 = Guide2( w1 = 0.038644, h1 = 0.073982, w2 = 0.036522, h2 = 0.072392, l = 1.220, R0 = 1.0, Qc = 0.0214, alpha = 5.617, mh = 3, mv = 2, W = 0.0033) AT (0,0,2.782) RELATIVE a1 COMPONENT part3 = Guide2( w1 = 0.038644, h1 = 0.072392, w2 = 0.020, h2 = 0.060, l = 9.500, R0 = 1.0, Qc = 0.0214, alpha = 5.617, mh = 3, mv = 2, W = 0.0033) AT (0,0,4.202) RELATIVE a1 COMPONENT a2 = Arm() AT (0,0,9.9) RELATIVE part3 ROTATED (0,tthetam,0) RELATIVE a1 COMPONENT enmon = E_monitor( xmin = -0.01, xmax = 0.01, ymin = -0.03, ymax = 0.03, Emin = 80.992, Emax = 82.628, nchan = 10, filename = "enmon.out") AT (0,0,9.88) RELATIVE a1 COMPONENT cumono = Monochromator( zmin = -0.15, zmax = 0.15, ymin = -0.03, ymax = 0.03, mosaich = mono_mosaic_h, mosaicv = mono_mosaic_v, r0 = mono_r0, Q = mono_q) AT (0,0,0) RELATIVE a2 ROTATED (0,thetam,0) RELATIVE a1 COMPONENT psdsamar = PSD_monitor( xmin = -0.01, xmax = 0.01, ymin = -0.03, ymax = 0.03, nx = 20, ny = 60, filename = "psdsamar.out") AT (0,0,2) RELATIVE a2 COMPONENT psdsam = PSD_monitor( xmin = -0.005, xmax = 0.005, ymin = -0.005, ymax = 0.005, nx = 10, ny = 10, filename = "psdsam.out") AT (0,0,2) RELATIVE a2 COMPONENT divsamar = Divergence_monitor( xmin = -0.01, xmax = 0.01, ymin = -0.03, ymax = 0.03, nh = 45, nv = 45, h_maxdiv = 0.375, v_maxdiv = 0.375, filename = "divsamar.out") AT (0,0,2) RELATIVE a2 COMPONENT divsam = Divergence_monitor( xmin = -0.005, xmax = 0.005, ymin = -0.005, ymax = 0.005, nh = 45, nv = 45, h_maxdiv = 0.375, v_maxdiv = 0.375, filename = "divsam.out") AT (0,0,2) RELATIVE a2 COMPONENT ensamar = E_monitor( xmin = -0.01, xmax = 0.01, ymin = -0.03, ymax = 0.03, Emin = 80.992, Emax = 82.628, nchan = 10, filename = "ensamar.out") AT (0,0,2) RELATIVE a2 COMPONENT ensam = E_monitor( xmin = -0.005, xmax = 0.005, ymin = -0.005, ymax = 0.005, Emin = 80.992, Emax = 82.628, nchan = 10, filename = "ensam.out") AT (0,0,2) RELATIVE a2 END From kristian.nielsen at risoe.dk Mon Nov 23 14:49:55 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 23 Nov 1998 14:49:55 +0100 Subject: McStas In-Reply-To: (message from Laszlo Pusztai on Fri, 20 Nov 1998 11:36:48 +0100 (MET)) Message-ID: Dear Laszlo, > 2. This course would be necessary for me, since I cannot get through > the 'make install' step of the installation. I get an (obviously) error > message saying > "instrument.l", line 278.12: 1506-030 (S) Identifier parse_restricted > cannot be redeclared. I believe you found a small bug in McStas. To fix it, make the following two changes: Line 278 in file instrument.l reads static int parse_restricted = FALSE; remove the sord 'static' so that it reads int parse_restricted = FALSE; Line 2088 in file lex.yy.c similarly reads static int parse_restricted = FALSE; change it as before to read int parse_restricted = FALSE; Depending on your setup, making either just the first or just the second of these changes may be sufficient. However, if you change first 'instrument.l' and then 'lex.yy.c' you should be safe. Anyway, try it and let me know if it fixes the problem or not. - Kristian. From artus at obiwan.kri.physik.uni-muenchen.de Mon Nov 23 13:50:30 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Mon, 23 Nov 1998 13:50:30 +0100 (CET) Subject: absolute flux and M2 In-Reply-To: <01J4EBTDRPMU8WX0AY@risoe.dk> References: <13908.5823.254805.170353@obiwan.kri.physik.uni-muenchen.de> <01J4EBTDRPMU8WX0AY@risoe.dk> Message-ID: <13913.20880.414524.792607@obiwan.kri.physik.uni-muenchen.de> Hello Kristian, now that I'm using the E_monitor I'm a little bit confused about the output. The E_monitor's output consist of 4 numbers in the file. They should be Energy, number of neutrons, sum of the weights and sum of the squared weights (E, N, I, M2). I'm not sure how to read these values when I use Source_flux. Then M2 is much higher than I. E.g. source_flat: 80.992 425 0.00177358 2.13035e-08 same file, but source_flux (flux=3.63E+12): 80.992 384 127625 1.14823e+08 The values for I can be transformed using flux and solid angle (2.387E-4). How about M2? What are the units of I and M2 for any monitor when I use source_flux? I assume it is n/cm**2/s/AA? According to the manual all monitors should give N, I and M2 in the output. But using PSD_monitor or Divergence_monitor I have only one number in the file? The E_monitor is the only one which produces all 3 numbers? Here two smaller remarks for any future revision of the manual: 4.5.6. not dE but nchan hast to be given 4.1.2 wrong formula for I in last sentence Best wishes, Georg From mark.hagen at neutron-server.kek.jp Wed Nov 25 07:03:31 1998 From: mark.hagen at neutron-server.kek.jp (Mark Hagen) Date: Wed, 25 Nov 1998 06:03:31 +0000 Subject: The first one to unsubscribe ? Message-ID: <365B9DB3.8BACE4E3@neutron-server.kek.jp> Hi Kristian, I don't know if you keep a watchful eye on who subscribes and unsubscribes from your mailing list ? If you do you may be insulted to see that pha70 at cc.keele.ac.uk (Mark Hagen) has unsubscribed, however I can reassure you I hope by pointing out that mark.hagen at neutron-server.kek.jp has subscribed to it. Easier to get my e-mail here at the moment, rather than in Keele. Okay, other reasons for e-mailing. I leave it to you as to whether you forward these onto the e-mail list or if you quietly deal with them. The ALLOCA problem. ------------------- When I was at the MC meeting we tried to compile MCStas on MS-Visual C++, I don't know if you recall or not. However the reason it wouldn't work was because in instrument.tab.c there was a call to alloca, which it seems isn't an ANSI standard-C function. Okay my reason for bringing this up again is that I "made a sale" yesterday. A guy from Metro. Univ. in Tokyo who works at KEK. We tried to install Mcstas on a Hewlett Packard Workstation (HPUX) he has and it failed because it objected to alloca. Okay, so the guy will try installing it on an IBM Unix (AIX ?) workstation to see if it will work through there. Now you had a work around for the failure of alloca ? using malloc. Any chance of version of instrument.tab.c with that work around in it ? My recollection for Visual C++ was that the alloca and changing strcmpcase to stricase were all that the problem was there. If you made a change to instrument.tab.c and put the new file on the webpage for download as an "upgrade" for people who have the alloca problem then that would resolve the problem for this release. Well if you put the files with strcmpcase changed to stricase up as well with a note for HP or MS-VC users to download them and replace that would be even better. I know you put up a .exe for Win95 but the correct source files would be nice. The good news, Mcstas works fine under Digital Unix, I loaded it on my Keele DEC Unix Alpha with no problems. Ditto Slackware Linux, the only subtlety is that one needs to run the final exe files via ./program for some reason. Time of Flight, Source Distributions and Energy Monitors ------------------------------------------------------- As I mentioned above Drew Garret and I were demonstrating Mcstas to someone from Metro. Univ. and we decided to do a very simple ToF sim. to show him. Source + Collimator + Energy monitor. Okay so a flat energy distribution from say 5meV to 100meV. But it wasn't flat in the energy detector. Reason being, as Drew explained to me, your source emits as a uniform velocity distribution ? In other words you convert the low and high energy ranges to velocities and then use a 0 t 1 random number generator in the range of velocities ? Velocity is a funny one, it is not particularly used. For reactor people this may not matter but to us ToF boys it will be more relevant. I think a source should emit in uniform energy steps not velocity. When I first saw the curved energy distribution I jumped to a conclusion many ToF people would, that you hadn't done the ToF to Energy jacobian in the energy monitor. This isn't strictly correct but is close to the reason. You're plotting neutrons/unit of velocity in energy bins, hence the graph has a 1/sqrt(E) form. If you emitted uniformly in energy it would be neutrons/unit energy against energy which would be a nice flat line. So a request for a source that emits uniformly in energy, should be an extremely minor change, in the next revision ? The mailing list looks very nice, my man from Metro. Univ. was very impressed and signed on to it. Another suggestion, for your benefit, well Risoes. On the sign on page, in the form, ask people to supply their names and normal mail addresses as well. When it comes time to write a report for the EU about how wonderful all this Mcstas work is, you'll be able to supply a list of "Mcstas users" from around the world showing what a great success it is. A list of e-mail addresses doesn't have the same impact. Also it provides a mailing list for any future MC meetings. If you're unsure about this ask Kurt what he thinks, I think he'll see the "political" advantages to keeping such a record. Also record the number of hits and downloads from the web page. Again will look nice and impressive in a report to Brussels in the future. Okay, after all these suggestions of work for you I'd better get on and do some of my own work :) By the way Drew will be in touch soon, he has a working Mcstas routine for a Fermi chopper. I have one for my program as well. You could mention this to Kurt, he asked a number of people at the meeting if they had Fermi chopper code and everyone said no. Fermi chopper will be a very useful addition, very important for time of flighters. Cheers, Mark From mark.hagen at neutron-server.kek.jp Thu Nov 26 15:38:23 1998 From: mark.hagen at neutron-server.kek.jp (Mark Hagen) Date: Thu, 26 Nov 1998 14:38:23 +0000 Subject: The first one to unsubscribe ? References: <01J4MK66YNZW8WY25C@risoe.dk> Message-ID: <365D67DF.E9B8689@neutron-server.kek.jp> Hi there, Thanks for your speedy reply. > I do (the system sends me an e-mail). I did see your new address being > added to the list, but I never saw the old one being removed, and in > fact pha70 at cc.keele.ac.uk is still on the list. Apparently there is some > list problem? > Yes, perhaps. I checked on the Keele computer and the mail system has sent a message to my account that it is unable to deliver a message to majordomo at neutron.risoe.dk but will keep trying for 5 days. > > The ALLOCA problem. > Ok, I fixed (I hope) the alloca problem. Now mcstas should no longer use > the alloca() function at all. I just checked, and mcstas now compiles on > our HP box using the HP compiler (we normally use gcc). > Excellent I'll e-mail my man and tell him to download the beta version. I'll check with him if he tried the IBM. Looks good though, you've now covered pretty well all the major platforms, DEC, HP, IBM (I haven't heard, so no news is good news), Linux (in various versions) and Win95 with Visual C and Drew has it for the Borland C++ compiler. > I already fixed the strcasecmp/stricmp problem in my sources. For > Windows (32 bit) a few other minor details needs fixing, see the list > archive for details. My current sources compile cleanly in Visual C (it > is necessary to define the C preprocessor macro "WIN32"). > > In the end quite a few files have small changes, so rather than sending > individual files I will build a beta of "McStas v1.01" and put it on the > web page later today. I've downloaded a copy to my laptop and will give it a try tomorrow. > Great. The reason for the "./program" thing is that "." (the current > directory) is not included in the $PATH variable, probably for security > reasons. I think that is even in the manual :-). Yes, looking in the manual was how I "worked it out", would have fooled me otherwise. > > > Collimator + Energy monitor. Okay so a flat energy distribution from say 5meV > > to 100meV. But it wasn't flat in the energy detector. Reason being, as Drew > > explained to me, your source emits as a uniform velocity distribution ? In other > > words you convert the low and high energy ranges to velocities and then use a > > 0 t 1 random number generator in the range of velocities ? Velocity is a funny > > Ouch! We fixed this in the Source_flat component, but missed it in the > Moderator component. I will fix this and include it in the McStas beta. > We hope to put McStas through it's paces next week. I have done a series of calculations for a new spectrometer design they're thinking about at KEK using my program and Drew is going to check my results by repeating the calculations with McStas next week. He sent a message to the mailing list about his Fermi chopper component, I don't know if you saw it or not. His explanation was a little opaque, but I have seen his computed results compared with results for the design of the MARI (spectrometer at ISIS) Fermi chopper and they do compare very well. A Fermi chopper is an important component for the ToF community, it is probably something, once you are happy with his code, that you want as a standard component in your library. I am reasonably happy with his code because.... for some reason it is jolly similar to my F90 code for a Fermi chopper :) Okay, it's late here in Japan, I'm off for some sleep, things look pretty good to me, hope you're getting plenty of hits and e-mail sign-ups, I'm sure it will grow with time, cheers, Mark From pusztai at para.chem.elte.hu Fri Nov 27 16:30:30 1998 From: pusztai at para.chem.elte.hu (Laszlo Pusztai) Date: Fri, 27 Nov 1998 16:30:30 +0100 (MET) Subject: McStas v1.01 BETA 1 In-Reply-To: <01J4MPGXL7AO8WYE61@risoe.dk> Message-ID: Kristian, DO you happen to have an instrument file that contains a lot of neutron guides? (We have this specific problem of redesigning the guide system and, unfortunately, I couldn't find any example that would be good as a start for that.) Thanks, Laszlo. From kristian.nielsen at risoe.dk Mon Nov 30 14:31:15 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 30 Nov 1998 14:31:15 +0100 Subject: McStas v1.01 BETA 1 In-Reply-To: (message from Laszlo Pusztai on Fri, 27 Nov 1998 16:30:30 +0100 (MET)) Message-ID: > DO you happen to have an instrument file that contains a lot of neutron > guides? (We have this specific problem of redesigning the guide system > and, unfortunately, I couldn't find any example that would be good as a > start for that.) Kim Lefmann is currently setting up a simulation of the front-end of the RITA spectrometer at Risoe. This has five or six guide sections. I have put it on our Web server; you may download it from http://elu-alf-2.risoe.dk/~elu-krni/mcstas/support/misc/RITA_frontend.instr If you want to run this simulation, you also need a couple of new components: http://elu-alf-2.risoe.dk/~elu-krni/mcstas/support/misc/Divergence_monitor.comp http://elu-alf-2.risoe.dk/~elu-krni/mcstas/support/misc/V_selector.comp You could also try asking on the mailing list (neutron-mc at risoe.dk). Several people at other institutions have set up McStas simulations with guides and might be willing to share their code. - Kristian. From pusztai at para.chem.elte.hu Mon Nov 30 15:17:38 1998 From: pusztai at para.chem.elte.hu (Laszlo Pusztai) Date: Mon, 30 Nov 1998 15:17:38 +0100 (MET) Subject: McStas v1.01 BETA 1 In-Reply-To: <01J4SDLUNQKI8WYUDR@risoe.dk> Message-ID: Thanks, I've got the files. Laszlo. From pusztai at para.chem.elte.hu Fri Nov 20 11:36:48 1998 From: pusztai at para.chem.elte.hu (Laszlo Pusztai) Date: Fri, 20 Nov 1998 11:36:48 +0100 (MET) Subject: McStas Message-ID: Dear Kristian, I'm one of participants of the meeting on MC simulation on neutron scattering instruments, held in Risoe at the of October. I have two questions: 1. There was an offer of you (and of Kurt Clausen) that possibly an introductory course on the use of McStas will be given before Christmas. Is there a date assigned to this; or if there is not so many applicants, is it possible that somebody (like me, e.g.) would just go there and try to learn? 2. This course would be necessary for me, since I cannot get through the 'make install' step of the installation. I get an (obviously) error message saying "instrument.l", line 278.12: 1506-030 (S) Identifier parse_restricted cannot be redeclared. Any idea? (I'm almost like a Unix-dummy, so please, use simple words...) I am NOTa superuser of the machine I've used, so I tried to apply the prefix command (i think, successfully). Many thanks, and best regards, Laszlo Pusztai. From kristian.nielsen at risoe.dk Wed Dec 2 09:53:34 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Wed, 02 Dec 1998 09:53:34 +0100 Subject: Any interest in a McStas mini workshop / course? Message-ID: <01J4UWIJL03O8WZ0XA@risoe.dk> Hi all, At the Monte Carlo workshop at Ris? on October 30th, we at Ris? offered to let interested people visit us and receive help on getting started with using McStas. I was wondering how much interest there is in this? If several people would like to come, we might arrange a small course or a mini-workshop on McStas. On the other hand, if it is only a few, they could just visit individually at the most convenient time. So, I would ask those who might be interested in visiting Ris? to learn McStas to please write me an email (at kristian.nielsen at risoe.dk). - Kristian. From kristian.nielsen at risoe.dk Tue Dec 1 11:16:25 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 1 Dec 1998 11:16:25 +0100 Subject: First tries using McStas In-Reply-To: <13908.3056.33799.267080@obiwan.kri.physik.uni-muenchen.de> (artus@obiwan.kri.physik.uni-muenchen.de) Message-ID: > Did I tell you about the difference in the angular profiles between > beamline and McStas at the end of the tapered guide? Beamline gives me > a rather regular profile, while McStas calculates some extra maxima at > about 11 minutes of arc (looks like Batman). The difference is not > extreme but large enough to again think about the guide. I should send > you the files if you want to have a look at them. Ok, I finally got around to take a look at this (sorry for taking so long). I think what you are seeing is an effect of the gab you have between guide section 2 and 3: COMPONENT part2 = Guide2( w2 = 0.036522, l = 1.220, ... AT (0,0,2.782) RELATIVE a1 COMPONENT part3 = Guide2( w1 = 0.038644, l = 9.500, ... AT (0,0,4.202) RELATIVE a1 There is a 20 cm long and about 2 mm wide gab between the two sections in the horizontal direction. From the divergence detector, this gab is seen at an angle of about 0.12 degrees, and that is precisely the location of the two minima on the horizontal beam profile ... To investigate this, I tried to run a modified version of your simulation where the gab is closed: COMPONENT part2 = Guide2( w2 = 0.036522, l = 1.220, AT (0,0,2.782) RELATIVE a1 COMPONENT part3 = Guide2( w1 = 0.036522, l = 9.700, AT (0,0,4.003) RELATIVE a1 With the gab closed, the horizontal profile is smooth. So it appears safe to conclude that the gab is the cause of the strange minima. If you look closely, you can see a similar effect in the vertical direction, though it is much less pronounced (probably because of the larger m value and perhaps the larger guide dimensions in this direction). The question is then why you 'beamline' program does not show this effect? I assume that this program also has the gab between the guide sections? - Kristian. From kim.lefmann at risoe.dk Tue Dec 1 12:09:35 1998 From: kim.lefmann at risoe.dk (Kim Lefmann) Date: Tue, 01 Dec 1998 12:09:35 +0100 (MET) Subject: Georg mails Message-ID: <199812011109.MAA22446@fys-hp-1.risoe.dk> >From lefmann Tue Dec 1 09:36:30 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id JAA18328; Tue, 1 Dec 1998 09:36:30 +0100 (MET) From: Kim Lefmann Message-Id: <199812010836.JAA18328 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 9:36:29 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Nov 30, 98 2:23 pm X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, yes, there is a problem! We have not defined a general sample yet, and there is probably not going to be one ready before January/February, although we are working on it. You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. Yours, Kim >From artus at obiwan.kri.physik.uni-muenchen.de Tue Dec 1 10:22:09 MET 1998 Received: from risvm1.risoe.dk (risvm1.risoe.dk [130.226.48.29]) by fys-hp-1.risoe.dk with ESMTP (8.7.6/8.7.1) id KAA21040 for ; Tue, 1 Dec 1998 10:22:08 +0100 (MET) From: artus at obiwan.kri.physik.uni-muenchen.de Received: from CONVERSION-DAEMON by risoe.dk (PMDF V5.1-10 #28173) id <01J4TJ7L04HC8WYWJY at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 1 Dec 1998 10:22:06 +0100 Received: from obiwan.kri.physik.uni-muenchen.de by risoe.dk (PMDF V5.1-10 #28173) with ESMTP id <01J4TJ7HKCN68WYYB9 at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 01 Dec 1998 10:22:03 +0100 Received: (from artus at localhost) by obiwan.kri.physik.uni-muenchen.de (8.8.8/8.8.8) id KAA18962; Tue, 01 Dec 1998 10:19:32 +0100 Date: Tue, 01 Dec 1998 10:19:32 +0100 (CET) Subject: Re: small theta and sample size In-reply-to: <199812010836.JAA18328 at fys-hp-1.risoe.dk> To: Kim Lefmann Message-id: <13923.45737.632369.697606 at obiwan.kri.physik.uni-muenchen.de> MIME-version: 1.0 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <"artus at obiwan.kri.physik.uni-muenchen.de"@Nov> <199812010836.JAA18328 at fys-hp-1.risoe.dk> Status: RO Hello Kim, > You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. This is a good idea! Another question: Do you take the penetration depth into account with your actual monochromator component? This would be important for a monochromator with higher mosaicity. Penetration should broaden the profile!? Best regards, Georg >From lefmann Tue Dec 1 12:05:57 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id MAA22400; Tue, 1 Dec 1998 12:05:56 +0100 (MET) From: Kim Lefmann Message-Id: <199812011105.MAA22400 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 12:05:56 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Dec 01, 98 10:19 am X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, No, penetration is not included. This is, as you can see, a very preliminary component... In the powder1 sample, however, penetration and attenuation IS included, so if you are very brave, you may create a better single Xstal sample component using these two existing ones. Otherwise we will do it in a few months time. Kim >From lefmann Tue Dec 1 09:36:30 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id JAA18328; Tue, 1 Dec 1998 09:36:30 +0100 (MET) From: Kim Lefmann Message-Id: <199812010836.JAA18328 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 9:36:29 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Nov 30, 98 2:23 pm X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, yes, there is a problem! We have not defined a general sample yet, and there is probably not going to be one ready before January/February, although we are working on it. You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. Yours, Kim >From artus at obiwan.kri.physik.uni-muenchen.de Tue Dec 1 10:22:09 MET 1998 Received: from risvm1.risoe.dk (risvm1.risoe.dk [130.226.48.29]) by fys-hp-1.risoe.dk with ESMTP (8.7.6/8.7.1) id KAA21040 for ; Tue, 1 Dec 1998 10:22:08 +0100 (MET) From: artus at obiwan.kri.physik.uni-muenchen.de Received: from CONVERSION-DAEMON by risoe.dk (PMDF V5.1-10 #28173) id <01J4TJ7L04HC8WYWJY at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 1 Dec 1998 10:22:06 +0100 Received: from obiwan.kri.physik.uni-muenchen.de by risoe.dk (PMDF V5.1-10 #28173) with ESMTP id <01J4TJ7HKCN68WYYB9 at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 01 Dec 1998 10:22:03 +0100 Received: (from artus at localhost) by obiwan.kri.physik.uni-muenchen.de (8.8.8/8.8.8) id KAA18962; Tue, 01 Dec 1998 10:19:32 +0100 Date: Tue, 01 Dec 1998 10:19:32 +0100 (CET) Subject: Re: small theta and sample size In-reply-to: <199812010836.JAA18328 at fys-hp-1.risoe.dk> To: Kim Lefmann Message-id: <13923.45737.632369.697606 at obiwan.kri.physik.uni-muenchen.de> MIME-version: 1.0 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <"artus at obiwan.kri.physik.uni-muenchen.de"@Nov> <199812010836.JAA18328 at fys-hp-1.risoe.dk> Status: RO Hello Kim, > You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. This is a good idea! Another question: Do you take the penetration depth into account with your actual monochromator component? This would be important for a monochromator with higher mosaicity. Penetration should broaden the profile!? Best regards, Georg >From lefmann Tue Dec 1 12:05:57 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id MAA22400; Tue, 1 Dec 1998 12:05:56 +0100 (MET) From: Kim Lefmann Message-Id: <199812011105.MAA22400 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 12:05:56 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Dec 01, 98 10:19 am X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, No, penetration is not included. This is, as you can see, a very preliminary component... In the powder1 sample, however, penetration and attenuation IS included, so if you are very brave, you may create a better single Xstal sample component using these two existing ones. Otherwise we will do it in a few months time. Kim >From lefmann Tue Dec 1 09:36:30 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id JAA18328; Tue, 1 Dec 1998 09:36:30 +0100 (MET) From: Kim Lefmann Message-Id: <199812010836.JAA18328 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 9:36:29 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Nov 30, 98 2:23 pm X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, yes, there is a problem! We have not defined a general sample yet, and there is probably not going to be one ready before January/February, although we are working on it. You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. Yours, Kim >From artus at obiwan.kri.physik.uni-muenchen.de Tue Dec 1 10:22:09 MET 1998 Received: from risvm1.risoe.dk (risvm1.risoe.dk [130.226.48.29]) by fys-hp-1.risoe.dk with ESMTP (8.7.6/8.7.1) id KAA21040 for ; Tue, 1 Dec 1998 10:22:08 +0100 (MET) From: artus at obiwan.kri.physik.uni-muenchen.de Received: from CONVERSION-DAEMON by risoe.dk (PMDF V5.1-10 #28173) id <01J4TJ7L04HC8WYWJY at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 1 Dec 1998 10:22:06 +0100 Received: from obiwan.kri.physik.uni-muenchen.de by risoe.dk (PMDF V5.1-10 #28173) with ESMTP id <01J4TJ7HKCN68WYYB9 at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 01 Dec 1998 10:22:03 +0100 Received: (from artus at localhost) by obiwan.kri.physik.uni-muenchen.de (8.8.8/8.8.8) id KAA18962; Tue, 01 Dec 1998 10:19:32 +0100 Date: Tue, 01 Dec 1998 10:19:32 +0100 (CET) Subject: Re: small theta and sample size In-reply-to: <199812010836.JAA18328 at fys-hp-1.risoe.dk> To: Kim Lefmann Message-id: <13923.45737.632369.697606 at obiwan.kri.physik.uni-muenchen.de> MIME-version: 1.0 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <"artus at obiwan.kri.physik.uni-muenchen.de"@Nov> <199812010836.JAA18328 at fys-hp-1.risoe.dk> Status: RO Hello Kim, > You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. This is a good idea! Another question: Do you take the penetration depth into account with your actual monochromator component? This would be important for a monochromator with higher mosaicity. Penetration should broaden the profile!? Best regards, Georg >From lefmann Tue Dec 1 12:05:57 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id MAA22400; Tue, 1 Dec 1998 12:05:56 +0100 (MET) From: Kim Lefmann Message-Id: <199812011105.MAA22400 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 12:05:56 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Dec 01, 98 10:19 am X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, No, penetration is not included. This is, as you can see, a very preliminary component... In the powder1 sample, however, penetration and attenuation IS included, so if you are very brave, you may create a better single Xstal sample component using these two existing ones. Otherwise we will do it in a few months time. Kim >From lefmann Tue Dec 1 09:36:30 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id JAA18328; Tue, 1 Dec 1998 09:36:30 +0100 (MET) From: Kim Lefmann Message-Id: <199812010836.JAA18328 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 9:36:29 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Nov 30, 98 2:23 pm X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, yes, there is a problem! We have not defined a general sample yet, and there is probably not going to be one ready before January/February, although we are working on it. You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. Yours, Kim >From artus at obiwan.kri.physik.uni-muenchen.de Tue Dec 1 10:22:09 MET 1998 Received: from risvm1.risoe.dk (risvm1.risoe.dk [130.226.48.29]) by fys-hp-1.risoe.dk with ESMTP (8.7.6/8.7.1) id KAA21040 for ; Tue, 1 Dec 1998 10:22:08 +0100 (MET) From: artus at obiwan.kri.physik.uni-muenchen.de Received: from CONVERSION-DAEMON by risoe.dk (PMDF V5.1-10 #28173) id <01J4TJ7L04HC8WYWJY at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 1 Dec 1998 10:22:06 +0100 Received: from obiwan.kri.physik.uni-muenchen.de by risoe.dk (PMDF V5.1-10 #28173) with ESMTP id <01J4TJ7HKCN68WYYB9 at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Tue, 01 Dec 1998 10:22:03 +0100 Received: (from artus at localhost) by obiwan.kri.physik.uni-muenchen.de (8.8.8/8.8.8) id KAA18962; Tue, 01 Dec 1998 10:19:32 +0100 Date: Tue, 01 Dec 1998 10:19:32 +0100 (CET) Subject: Re: small theta and sample size In-reply-to: <199812010836.JAA18328 at fys-hp-1.risoe.dk> To: Kim Lefmann Message-id: <13923.45737.632369.697606 at obiwan.kri.physik.uni-muenchen.de> MIME-version: 1.0 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <"artus at obiwan.kri.physik.uni-muenchen.de"@Nov> <199812010836.JAA18328 at fys-hp-1.risoe.dk> Status: RO Hello Kim, > You may bypass the problem by making a composite sample consisting of many small monochromators, all with the same orientation, displaced in the x-direction. This will work because the monochromator component does not ABSORB a non-hitting neutron. This is a good idea! Another question: Do you take the penetration depth into account with your actual monochromator component? This would be important for a monochromator with higher mosaicity. Penetration should broaden the profile!? Best regards, Georg >From lefmann Tue Dec 1 12:05:57 MET 1998 Received: (from lefmann at localhost) by fys-hp-1.risoe.dk (8.7.6/8.7.1) id MAA22400; Tue, 1 Dec 1998 12:05:56 +0100 (MET) From: Kim Lefmann Message-Id: <199812011105.MAA22400 at fys-hp-1.risoe.dk> Subject: Re: small theta and sample size To: artus at obiwan.kri.physik.uni-muenchen.de Date: Tue, 01 Dec 1998 12:05:56 MET Cc: lefmann In-Reply-To: from "artus at obiwan.kri.physik.uni-muenchen.de" at Dec 01, 98 10:19 am X-Mailer: Elm [revision: 212.4] Status: RO Dear Georg, No, penetration is not included. This is, as you can see, a very preliminary component... In the powder1 sample, however, penetration and attenuation IS included, so if you are very brave, you may create a better single Xstal sample component using these two existing ones. Otherwise we will do it in a few months time. Kim From artus at obiwan.kri.physik.uni-muenchen.de Tue Dec 1 11:43:10 1998 From: artus at obiwan.kri.physik.uni-muenchen.de (artus at obiwan.kri.physik.uni-muenchen.de) Date: Tue, 01 Dec 1998 11:43:10 +0100 (CET) Subject: First tries using McStas In-Reply-To: <01J4TL3N9WJY8WZ23O@risoe.dk> References: <13908.3056.33799.267080@obiwan.kri.physik.uni-muenchen.de> <01J4TL3N9WJY8WZ23O@risoe.dk> Message-ID: <13923.50525.203297.633731@obiwan.kri.physik.uni-muenchen.de> Hello Kristian, thanks for finding the error! The gap should be 20cm long but not 2mm wide! The problem is that I obviously copied the wrong value for w1 for part3. Instead of .038644 it should of course be .036522 so that the widths of entrance and exit of the guides match! With the wrong number I of course had a too large slope for the side faces of the last part of the guide and this explaines the missing intensity at some angles in the horizontal divergence profile! The 20m gap itself makes sense (there will be the third barrier against water leakage) and this gap also is included within beamline. At the moment I'm rerunning the job with constant slope all over the guide. I bet now there is no difference in the profiles... Best regards, Georg From pusztai at para.chem.elte.hu Wed Dec 2 10:12:03 1998 From: pusztai at para.chem.elte.hu (Laszlo Pusztai) Date: Wed, 02 Dec 1998 10:12:03 +0100 (MET) Subject: Any interest in a McStas mini workshop / course? In-Reply-To: <01J4UWIJL03O8WZ0XA@risoe.dk> Message-ID: Kristian, I would be interested in a small workshop (but if it doesn't come to existence then I would probably try to go there on my own to learn how to simulate curved guides). Bye, Laszlo. From kadowaki at phys.metro-u.ac.jp Sat Dec 12 10:25:25 1998 From: kadowaki at phys.metro-u.ac.jp (Kadowaki Hiroaki) Date: Sat, 12 Dec 1998 18:25:25 +0900 Subject: install prob. AIX HPUX Message-ID: <199812120924.SAA43050@comp.metro-u.ac.jp> Dear Kristian Nielsen , MCSTAS looks very nice, which M Hagen showed me how to use, and I would like to start calculating something. So I am trying to install mcstas-1.01b1 on unix machines. (1) AIX Version 4 (IBM) (2) HP-UX A.09.01 A 9000/720 (3) Digital UNIX V3.2 <---- OK it works In the cases of AIX and HP-UX9, errors occurred during "make install". Could you see the following messages of the installation, and tell me what should I do? Sincerely Kadowaki Hiroaki Department of Physics, Tokyo Metropolitan University Hachioji-shi, Tokyo 192-0397, Japan tel 81-426-77-2509, fax 81-426-77-2483 e-mail kadowaki at phys.metro-u.ac.jp ----------- AIX---------------------------------- kunugi(kadowaki)% configure --prefix=/home/phys/kadowaki creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/installbsd -c checking for perl5... no checking for perl... /usr/local/bin/perl checking for gcc option to accept ANSI C... -DCC_HAS_PROTOS checking for strcasecmp... yes updating cache ./config.cache creating ./config.status creating Makefile kunugi(kadowaki)% make gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 i nstrument.tab.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 l ex.yy.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 d ebug.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 m emory.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 l ist.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 s ymtab.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 c oords.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 r otation.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 c exp.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 p osition.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 f ile.c gcc -I. -I. -c -g -O2 -DMC_SYS_DIR='"'/home/phys/kadowaki/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DHAVE_STRCASECMP=1 -DDEBUG=0 c ogen.c gcc -o mcstas -g -O2 instrument.tab.o lex.yy.o debug.o memory.o list.o symtab.o coords.o rotation.o cexp.o position.o f ile.o cogen.o -lm sed -e 's+#! /usr/bin/perl+#! '/usr/local/bin/perl'+' <./gscan.pl >gscan sed -e 's+#! /usr/bin/perl+#! '/usr/local/bin/perl'+' <./mcdisplay.pl >mcdisplay Target "all" is up to date. kunugi(kadowaki)% make install ./mkinstalldirs /home/phys/kadowaki/bin /home/phys/kadowaki/lib /home/phys/kadowaki/lib/mcstas mkdir /home/phys/kadowaki/bin mkdir /home/phys/kadowaki/lib mkdir /home/phys/kadowaki/lib/mcstas /usr/bin/installbsd -c mcstas /home/phys/kadowaki/bin/mcstas installbsd: /home/phys/kadowaki/bin/mcstas: Not owner make: The error code from the last command is 1. Stop. ------------------------------------------------- ----------- HP-UX---------------------------------- konisiki98$configure --prefix=/home/issp/kado creating cache ./config.cache checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... no checking for a BSD compatible install... ./install-sh -c checking for perl5... no checking for perl... /usr/local/bin/perl checking for cc option to accept ANSI C... -Aa -D_HPUX_SOURCE checking for strcasecmp... yes ./configure: sh internal 2K buffer overflow updating cache ./config.cache creating ./config.status creating Makefile konisiki100$make cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 instrumen t.tab.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 lex.yy.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 debug.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 memory.c cc: "memory.c", line 138: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 139: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 157: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 157: warning 563: Argument #1 is not the correct type. cc: "memory.c", line 157: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 159: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 159: warning 563: Argument #1 is not the correct type. cc: "memory.c", line 161: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 161: warning 563: Argument #1 is not the correct type. cc: "memory.c", line 163: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 163: warning 563: Argument #1 is not the correct type. cc: "memory.c", line 165: warning 604: Pointers are not assignment-compatible. cc: "memory.c", line 165: warning 563: Argument #1 is not the correct type. cc: "memory.c", line 171: warning 604: Pointers are not assignment-compatible. cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 list.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 symtab.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 coords.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 rotation. c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 cexp.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 position. c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 file.c cc -I. -I. -c -g -Aa -D_HPUX_SOURCE -DMC_SYS_DIR='"'/home/issp/kado/lib/mcstas'"' -DHAVE_STRCASECMP=1 -DDEBUG=0 cogen.c cc -o mcstas -g -Aa -D_HPUX_SOURCE instrument.tab.o lex.yy.o debug.o memory.o list.o symtab.o coords.o rotation.o cexp.o position.o file.o cogen.o -lm sed -e 's+#! /usr/bin/perl+#! '/usr/local/bin/perl'+' <./gscan.pl >gscan sed -e 's+#! /usr/bin/perl+#! '/usr/local/bin/perl'+' <./mcdisplay.pl >mcdisplay konisiki183$make install ./mkinstalldirs /home/issp/kado/bin /home/issp/kado/lib /home/issp/kado/lib/mcstas ./install-sh -c mcstas /home/issp/kado/bin/mcstas Make: Cannot load ./install-sh. Stop. *** Error code 1 Stop. ------------------------------------------------- From kristian.nielsen at risoe.dk Thu Dec 17 10:29:57 1998 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 17 Dec 1998 10:29:57 +0100 Subject: install prob. AIX HPUX In-Reply-To: <199812120924.SAA43050@comp.metro-u.ac.jp> (kadowaki@phys.metro-u.ac.jp) Message-ID: Sorry to take so long in getting back to you, but I am just recovering from a week with the flue ... > In the cases of AIX and HP-UX9, errors occurred > during "make install". Could you see the following messages > of the installation, and tell me what should I do? Hm, the errors you get look pretty strange to me ... Apparently, the compile runs fine, but the installation is unable to copy the files to their proper location. And the install fails in different ways on the two machines. Anyway, a quick workaround is to install the files manually. While in the main mcstas directory, execute the commands cp mcstas gscan mcdisplay /home/phys/kadowaki/bin/ cp lib/* /home/phys/kadowaki/lib/mcstas/ chmod +x /home/phys/kadowaki/bin/mcstas chmod +rx /home/phys/kadowaki/bin/gscan chmod +rx /home/phys/kadowaki/bin/mcdisplay chmod +r /home/phys/kadowaki/lib/mcstas/* The same commands should work on the HP, but with the path /home/phys/kadowaki replaced with /home/issp/kado, of course. As to why the install does not work on these machines I am not really sure. I do not know anything about AIX, but McStas installs without problems on our HPUX machine here at Ris?. The easiest way to track this down would probably be if I could get temporary accounts on the two machines and log in and check things out myself. That is, if the policies at your institution would allow this? Here are a few comments on the output you sent me: > kunugi(kadowaki)% configure --prefix=/home/phys/kadowaki > checking for a BSD compatible install... /usr/bin/installbsd -c Here the installation decides to use the AIX own install program rather than its own. > /usr/bin/installbsd -c mcstas /home/phys/kadowaki/bin/mcstas > installbsd: /home/phys/kadowaki/bin/mcstas: Not owner Here the install fails, but in a really strange way. Apparently it is saying that the mcstas program is owned by another user, even though it was just copied over ??? > ----------- HP-UX---------------------------------- > > konisiki98$configure --prefix=/home/issp/kado > > ./configure: sh internal 2K buffer overflow Now this error message has me somewhat worried, even though I see no immediate consequences. I wonder if your HPUX is very old? and maybe uses a shell with bugs or limitations? > ./install-sh -c mcstas /home/issp/kado/bin/mcstas > Make: Cannot load ./install-sh. Stop. Here the install fails to even start the installation program ./install-sh, which again suggest a severe problem with the shell on the system. - Kristian.