From Georg_Artus at Physik.TU-Muenchen.DE Fri Jan 8 18:15:34 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Fri, 08 Jan 1999 17:15:34 +0000 Subject: order of moving and rotating Message-ID: <36963D36.7E94E913@ph.tum.de> Hello, First of all a happy new year to all of you! Now the question: I'm trying to optimize the angle of a specific mirror in the neutron path. From the manual and also the results of the calculations it is not quite clear to me, how the mirror is moved and rotated and what the reference points are. Am I right, that any rotation is done after the translation, and that the rotation axes are the (not translated) axes of the coordinate system defined by the RELATIVE command? Or are only the directions of the rotation axis those of the component defined by RELATIVE, but the center of rotation now lies at (0,0,0) of the already moved component? Thanks for any advice! Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Mon Jan 18 16:44:06 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Mon, 18 Jan 1999 16:44:06 +0100 Subject: order of moving and rotating In-Reply-To: <36963D36.7E94E913@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: <01J6OYJRKSAO8X5TPW@risoe.dk> > Hello, > > First of all a happy new year to all of you! Thanks! I apologize for taking a bit long to answer your question. > Now the question: > I'm trying to optimize the angle of a specific mirror in the neutron > path. From the manual and also the results of the calculations it is not > quite clear to me, how the mirror is moved and rotated and what the > reference points are. Yes, this is a point that can be a bit confusing, and I am planning on writing a clarification in the next version of the manual. But if you approach the issue in the right way, it is not at all complicated. The coordinate system of a component has a position and an orientation. The position is the spatial location of the reference point. The orientation is the direction of the axes. Now, when a component is specified in the instrument definition, it has an AT and a ROTATED specification. The AT specifies the position and the ROTATED specifies the orientation. Thus if component C is AT (x,y,z) relative component A and ROTATED (v,0,0) relative component B, the reference point of C is at (x,y,z) in the coordinate system of A and the axes of C are the axes of B rotated the angle v around the X axis of B. > Am I right, that any rotation is done after the translation, and that > the rotation axes are the (not translated) axes of the coordinate system > defined by the RELATIVE command? Or are only the directions of the > rotation axis those of the component defined by RELATIVE, but the center > of rotation now lies at (0,0,0) of the already moved component? > Thanks for any advice! The last of your two possibilities describes most precisely what happens in McStas, I think. I hope the above explanation clarifies the issue. If not, ask again and I will use your feedback when updating the manual. A quick remark on the use on the mirror component. Consider building a guide from four mirrors. The guide entrance and exit are parallel to the X-Y plane, the guide top and bottom are parallel to the X-Z plane and the guide left and right sides are parallel to the Y-Z plane. The mirror component lies in the X-Y plane of the component local coordinate system. Thus to get the top or bottom, the mirror should be rotated about the X axis and moved up or down. To get the sides, the mirror should be rotated about the Y axis and moved left or right. I just finished a much improved version of the graphics display program for McStas simulations. It is capable of drawing real sketches of components so that one may see the exact position and orientation of every component. This will be in the next McStas release (due in March), and should greatly help understanding the setup of ones instrument. - Kristian. From Georg_Artus at Physik.TU-Muenchen.DE Tue Jan 19 13:21:30 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Tue, 19 Jan 1999 12:21:30 +0000 Subject: order of moving and rotating References: <01J6OYJRKSAO8X5TPW@risoe.dk> Message-ID: <36A478CA.D4256100@ph.tum.de> Hello, thanks for the help with rotation an translation of components. I'm finishing with the simulations for our diffractometer and hopefully I have found the best configuration now... I also compared beamline and McStas more exactly and not only transmissions but also profiles match really good. The remaining (small) differences can be explained by the different handling of the mirror reflectivities. Last year in one of the mails in this list Kristian or Kim mentioned that a general single crystal sample is in work and will be available 1999. When will that be? Georg Kristian Nielsen wrote: > > > Hello, > > > > First of all a happy new year to all of you! > > Thanks! I apologize for taking a bit long to answer your question. > > > Now the question: > > I'm trying to optimize the angle of a specific mirror in the neutron > > path. From the manual and also the results of the calculations it is not > > quite clear to me, how the mirror is moved and rotated and what the > > reference points are. > > Yes, this is a point that can be a bit confusing, and I am planning on > writing a clarification in the next version of the manual. > > But if you approach the issue in the right way, it is not at all > complicated. The coordinate system of a component has a position and an > orientation. The position is the spatial location of the reference > point. The orientation is the direction of the axes. > > Now, when a component is specified in the instrument definition, it has > an AT and a ROTATED specification. The AT specifies the position and the > ROTATED specifies the orientation. > > Thus if component C is AT (x,y,z) relative component A and ROTATED > (v,0,0) relative component B, the reference point of C is at (x,y,z) in > the coordinate system of A and the axes of C are the axes of B rotated > the angle v around the X axis of B. > > > Am I right, that any rotation is done after the translation, and that > > the rotation axes are the (not translated) axes of the coordinate system > > defined by the RELATIVE command? Or are only the directions of the > > rotation axis those of the component defined by RELATIVE, but the center > > of rotation now lies at (0,0,0) of the already moved component? > > Thanks for any advice! > > The last of your two possibilities describes most precisely what happens > in McStas, I think. I hope the above explanation clarifies the issue. If > not, ask again and I will use your feedback when updating the manual. > > A quick remark on the use on the mirror component. Consider building a > guide from four mirrors. The guide entrance and exit are parallel to > the X-Y plane, the guide top and bottom are parallel to the X-Z plane > and the guide left and right sides are parallel to the Y-Z plane. The > mirror component lies in the X-Y plane of the component local coordinate > system. Thus to get the top or bottom, the mirror should be rotated > about the X axis and moved up or down. To get the sides, the mirror > should be rotated about the Y axis and moved left or right. > > I just finished a much improved version of the graphics display program > for McStas simulations. It is capable of drawing real sketches of > components so that one may see the exact position and orientation of > every component. This will be in the next McStas release (due in March), > and should greatly help understanding the setup of ones instrument. > > - Kristian. -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From snphbern at jerry.rommel.stw.uni-erlangen.de Wed Jan 20 15:57:26 1999 From: snphbern at jerry.rommel.stw.uni-erlangen.de (Philipp Bernhardt) Date: Wed, 20 Jan 1999 15:57:26 +0100 (CET) Subject: Bender Message-ID: Hello, The following routine is simulating a curved neutron guide (bender). It is bent to the negative X axis. It behaves like a parallel guide in the Y axis. To get a better transmission coefficient, you can split the bender into channels. These channels are separated by partitions with the thickness of d. Because the angle of reflection doesn't change, the routine calculates the reflection coefficent for the concave and, if necessary, for the convex wall only onces, together with the number of reflections. Nevertheless the exact position, the time, and the divergence is calculated at the end of the bender, so there aren't any approximations. I have compared the results with analytic results in the case of an ideal reflection and with the programme haupt and found that they fit well. I would appreciate hearing about any comments or other test results obtained from this routine. Thank you Philipp Bernhardt Universit?t Erlangen/N?rnberg Lehrstuhl f?r Kristallographie und Strukturphysik D-91054 Erlangen E-mail: philipp.bernhardt at krist.uni-erlangen.de -------------- next part -------------- /********************************************************************************************** * * Component: Bender * * Written by: Philipp Bernhardt, Januar 10 1999 * * Models a curved neutron guide. The entrance lies in the X-Y plane, * centered on the Z axis. The neutrons will also leave the bender in the X-Y plane at * the z-value r*Win, so you do not have to calculate the real exit coordinates and you do not * need a new arm. The bender is bent to the negative X axis; it behaves like a * parallel guide in the Y axis. * There is no warning, if the parameters are wrong, so please make sure that * - w,h,r,d,Win,k are positive numbers * - k*d is smaller than the width w * - Win is big enough to prevent, that a neutron can pass the bender without a reflection * otherwise you will get wrong results * * INPUT PARAMETERS: * * w: (m) Width at the bender entry and exit * h: (m) Height at the bender entry and exit * r: (m) Radius of the bender * d: (m) Thickness of the partition, which separates the channels * Win: (rad) Angle of the deflection of the whole bender (r*Win is the length of the bender) * k: (AA) Number of channels * R0a,Qca,alphaa,ma,Wa: Parameters, which are describing the mirror at concave side of the bender * R0i,Qci,alphai,mi,Wi: Parameters, which are describing the mirror at convex side of the bender * R0s,Qcs,alphas,ms,Ws: Parameters, which are describing the mirror at the top and bottom side * of the bender * * Example values: w=0.05 h=0.12 r=250 d=0.001 Win=0.04 k=3 ma=3 mi=2 ms=2 ************************************************************************************************/ DEFINE COMPONENT Bender DEFINITION PARAMETERS (w,h,r,d,Win,k,R0a,Qca,alphaa,ma,Wa,R0i,Qci,alphai,mi,Wi,R0s,Qcs,alphas,ms,Ws) SETTING PARAMETERS () OUTPUT PARAMETERS () STATE PARAMETERS (x, y, z, vx, vy, vz, t, s1, s2, p) DECLARE %{ double bk; %} INITIALIZE %{ bk=(w+d)/k; /* width of one channel + thickness d of partition */ %} TRACE %{ double erszei,aktwin,aktzei,zykzei,zykwin,ab,dab,dru,einwin,Q,arg,ref,innref,aeuref,aeuwin,innwin,R,T,Ta; PROP_Z0; if ((fabs(x)>w/2) || (fabs(y)>h/2)) /* neutron is missing the bender */ ABSORB; dru=floor((w/2-x)/bk)*bk-w/2; ab=-dru-x; /* distance between neutron and the concave side of neutron */ R=r-dru; /* radius of the channel for the current neutron */ if (ab>bk-d) /* neutron is hitting the partition */ ABSORB; /* reflections in the XZ-plane */ einwin=atan(vx/vz); /* divergence of the current neutron at the entrance */ dab=R-cos(einwin)*(R-ab); /* maximal distance between neutron and concave side */ aeuwin=acos((R-dab)/R); /* angle of reflection at the concave side */ zykwin=2*aeuwin; T=2*sqrt(R*R-(R-dab)*(R-dab))/sqrt(vx*vx+vz*vz); /* time period between two reflections at */ /* the concave side */ innref=1.0; Q=2*V2K*sqrt(vx*vx+vz*vz)*sin(aeuwin); if (Q<=Qca) aeuref=R0a; else { arg=(Q-ma*Qca)/Wa; if (arg<10) aeuref=.5*R0a*(1-tanh(arg))*(1-alphaa*(Q-Qca)); /* reflectivity at the concave side */ else ABSORB; } if (dab>bk-d) { /* there are also zick-zack-reflections */ innwin=acos(R*cos(aeuwin)/(R-bk+d)); /* angle of reflection at the convex side */ Q=2*V2K*sqrt(vx*vx+vz*vz)*sin(innwin); if (Q<=Qci) innref=R0i; else { arg=(Q-mi*Qci)/Wi; if (arg<10) innref=.5*R0i*(1-tanh(arg))*(1-alphai*(Q-Qci)); /* reflectivity at the convex side */ else ABSORB; } zykwin=2*(aeuwin-innwin); T=2*sqrt(R*R+(R-bk+d)*(R-bk+d)-2*R*(R-bk+d)*cos(zykwin/2))/sqrt(vx*vx+vz*vz); } if (einwin<0) { aktwin=Win-zykwin+aeuwin+einwin; p*=aeuref*innref; Ta=sqrt((R-ab)*(R-ab)+(R-bk+d)*(R-bk+d)-2*(R-ab)*(R-bk+d)*cos(Win-aktwin-zykwin/2))/sqrt(vx*vx+vz*vz)+T/2; } else { aktwin=Win-aeuwin+einwin; p*=aeuref; Ta=sqrt((R-ab)*(R-ab)+R*R-2*(R-ab)*R*cos(Win-aktwin))/sqrt(vx*vx+vz*vz); } while (aktwin>zykwin) { p*=aeuref*innref; aktwin-=zykwin; Ta+=T; } if (aktwin>zykwin/2) { p*=innref; ab=(R*cos(aeuwin-zykwin+aktwin)-R+dab)/cos(aeuwin-zykwin+aktwin); Ta+=sqrt((R-ab)*(R-ab)+(R-bk+d)*(R-bk+d)-2*(R-ab)*(R-bk+d)*cos(aktwin-zykwin/2))/sqrt(vx*vx+vz*vz)+T/2; vx=sin(aeuwin-zykwin+aktwin)*sqrt(vx*vx+vz*vz); vz=vx/tan(aeuwin-zykwin+aktwin); } else { ab=(R*cos(aeuwin-aktwin)-R+dab)/cos(aeuwin-aktwin); Ta+=sqrt((R-ab)*(R-ab)+R*R-2*(R-ab)*R*cos(aktwin))/sqrt(vx*vx+vz*vz); vx=-sin(aeuwin-aktwin)*sqrt(vx*vx+vz*vz); vz=-vx/tan(aeuwin-aktwin); } x=-ab-dru; z=r*Win; t+=Ta; /* reflections at top an bottom (Y axis) */ if (vy!=0.0) { zykzei=h/fabs(vy); /* time period between two reflections */ Q=2*V2K*fabs(vy); if (Q<=Qcs) ref=R0s; else { arg=(Q-ms*Qcs)/Ws; if (arg<10) ref=.5*R0s*(1-tanh(arg))*(1-alphas*(Q-Qcs)); /* reflectivity at top and bottom */ else ABSORB; } erszei=(vy/fabs(vy)*h/2-y)/vy; /* time till neutron hit the top or bottom side for the first time */ if (erszeizykzei) { p*=ref; aktzei-=zykzei; vy*=-1; } y=-vy/fabs(vy)*h/2+aktzei*vy; } else y+=Ta*vy; } %} FINALLY %{ %} END From kristian.nielsen at risoe.dk Fri Jan 22 08:35:20 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 22 Jan 1999 08:35:20 +0100 Subject: order of moving and rotating In-Reply-To: <36A478CA.D4256100@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: <01J6U2N5SK528X73N4@risoe.dk> > Last year in one of the mails in this list Kristian or Kim mentioned > that a general single crystal sample is in work and will be available > 1999. When will that be? Unfortunately not in the next few months, since we have not yet had much time to look at samples. Of course it is possible that somebody else will beat us to it, maybe using existing code from other simulation packages. We already had the fermi chopper from Andrew Garrett and the bender from Philipp Bernhardt. Anyway, we try to work on extending McStas first in the directions that are needed by the users, so requests like yours is very useful input. We will extend the support of sample components in McStas as soon as possible. - Kristian. From kristian.nielsen at risoe.dk Fri Jan 22 09:02:46 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 22 Jan 1999 09:02:46 +0100 Subject: Bender In-Reply-To: (message from Philipp Bernhardt on Wed, 20 Jan 1999 15:57:26 +0100 (CET)) Message-ID: <01J6U3L665WE8X77XL@risoe.dk> > Date: Wed, 20 Jan 1999 15:57:26 +0100 (CET) > From: Philipp Bernhardt > Hello, > > The following routine is simulating a curved neutron guide (bender). = > It is bent to the negative > X axis. It behaves like a parallel guide in the Y axis. To get a bett= > er transmission coefficient, you can=20 > split the bender into channels. These channels are separated by parti= > tions with the thickness of d. Thank you very much! It is great that we are starting to have this kind of cooperation between the various institutions involved in neutron scattering simulations. I hope that you will permit us to include your routine in the McStas component library? Of course, if you have some notes for the calculations that you could send us to form a basis for a manual entry for the bender, that would be even better ... - Kristian. From Georg_Artus at Physik.TU-Muenchen.DE Fri Jan 22 10:28:03 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Fri, 22 Jan 1999 09:28:03 +0000 Subject: Error in Calculation of absolute Flux (Source_flux) ??? References: <01J6U2N5SK528X73N4@risoe.dk> Message-ID: <36A844A3.377923B4@ph.tum.de> Hello Kristian, a few days ago my colleague Ralph Gilles (he was also at the Riso meeting Nov. 98) started with McStas. Due to 'learning' we detected some problems in calculating the absolute flux with McStas using the component Source_flux! Look at the following simple example: It is just a straight guide with a monitor at the beginning and at the end: DEFINE INSTRUMENT TEST() TRACE COMPONENT source = Source_flux( radius = 0.050, dist = 2.0, xw = 0.02, yh = 0.1, E0 = 81.804, /* = 1A*/ dE = 0.818, flux = 2.542E+13) AT (0,0,0) ABSOLUTE COMPONENT monitor1 = Monitor( xmin = -0.010, xmax = 0.010, ymin = -0.050, ymax = 0.050) AT (0,0,2) ABSOLUTE COMPONENT part1 = Guide2( w1 = 0.02, h1 = 0.1, w2 = 0.02, h2 = 0.01, l = 10.0, R0 = 1.0, Qc = 0.0214, alpha = 5.617, mh = 3, mv = 2, W = 0.0033) AT (0,0,2.0) ABSOLUTE COMPONENT monitor2 = Monitor( xmin = -0.010, xmax = 0.010, ymin = -0.050, ymax = 0.050) AT (0,0,12) ABSOLUTE END Let's compare the results with the same instrument, but now the guide is focusing (exit height is now 8cm instead of 10cm): DEFINE INSTRUMENT TEST() TRACE COMPONENT source = Source_flux( radius = 0.050, dist = 2.0, xw = 0.02, yh = 0.1, E0 = 81.804, /* = 1A*/ dE = 0.818, flux = 2.542E+13) AT (0,0,0) ABSOLUTE COMPONENT monitor1 = Monitor( xmin = -0.010, xmax = 0.010, ymin = -0.050, ymax = 0.050) AT (0,0,2) ABSOLUTE COMPONENT part1 = Guide2( w1 = 0.02, h1 = 0.1, w2 = 0.02, h2 = 0.008, l = 10.0, R0 = 1.0, Qc = 0.0214, alpha = 5.617, mh = 3, mv = 2, W = 0.0033) AT (0,0,2.0) ABSOLUTE COMPONENT monitor2 = Monitor( xmin = -0.010, xmax = 0.010, ymin = -0.040, ymax = 0.040) AT (0,0,12) ABSOLUTE END McStas: Transmission (%) Flux at Monitor2 (units ?) straight 3.43 3.42E+08 focusing 2.87 2.87E+08 Transmission = Flux at Monitor2 / Flux at Monitor1 Flux at Monitor1 = 9.977E+09 Going from a straight to a focusing guide the transmission should decrease, because the average angle between a neutron trajectory an the top and bottom face of the guide increases and reflection gets less probable. But the flux at the exit of the guide should increase due to focusing! It seems as if McStas calculates the flux proportional to the transmission. For comparison look at the results for the same guide system calculated with Beamline (J. Cook): Beamline: Transmission (%) Flux at Monitor2 (n/cm**2/AA/s) straight 3.5 1.75E+09 focusing 2.9 1.82E+09 The transmissions fit well (as we have verified with several other guide systems). Small differences can be explained by the different handling of the mirror reflectivity. Here the absolute flux increases going from straight to focusing guide. Also the fluxes computed by both programs don't match. This is why I am not sure, what the units of the fluxes calculated with McStas are and how they are calculated. Due to an erlier discussion about this matter on this newsgroup (11/23/98) I expected it to be n/cm**2/s/AA/ster. " > 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). " To get more insight, I tried a simple test without guide: A small source with radius 1cm and monitor1 of 10cm*10cm in a distance of 1m. For this example the flux at the monitor can be calculated by hand: Fi = Q * o * Aq / Ai Fi = flux at monitor1 (n/cm**2/s/AA) Q = brightness of source (n/cm**2/s/AA/ster) (I used a wavelength dependent Q which was calculated for our beamline at FRMII) o = solid angle (here 0.01 ster) Aq = Area of source (here pi*cm**2) Ai = Area of detector (100 cm**2) Here the numbers: Wavelength (AA) 0.5 1.0 2.0 3.0 Flux calc. by hand 7.5E+08 8.0E+09 2.4E+09 4.2E+08 Flux Beamline 7.5E+08 8.0E+09 2.4E+09 4.2E+08 Flux McStas 3.7E+08 8.0E+09 4.8E+09 1.3E+09 While the fluxes calculated by hand and calulated by Beamline fit well, from the numbers it seems as if McStas calculates fluxes with units n/cm**2/s! If we now add a guide to the system above the flux Ff (n/cm**2/s/AA) and the end of the guide can be calculated as Ff = nf / Af nf = t * ni ni = Q * o * Aq => Ff = t * Q * o * Aq / Af Af = Area of guide exit (=area of monitor2) nf = neutrons reaching monitor2 ni = neutrons reaching monitor1 t = transmission of guide The above formula reproduces the fluxes calculated by Beamline perfectly. It seems as if McStas calculates the absolute flux proportional to the overall transmission, which is not always correct. Also I'm slightly confused about the units. Best wishes, Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Fri Jan 22 13:02:34 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Fri, 22 Jan 1999 13:02:34 +0100 Subject: Error in Calculation of absolute Flux (Source_flux) ??? In-Reply-To: <36A844A3.377923B4@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: <01J6UBYHXD748X7I94@risoe.dk> > Look at the following simple example: It is just a straight guide with a > monitor at the beginning and at the end: > COMPONENT part1 = Guide2( > h1 = 0.1, > h2 = 0.01, I think you have a typo here (or else I did not understand you properly). The guide entrance is 10cm high, but the exit is 1cm. > Let's compare the results with the same instrument, but now the guide is > focusing (exit height is now 8cm instead of 10cm): > COMPONENT part1 = Guide2( > h1 = 0.1, > h2 = 0.008, The exit height is in fact 0.8 cm! I think this probably accounts for some of your confusion. Fortunately, errors like this will be easy to detect with the new graphics display program that has already been finished and will be in the next release (let me know if you want a pre-release copy to play with). Anyway, I think that some of your points can still be discussed. > McStas: Transmission (%) Flux at Monitor2 (units ?) > > straight 3.43 3.42E+08 > focusing 2.87 2.87E+08 > > Transmission = Flux at Monitor2 / Flux at Monitor1 > Flux at Monitor1 = 9.977E+09 Hm. I am starting to think that I may have mislead you about fluxes in McStas. The ONLY place the notion of flux is used in McStas is in the "flux" parameter of Source_flux. All the monitors simulate real monitors/detectors, and compute neutron counts, not neutron fluxes. Depending on your viewpoint, you can say that you are simulating a one second experiment; then the monitors count neutrons per second. What this means is that if you want the flux in n/cm**2, you need to divide by the area of the monitor. Since the flux will probably depend on the position, you really need to use a position-sensitive detector and divide each bin by the pixel area. I suspect that the McStas flux values given above are in fact the "raw" counts in monitor2. When I divide by the monitor area, I get the following numbers: Flux [neutrons/cm**2] straight 3.43 1.71E7 focusing 2.87 1.79E7 These numbers match well with the Beamline results when compared relatively. To get the units in neutrons/AA, it would be necessary to use an energy sensitive detector and divide each bin by its wavelength range. > calculated with McStas are and how they are calculated. Due to an erlier > discussion about this matter on this newsgroup (11/23/98) I expected it > to be n/cm**2/s/AA/ster. Yes. That is the unit of the input parameter to the source. The unit for the detector outputs is just counts (or counts/sec, if you like). I am sorry about the confusion here. > While the fluxes calculated by hand and calulated by Beamline fit well, > from the numbers it seems as if McStas calculates fluxes with units > n/cm**2/s! As I said above, it is in fact just n/s, to get the 1/cm**2/AA you need to use an energy sensitive detector and do the computation by hand. I hope this clarifies matters? Otherwise, please ask again. Do you think the way the monitors in McStas work should be changed to handle flux like in Beamline, and if so, why? - Kristian. From kristian.nielsen at risoe.dk Fri Jan 22 12:19:53 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 22 Jan 1999 12:19:53 +0100 Subject: McStas installation and questions In-Reply-To: <199901191625.QAA18936@elvira2.ill.fr> (message from emmanuel farhi on Tue, 19 Jan 1999 16:25:47 +0000 (GMT)) Message-ID: > As I already mentioned in a previous mail, I'm deseperatly trying to install > McStas program on my account. I'm not root on our machines, and it doesn't seems > to be so easy as written in the manual ! Sorry that I took so long to answer, but thinks have been a bit hectic this week due to major restructuring of the department. If security regulations etc. permits you to, you could supply me with an account on the machines and I could log in myself and investigate (assuming this is not impossible because of firewalls). Otherwise we will have to use e-mail debugging; I will try to answer subsequent emails quickly. > 1a- First, I tryied to install the program on HP two HP stations. The first one > is a > hp9000s800 bi-processor machine. In that case, an error appears in > pre-processing when compiling ('make', after 'configure > --prefix=/home/tas/farhi'), as reported in the previous mail : Using the prefix in this way to avoid needing root privileges should be fine. > gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' > -DCC_HAS_PROTOS=1 -DDEBUG=0 instrument.tab.c > as: "/var/tmp/cca11970.s", line 2786: error 1052: Directive name not recognized > - PARAM Now this is a strange error, since it happens in the assembler! I am really tempted to suggest a problem with the installation of the gcc compiler on this machine. Is it possible to compile other C programs with gcc on the HP? Perhaps there might be a problem if the gcc compiler is using the HP assembler? Anyway, you could try setting the environment variable CC before running configure, one of these commands should work depending on your shell: setenv CC cc CC=cc ; export CC This will only work if you bought the optional ANSI C compiler for the HP. > gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' > -DCC_HAS_PROTOS=1 -DDEBUG=0 instrument.tab.c > In file included from > /usr/local/lib/gcc-lib/hppa1.1-hp-hpux9.03/2.6.3/include/stdlib.h:231, > from mcstas.h:59, > from instrument.y:70: > /usr/include/pwd.h:29: parse error before `int32_t' This is also a bit strange since it happens in the system include files. Again, I tend to suspect a problem with the compiler installation.But try to add the following line at the top of the file "mcstas.h": #include I have a hunch that might just work. If it does, tell me and I will try to find a portable way to fix this problem. You might also try the CC trick on this machine. > 2- After those two uneffective trials, I turned to a SGI machine iris4d. > Compiling is nearly ok : configure+make, with warnings as follows : Compilation seems to run fine. > cannot load /opt/imake/bin/install (bu24):No such file or directory This is suspicious, since it is trying to run /opt/imake/bin/install which is the path returned by the configure run on the HP! The problem is that "./configure" builds a cache file the first time it is run, and subsequent runs do not actually configure but just read previous results from the cache. Maybe you used the same network-mounted directory for the HP and SGI compilations, or perhaps copied the directory from the HP to the SGI instead of using a freshly unpacked distribution? In this case try again on the SGI either from a newly unpacked distribution, or delete the cache file: rm config.cache before "./configure" and "make install". Anyway, it is not too difficult to do the install manually. While in the main mcstas directory, execute the commands cp mcstas gscan mcdisplay /home/tas/farhi/bin/ cp lib/* /home/tas/farhi/lib/mcstas/ chmod +x /home/tas/farhi/bin/mcstas chmod +rx /home/tas/farhi/bin/gscan chmod +rx /home/tas/farhi/bin/mcdisplay chmod +r /home/tas/farhi/lib/mcstas/* Replace /home/tas/farhi with the relevant directory if necessary. > beeing root or needing some 'hieroglyphic' commands ? Are there some already > compiled versions for HP or SGI ? If the above does not work I have HP binaries that I could send you, and I can produce SGI binaries as well. But hopefully I can fix McStas so that later versions compile out of the box on your machines also. > Ian Anderson is now discussing your coming in Marsh, but I'd like to play with > your toy before. I'd like also to indicate than a deeply improved version of Yes I think we should get McStas up and running at the ILL as much as possible before the visit so that we can utilize the time in the best possible way. > MFit/Mview is now available on ILL/TAS group Web page (which becomes an official > archive site for those Matlab stuff: http://www.ill.fr/tas). > > I now began to think about a graphic user interface between MFit/Mview and > McStas (if I can ever make this latter work !), that would enable to build > instruments easely, to pre-process mcstas, and compile gcc Monte Carlo program, > simulate scans and finally display results, all mouse-driven, if > possible. This sounds very exiting! I hope that you get started on this project, and I will do my best to support with guidance, extensions to McStas, etc. I hope the above helps, please write back and tell me how it worked, and I will promise a speedy reply. - Kristian. From farhi at ill.fr Thu Jan 14 12:20:04 1999 From: farhi at ill.fr (Emmanuel Farhi (71 83)) Date: Thu, 14 Jan 1999 12:20:04 +0100 Subject: Installing McStas at ILL Message-ID: Hello, I'm now trying to install McStas at ILL, in order to try it and compare with our own tools. But I've got problems to compile it. The machine is an HP BiProcessor, with HP-UX. HOSTTYPE=hp9000s800 the .configure step is the following % ./configure --prefix=/home/tas/farhi loading cache ./config.cache checking for gcc... (cached) 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... (cached) yes checking whether gcc accepts -g... (cached) no checking for a BSD compatible install... (cached) /opt/imake/bin/install -c checking for perl... (cached) /usr/contrib/bin/perl checking for gcc option to accept ANSI C... (cached) -DCC_HAS_PROTOS creating ./config.status creating Makefile But an error occurs at compilation : % make install ./mkinstalldirs /home/tas/farhi/bin /home/tas/farhi/lib /home/tas/farhi/lib/mcstas gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 instrument.tab.c as: "/var/tmp/cca12321.s", line 2786: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca12321.s", line 2816: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca12321.s", line 2850: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca12321.s", line 2918: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca12321.s", line 2979: error 1052: Directive name not recognized - PARAM *** Error exit code 1 Stop. What can be done ? or perhaps you already have compiled versions for HP ? Thanks... Emmanuel Farhi. -------------------------------------------- Dr. Eng. Emmanuel FARHI, \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ From farhi at ill.fr Tue Jan 19 17:25:47 1999 From: farhi at ill.fr (emmanuel farhi) Date: Tue, 19 Jan 1999 16:25:47 +0000 (GMT) Subject: McStas installation and questions Message-ID: <199901191625.QAA18936@elvira2.ill.fr> Hello, As I already mentioned in a previous mail, I'm deseperatly trying to install McStas program on my account. I'm not root on our machines, and it doesn't seems to be so easy as written in the manual ! 1a- First, I tryied to install the program on HP two HP stations. The first one is a hp9000s800 bi-processor machine. In that case, an error appears in pre-processing when compiling ('make', after 'configure --prefix=/home/tas/farhi'), as reported in the previous mail : biceps~farhi 26> make gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 instrument.tab.c as: "/var/tmp/cca11970.s", line 2786: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca11970.s", line 2816: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca11970.s", line 2850: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca11970.s", line 2918: error 1052: Directive name not recognized - PARAM as: "/var/tmp/cca11970.s", line 2979: error 1052: Directive name not recognized - PARAM *** Error exit code 1 Stop. 1b- Then I passed on an other HP machine, a mono-processor hp9000s800. An error also occurs, but different : elvira2~farhi 26> make gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 instrument.tab.c In file included from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux9.03/2.6.3/include/stdlib.h:231, from mcstas.h:59, from instrument.y:70: /usr/include/pwd.h:29: parse error before `int32_t' /usr/include/pwd.h:29: warning: no semicolon at end of struct or union /usr/include/pwd.h:31: parse error before `}' /usr/include/pwd.h:67: parse error before `int32_t' /usr/include/pwd.h:67: warning: no semicolon at end of struct or union /usr/include/pwd.h:69: parse error before `}' /usr/include/pwd.h:80: warning: parameter names (without types) in function declaration *** Error exit code 1 Stop. Note : gcc, bison and perl are installed on both machines. 2- After those two uneffective trials, I turned to a SGI machine iris4d. Compiling is nearly ok : configure+make, with warnings as follows : gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 instrument.tab.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 lex.yy.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 debug.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 memory.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 list.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 symtab.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 coords.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 rotation.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 cexp.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 position.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 file.c gcc -I. -I. -c -O2 -DMC_SYS_DIR='"'/home/tas/farhi/lib/mcstas'"' -DCC_HAS_PROTOS=1 -DDEBUG=0 cogen.c gcc -o mcstas -O2 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 ld: WARNING 84: /usr/public/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.1/libgcc.a is not used for resolving any symbol. ld: WARNING 84: /usr/public/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.1/libgcc.a is not used for resolving any symbol. but final step fails (make install) as follows : mica~farhi 27% make install ./mkinstalldirs /home/tas/farhi/bin /home/tas/farhi/lib /home/tas/farhi/lib/mcstas /opt/imake/bin/install -c mcstas /home/tas/farhi/bin/mcstas cannot load /opt/imake/bin/install (bu24):No such file or directory *** Error code 1 (bu21) So I'm now praying for help. Can't I just simply install those programs, without beeing root or needing some 'hieroglyphic' commands ? Are there some already compiled versions for HP or SGI ? Ian Anderson is now discussing your coming in Marsh, but I'd like to play with your toy before. I'd like also to indicate than a deeply improved version of MFit/Mview is now available on ILL/TAS group Web page (which becomes an official archive site for those Matlab stuff: http://www.ill.fr/tas). I now began to think about a graphic user interface between MFit/Mview and McStas (if I can ever make this latter work !), that would enable to build instruments easely, to pre-process mcstas, and compile gcc Monte Carlo program, simulate scans and finally display results, all mouse-driven, if possible. Bye. EF. ************************************************************************* Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ Institut Laue Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Tel (33) 04 76 20 71 83. \__U_/ From Georg_Artus at Physik.TU-Muenchen.DE Fri Jan 22 14:21:26 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Fri, 22 Jan 1999 13:21:26 +0000 Subject: Error in Calculation of absolute Flux (Source_flux) ??? References: <01J6UBYHXD748X7I94@risoe.dk> Message-ID: <36A87B56.CF5A647B@ph.tum.de> Hello, > I think you have a typo here (or else I did not understand you > properly). The guide entrance is 10cm high, but the exit is 1cm. Ooops! I checked the real input file and there the numbers were correct! Probably I copied wrong files from another directory or so. Nevertheless I checked the input files again, compiled and started them with correct heights and the results are still those I wrote in my last mail. > Hm. I am starting to think that I may have mislead you about fluxes in > McStas. The ONLY place the notion of flux is used in McStas is in the > "flux" parameter of Source_flux. All the monitors simulate real > monitors/detectors, and compute neutron counts, not neutron fluxes. > Depending on your viewpoint, you can say that you are simulating a one > second experiment; then the monitors count neutrons per second. This starts clearifying things. The misleading thing was in fact the answer to my question, | V " > 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). " > What this means is that if you want the flux in n/cm**2, you need to > divide by the area of the monitor. Since the flux will probably depend > on the position, you really need to use a position-sensitive detector > and divide each bin by the pixel area. I suspect that the McStas flux > values given above are in fact the "raw" counts in monitor2. > When I divide by the monitor area, I get the following numbers: > > Flux [neutrons/cm**2] > straight 3.43 1.71E7 > focusing 2.87 1.79E7 > > These numbers match well with the Beamline results when compared relatively. > > To get the units in neutrons/AA, it would be necessary to use an energy > sensitive detector and divide each bin by its wavelength range. Now this all sounds very logical. The latter sounds not easy. What is the wavelength range when you don't have an even distribution (as you have it at the source)? This distribution of course changes after any component. > I hope this clarifies matters? Otherwise, please ask again. Do you think > the way the monitors in McStas work should be changed to handle flux > like in Beamline, and if so, why? It would be extremely useful to have monitors which calculate flux densities! If one (as we have to do it here) wants to compare different complicated guide systems (primary guide, monochromator, secondary guide, sample) the only measure for comparison is absolute flux density. Anything like transmission or n/time doesn't help, since we have to alter all entrance and exit heights, monochromator heights, sample sizes and so on. It would be extremely tedious to get the flux densities by hand! I had about 500 numbers in the last weeks I would have to treat like this! Doing All these calculations by hand is just impossible. If one wants to compare different real instruments, different simulations or the results of different simulation software the three most important numbers are transmission, flux and flux density. May be it would be a good idea to give not only the numbers in the output file but also the according units. If you see the chance of writing a monitor, which computes flux densities automatically, it would be of really great help to us! Many thanks! Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Mon Jan 25 10:09:05 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 25 Jan 1999 10:09:05 +0100 Subject: Error in Calculation of absolute Flux (Source_flux) ??? In-Reply-To: <36A87B56.CF5A647B@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: > > I hope this clarifies matters? Otherwise, please ask again. Do you think > > the way the monitors in McStas work should be changed to handle flux > > like in Beamline, and if so, why? > > It would be extremely useful to have monitors which calculate flux > If you see the chance of writing a monitor, which computes flux > densities automatically, it would be of really great help to us! First we must decide on how "flux" is defined exactly. You mentioned that in Beamline, the flux is given in the units of n/cm**2/AA/s. Now, clearly this value will depend on the position in the beam and the wavelength at which it is computed. So now it is I who is confused about the units, which seems only fair after the confusion you have been through :-) I assume that Beamline gives you the average flux in the area under consideration (eg. monitor/detector area or perhaps guide exit in Beamline?). This makes sense and is easily handled by dividing neutron counts with the monitor area. But what about the wavelength dependence (as you yourself mention)? Can you explain the precise meaning of the Beamline flux numbers you gave, > Beamline: Transmission (%) Flux at Monitor2 (n/cm**2/AA/s) > > straight 3.5 1.75E+09 > focusing 2.9 1.82E+09 in terms of wavelength dependence? More precisely, suppose I have a neutron beam that is uniform on a 1 cm**2 area. The wavelength dependent flux of the beam is given by a function f such that for a given wavelength lambda in AA, the flux of the beam in n/cm**2/AA/s at that lambda is f(lambda). Then what is the flux value corresponding to the Beamline numbers? I can see a couple of possibilities: 1. The average flux in a user supplied wavelength range, i.e. (integral(lmin,lmax) f(l) dl) / (lmax - lmin) 2. The maximum flux, i.e. the maximum of f (hm, that might be non-trivial to compute from monte carlo data) and maybe others, but I would like to know what Beamline does. Once we resolve this issue, I will be happy to provide you with a flux monitor component for McStas. - Kristian. From farhi at ill.fr Fri Jan 22 15:30:17 1999 From: farhi at ill.fr (Emmanuel Farhi (71 83)) Date: Fri, 22 Jan 1999 15:30:17 +0100 Subject: McStas installation and questions In-Reply-To: <01J6UAHUZKSE8X7LJF@risoe.dk> References: <199901191625.QAA18936@elvira2.ill.fr> (message from emmanuel farhi on Tue, 19 Jan 1999 16:25:47 +0000 (GMT)) Message-ID: Hello Kristian, At last, I could compile McStas on mica (SGI machine). parsing instrument (mcstas) and compiling is ok. running simulations by hand seems ok (instrument asks for config parameters). Then I now try to run reference simulations, as listed in Web Pages TAS1 lineup. The first line in log file is # mica~farhi 104% perl gscan.pl 21 ./linup-1 sim/linup_1_50.sim -39,-35 -73 0 1e5 Invalid parameter specification '-39,-35' at gscan.pl line 35. Then I try something else : # gscan 1 21 ./linup-1 sim/linup_1_50.sim -39,-35 -73 0 1e5 Warning: translation table syntax error: Unknown keysym name: ClearLine Warning: ... found while parsing 'ClearLine: delete-to-end-of-line()' Warning: Cannot convert string "-*-screen-medium-r-normal--15-*-*-*-*-*-iso8859-1" to type FontStruct dgl error (protocol): remote machine not DGL capable - macfarhi.ill.fr:0.0 dgl error (default init): default dglopen(macfarhi.ill.fr:0.0,4) returned -13 The main question is then : what is DGL ? And does gscan require graphic display ? Is this error message realy generated by gscan ? I suspect that solution is quite simple (as usual), and I look forward to compare computation results with yours ! Cheers. E. -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From farhi at ill.fr Fri Jan 22 16:20:08 1999 From: farhi at ill.fr (Emmanuel Farhi (71 83)) Date: Fri, 22 Jan 1999 16:20:08 +0100 Subject: McStas installation and questions In-Reply-To: <01J6UAHUZKSE8X7LJF@risoe.dk> References: <199901191625.QAA18936@elvira2.ill.fr> (message from emmanuel farhi on Tue, 19 Jan 1999 16:25:47 +0000 (GMT)) Message-ID: The McStas computation on mica is going on, slowly. ok. Arnaud heiss is coming to Risoe, on TAS6 with Des Mc Morrow. I've talked about TAS1 with him. It could be great to compare McStas results with our 'home' program ResTrax (which is perhaps faster, by really more specific for TAS instruments, and doesn't enable to describe anything as McStas). For this, we need a 'mecanical' description of TAS1 instrument (distances, components, etc) Of course it's in the lineup-1 file for instance, but a drawing is perhaps better (with the exact significance of parameter used). I guess you had to do so when writting lineup files for TAS1... Arnaud might be quite busy on monday, but should have some time on thuesday or wenesday morning. Would it be possible for you to go and find him if you find time to do so ? Thanks !! -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From kristian.nielsen at risoe.dk Mon Jan 25 10:27:32 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 25 Jan 1999 10:27:32 +0100 Subject: McStas installation and questions In-Reply-To: (farhi@ill.fr) Message-ID: Hi Emmanuel, > Hello Kristian, > > At last, I could compile McStas on mica (SGI machine). parsing instrument (mcstas) and compiling is ok. running simulations by hand seems ok (instrument asks for config parameters). Good! Did you find out what the problem was (so that I could improve the installation or clarify in the manual)? Did you give up on the HPs? > # mica~farhi 104% perl gscan.pl 21 ./linup-1 sim/linup_1_50.sim -39,-35 -73 0 1e5 > Invalid parameter specification '-39,-35' at gscan.pl line 35. Ouch! This is using the old syntax from a very old version of McStas, before the first release. Where did you find that example, I will erase it immediately! Hm I guess you found it on the web page, parts of that badly needs an update. The correct new syntax would be something like perl gscan 21 1e5 ./linup-1 sim/linup_1_50.sim PHM=-39,-35 TTM=-73 C1=0 > Then I try something else : > > # gscan 1 21 ./linup-1 sim/linup_1_50.sim -39,-35 -73 0 1e5 > Warning: translation table syntax error: Unknown keysym name: ClearLine > Warning: ... found while parsing 'ClearLine: delete-to-end-of-line()' > Warning: Cannot convert string "-*-screen-medium-r-normal--15-*-*-*-*-*-iso8859-1" to type FontStruct > dgl error (protocol): remote machine not DGL capable - macfarhi.ill.fr:0.0 > dgl error (default init): default dglopen(macfarhi.ill.fr:0.0,4) returned -13 This is just plain wierd ... I think DGL is SGIs own extension to the X Window System (for 3D graphics I guess), I cannot think of any way in which the gscan program would cause this. Maybe you hit a bad key on the keyboard ("ClearLine" ...) by mistake :-) > OK, it's ok. I'm now running tas1-examples batch ... suspens ! Great! > The McStas computation on mica is going on, slowly. ok. Good, do not hesitate to ask again if you need help, or want to tell about your results. > Arnaud heiss is coming to Risoe, on TAS6 with Des Mc Morrow. I've Thanks for the tip; Des has promised to introduce me to Arnaud. > talked about TAS1 with him. It could be great to compare McStas > results with our 'home' program ResTrax (which is perhaps faster, by > really more specific for TAS instruments, and doesn't enable to > describe anything as McStas). For this, we need a 'mecanical' > description of TAS1 instrument (distances, components, etc) Of course > it's in the lineup-1 file for instance, but a drawing is perhaps > better (with the exact significance of parameter used). I guess you > had to do so when writting lineup files for TAS1... Yes, I am sure we can find something suitable. I actually started something similar, but in the opposite direction, for the RESCAL program with Alan Tennant before Christmas. It is a McStas simulation for a RESCAL-type generic instrument that simulates an instrument defined by RESCAL instrument definition parameters. - Kristian. From snphbern at jerry.rommel.stw.uni-erlangen.de Mon Jan 25 10:51:53 1999 From: snphbern at jerry.rommel.stw.uni-erlangen.de (Philipp Bernhardt) Date: Mon, 25 Jan 1999 10:51:53 +0100 (CET) Subject: Bender In-Reply-To: <01J6U3L665WE8X77XL@risoe.dk> Message-ID: On Fri, 22 Jan 1999, Kristian Nielsen wrote: > Thank you very much! It is great that we are starting to have this kind > of cooperation between the various institutions involved in neutron > scattering simulations. > > I hope that you will permit us to include your routine in the McStas > component library? Of course, if you have some notes for the > calculations that you could send us to form a basis for a manual entry > for the bender, that would be even better ... > > - Kristian. > Hello Kristian, Of course you can include the component in the library, but I cannot guarantee, that everything is right. I try to send you some notes for the the calculations. McStas is a fine programme with a very good documentation. I am glad to hear that the next version has a graphical display programme to detect wrong input parameters. - Philipp From Peter_Link at physik.tu-muenchen.de Mon Jan 25 10:17:10 1999 From: Peter_Link at physik.tu-muenchen.de (Peter Link) Date: Mon, 25 Jan 1999 10:17:10 +0100 Subject: McStas and W32 Message-ID: <36AC3696.9550C823@physik.tu-muenchen.de> Dear Kristian Nielsen, at first my congratulations for your and your collegues work. I downloaded McStas last week and started to learn using it. I'm instrument responsible of the future thermal triple axis spektrometer at the Munich FRM II. I plan to simulate my hole instrument using McStas during the following months. I tried the Win32 compilation and I think in basic view it works. Although I'm a little concerned about some compiler warnings ( VC++, Microsoft, WinNT): /usr/share/misc/bison.simple(387) : warning C4013: 'yylex' undefined; Suppose: extern mit Rueckgabetyp int /usr/share/misc/bison.simple(590) : warning C4013: 'yyerror' undefined; Suppose: extern mit Rueckgabetyp int instrument.y(745) : warning C4716: 'yyerror' : has to return a value e:\mcstas\rotation.c(153) : warning C4101: 'k' : unreferenced local variable I think this is due to the exotic enviroment, but perhaps You know some turn arounds. I also wonder whether there exists a possiblility to use front-ends like gscan with Win32? Last but not least I discussed with Georg Artus a collegue here in Munich about source definition. source_flat has a circular face. As my beamtube will have a rectangular nose I ask myself about the best way to implement this. Best regards Peter -- ****************************************** Dr. P. Link IPC Uni G?ttingen Au?enstelle Garching Neue Forschungs- Neutronenquelle Garching ZBE- FRM II- Bau 85747 Garching Tel. 089 2891 4622 Fax. 089 2895 4622 mailto: plink at physik.tu-muenchen.de ****************************************** From kristian.nielsen at risoe.dk Mon Jan 25 12:55:17 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 25 Jan 1999 12:55:17 +0100 Subject: McStas and W32 In-Reply-To: <36AC3696.9550C823@physik.tu-muenchen.de> (message from Peter Link on Mon, 25 Jan 1999 10:17:10 +0100) Message-ID: Dear Peter Link, > I tried the Win32 compilation and I think in basic view it works. > Although I'm a little concerned about some compiler warnings ( VC++, > Microsoft, WinNT): > > /usr/share/misc/bison.simple(387) : warning C4013: 'yylex' undefined; > Suppose: extern mit Rueckgabetyp int > /usr/share/misc/bison.simple(590) : warning C4013: 'yyerror' undefined; > Suppose: extern mit Rueckgabetyp int > instrument.y(745) : warning C4716: 'yyerror' : has to return a value > e:\mcstas\rotation.c(153) : warning C4101: 'k' : unreferenced local > variable These warnings sound completely harmless. I think the tradition in the Unix world is to have less strict compilers than in the Windows world. > I also wonder whether there exists a possiblility to use front-ends like > gscan with Win32? The possibility is there, but we have no experience with what kind of problems may turn up. To use gscan, the program Perl is needed. According to my information, this is available for Windows 95/98/NT. So with luck you could just install Perl and gscan should work. The graphics frontends also use the PGPLOT graphics library and an interface betwenn PGPLOT and Perl. PGPLOT has been ported to Windows, I do not know about the Perl interface. In short, if you can install the required supporting programs and libraries, in theory you should be able to use the front-ends in Windows. Unfortunately, we do not use Windows here at Ris? for McStas, but if you have any problems I will do my best to help you. > Last but not least I discussed with Georg Artus a collegue here in > Munich about source definition. source_flat has a circular face. As my > beamtube will have a rectangular nose I ask myself about the best way to > implement this. The quick way (which I have used myself on occasion) is to put a rectangular slit just in front of the circular source, though you will waste a bit of computation time in this way. Alternatively, it is a two-minute modification to the Source_flat component to make it simulate a rectangular source rather than a circular one; I will be happy to write it and send it to you if you need it. Good luck using McStas! - Kristian. From Georg_Artus at Physik.TU-Muenchen.DE Mon Jan 25 15:56:53 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Mon, 25 Jan 1999 14:56:53 +0000 Subject: Error in Calculation of absolute Flux (Source_flux) ??? References: <01J6YCSQWV5E8X7CD8@risoe.dk> Message-ID: <36AC8635.E6C18FA1@ph.tum.de> hello, > First we must decide on how "flux" is defined exactly > > You mentioned that in Beamline, the flux is given in the units of > n/cm**2/AA/s. Now, clearly this value will depend on the position in the > beam and the wavelength at which it is computed. So now it is I who is > confused about the units, which seems only fair after the confusion you > have been through :-) I'm glad that you haven't lost your sense of humour... :-) Here is what beamline does: The user supplies the wavelength limits (from to) in AA and a step size. E.g. 0.9 1.1 0.1 means simulate the instrument at 0.9AA 1.0AA and 1.1AA. The step size is also used as delta lambda for each single wavelength to be calculated. But this value delta lambda is needed only for special calculations like integrated flux (summed over all calculated wavelengths) or capture flux (gold foil activation). For calculation of the flux density at the sample (monitor) it is not needed! E.g. you can provide 1.0 1.0 0.0 as input and the flux density (n/cm**2/s/AA) is still computed correctly. This means to me that all neutrons are started with exactly 1AA. This is physically not meaningful, but for the calculation of the flux density it is ok because the physics of a neutron guide doesn't change much in small wavelength ranges ( 0.0xAA). Also the initial wavelength range doesn't change too much in a guide. This means that Beamline avoids multiplying and afterwards dividing by a given wavelength range. This treatment may not be sufficient when you simulate a more complicated instrument in which the wavelength range is modified (monochromator) or the absolute wavelengths are modified by any physical process. > I assume that Beamline gives you the average flux in the area under > consideration (eg. monitor/detector area or perhaps guide exit in > Beamline?). This makes sense and is easily handled by dividing neutron > counts with the monitor area. Yes, it is the flux density averaged over the complete area (of the monitor or guide exit or sample...) > But what about the wavelength dependence (as you yourself mention)? Can > you explain the precise meaning of the Beamline flux numbers you gave, > > > Beamline: Transmission (%) Flux at Monitor2 (n/cm**2/AA/s) > > > > straight 3.5 1.75E+09 > > focusing 2.9 1.82E+09 > > in terms of wavelength dependence? More precisely, suppose I have a > neutron beam that is uniform on a 1 cm**2 area. The wavelength dependent > flux of the beam is given by a function f such that for a given > wavelength lambda in AA, the flux of the beam in n/cm**2/AA/s at that > lambda is f(lambda). Then what is the flux value corresponding to the > Beamline numbers? In the end 1/AA in the units of the Beamline output comes from the input of the source brightness in units of n/cm**2/s/AA/ster. In Beamline the brightness is calculated from a function brightness(wavelength). I got this function by fitting the MCNP-data I got for the D2O directly at the nose of my beamline. You can transform the McStas output monitor_I to the Beamline output by dividing by the monitor area and teh wavelength range (2*dE in AA). It fits very well! We have tried it with several guides. > I can see a couple of possibilities: > > 1. The average flux in a user supplied wavelength range, i.e. > (integral(lmin,lmax) f(l) dl) / (lmax - lmin) That sounds ok! But getting lmax and lmin will be a problem? > 2. The maximum flux, i.e. the maximum of f (hm, that might be > non-trivial to compute from monte carlo data) > > and maybe others, but I would like to know what Beamline does. > Once we resolve this issue, I will be happy to provide you with a flux > monitor component for McStas. I hope this all is not too much trouble! I am glad that I have to think again about things I thought to be a matter of course. They are not... Probably you know already that Ralph Gilles (vis a vis to my desk) and Peter Link (next door) are starting with McStas! Best Wishes, Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Wed Jan 27 08:38:41 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 27 Jan 1999 08:38:41 +0100 Subject: Error in Calculation of absolute Flux (Source_flux) ??? In-Reply-To: <36AC8635.E6C18FA1@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: > Here is what beamline does: Ok thanks for the explanation of Beamline. > You can transform the McStas output monitor_I to the Beamline output by > dividing by the monitor area and teh wavelength range (2*dE in AA). It > fits very well! We have tried it with several guides. Ok. I have modified the Monitor component to create a Monitor_flux component that does exactly this. It takes two extra input parameters: the lower and upper limit of the wavelength range to consider (eg. lmin = sqrt(81.81/(E+dE)), lmax = sqrt(81.81/(E-dE)) in your case). I think that letting the user supply the wavelength range is more general than just taking the values from the source component (ie. what happens if another source component with no dE is used?). I tried running the two test instruments you send in the first mail, modified to use the Monitor_flux component (and with the height typo fixed). The results, including the correct units, match those you gave for Beamline: straight 3.5 1.69E+09 focusing 2.9 1.80E+09 I put the Monitor_flux, as well as the modified test instruments, on our web page at http://neutron.risoe.dk/mcstas/support/artus/ The unit for lmin and lmax of the Monitor_flux component is AA and the output is in n/cm**2/AA, which is what you need, I think. There is starting to be a lot of inconsistency between using neutron energies in meV and neutron wavelengths in AA in the different components, but that I something I have to sort out in some way. One idea I have is to build in knowledge about common units in McStas so that the user can just say "20 [meV]" or "4 [AA]" or "2000 [m/s]" and McStas will sort it out by itself, but that is for the future. > I hope this all is not too much trouble! I am glad that I have to think > again about things I thought to be a matter of course. They are not... > > Probably you know already that Ralph Gilles (vis a vis to my desk) and > Peter Link (next door) are starting with McStas! No trouble at all, we measure the success of McStas to a large degree on the extent to which it is used by others. So we are very happy that you are using the program, and quite willing to help. And as you, I find it very useful to discuss these things and get to think about them, I have now a much clearer idea how to handle absolute flux better in McStas in future releases. - Kristian. From Peter_Link at physik.tu-muenchen.de Mon Jan 25 16:39:25 1999 From: Peter_Link at physik.tu-muenchen.de (Peter Link) Date: Mon, 25 Jan 1999 16:39:25 +0100 Subject: McStas and W32 References: <01J6YILT0YDU8X7DLP@risoe.dk> Message-ID: <36AC902D.54E79673@physik.tu-muenchen.de> > The quick way (which I have used myself on occasion) is to put a > rectangular slit just in front of the circular source, though you will > waste a bit of computation time in this way. Alternatively, it is a > two-minute modification to the Source_flat component to make it simulate > a rectangular source rather than a circular one; I will be happy to > write it and send it to you if you need it. > Thank You for your offer to help. In principle I would like to use this as an exercise, how to extend McStas. This, because I need certainly components which are ( up to now ) not in the package like a double focussing monochromotor made of a rather big number of crystals ( -100). On the other hand I'm not sure to have all the tools one needs to do so. Bye for now, until the first real problems, Peter -- ****************************************** Dr. P. Link IPC Uni G?ttingen Au?enstelle Garching Neue Forschungs- Neutronenquelle Garching ZBE- FRM II- Bau 85747 Garching Tel. 089 2891 4622 Fax. 089 2895 4622 mailto: plink at physik.tu-muenchen.de ****************************************** From farhi at ill.fr Mon Jan 25 20:16:35 1999 From: farhi at ill.fr (Emmanuel Farhi (71 83)) Date: Mon, 25 Jan 1999 20:16:35 +0100 Subject: News... In-Reply-To: <01J6YDFMLXM48X7KJ2@risoe.dk> References: (farhi@ill.fr) Message-ID: Hello Kristian First simulations are now completed (tas1-scans script), and exactly give same results as yours at Risoe (according to graphs shown on web page). Anyway computations seem quite slow, but it can surely be improved in the future (better compiling, and perhaps code optimisation, but I guess you already looked at it !). I plan to write an IN14 description file tomorrow, in order to compare results with the ones given by our Restrax program. I really think McStas is excellent, and I thank you again for it. The HP compilation problem still exists, and I'm currently running on an SGI machine... About the strange 'ClearLine' error message, there is already a gscan program on SGI, that requires X display... But as tas1 only uses perl script, it's ok. Rescal program for Matlab is currently used here at ILL by TAS users, and in Montpellier University where I was last year. It's good for 'phenomenological' description of instruments, and usually enough for a modelisation of instrument ellipsoid. Cheers. Emmanuel. -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From farhi at ill.fr Tue Jan 26 18:45:31 1999 From: farhi at ill.fr (Emmanuel Farhi (71 83)) Date: Tue, 26 Jan 1999 18:45:31 +0100 Subject: McStas installation and questions In-Reply-To: <01J6YDFMLXM48X7KJ2@risoe.dk> References: (farhi@ill.fr) Message-ID: Hello, I'm now designing IN14 instrument description for McStas. Are there some new source files (shape, or energy distribution not flat, for instance Maxwelian,...) or other components in general ? Future versions of McStas should also handle neutron spin (state and direction). Cheers. E. -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From kristian.nielsen at risoe.dk Wed Jan 27 08:51:34 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 27 Jan 1999 08:51:34 +0100 Subject: McStas installation and questions In-Reply-To: (farhi@ill.fr) Message-ID: > I'm now designing IN14 instrument description for McStas. Are there > some new source files (shape, or energy distribution not flat, for > instance Maxwelian,...) or other components in general ? Future > versions of McStas should also handle neutron spin (state and > direction). Currently, we have only circular sources with flat energy distributions, since we have not needed anything else yet. You can get a rectangular source by putting a slit just in front of a circular one. If you want, you could try to modify the Source_flat component yourself as an exercise in writing McStas components, i.e. to use a rectangular shape and multiply the weight by a Maxwelian. Or if you prefer, I could do it for you (it would only involve adding a few lines). I talked to Arnaud Hiess. He gave me a quick overview of ResTraxx and of the departments at the ILL, both of which were very helpful. We then went through the instrument definition for TAS1 and created a drawing with all the relevant dimensions and parameters. Of course, if we missed anything, just ask again. Good luck, - Kristian. From farhi at ill.fr Wed Jan 27 11:04:38 1999 From: farhi at ill.fr (Emmanuel Farhi (71 83)) Date: Wed, 27 Jan 1999 11:04:38 +0100 Subject: Sources In-Reply-To: <01J712OCAK5S8X83C1@risoe.dk> References: (farhi@ill.fr) Message-ID: Hello, Yes, you're right, creating a rectangular source is very easy (just change angle and radius directly into dimentions for the two first random numbers). For a Maxwellian distribution, I hesitate between using a flat energy distribution, but weightening with p=cte.exp(-E/T), or using E = -T log(rand01/cte), in order to produce more neutrons of certain energies. The first solution is simpler, but some neutrons with low weight are not very useful. The second solution appears to me more efficient in computation. What do you think about it ? Cheers. E. -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From kristian.nielsen at risoe.dk Wed Jan 27 11:29:47 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 27 Jan 1999 11:29:47 +0100 Subject: Sources In-Reply-To: (farhi@ill.fr) Message-ID: > Yes, you're right, creating a rectangular source is very easy (just > change angle and radius directly into dimentions for the two first > random numbers). For a Maxwellian distribution, I hesitate between > using a flat energy distribution, but weightening with > p=cte.exp(-E/T), or using E = -T log(rand01/cte), in order to produce > more neutrons of certain energies. The first solution is simpler, but > some neutrons with low weight are not very useful. The second solution > appears to me more efficient in computation. What do you think about > it ? My thoughts on the matter are quite complex! I have been thinking for a long time about writing a much better source component. The component would take a tabulated energy distribution as an input parameter, so it could be flat, Maxwellian, measured or anything desired. It would use adaptive importance sampling to select the neutron energy, so that it would automatically select a "useful" energy for most neutrons. I have most of the details in place, but I do not know when I will get the time to actually implement it; hopefully sometimes this spring. I think you are definitely right that the correct approach to selecting the neutron energy is the key to good performance. But which approach is the right one will in general depend on the application. For example, in a full tripple-axis setup, it will be necessary to select neutrons energies from a small range appropriate to the monochromator setting. To test a guide system, a wide range might be appropriate. In any case, the way to select neutron energies is to pick the energy from whatever random number distribution gives the best efficiency, and then adjust the weight accordingly to match a flat or Maxwellian or whatever distribution. - Kristian. From Georg_Artus at Physik.TU-Muenchen.DE Thu Jan 28 11:17:41 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Thu, 28 Jan 1999 10:17:41 +0000 Subject: Error in Calculation of absolute Flux (Source_flux) ??? References: <01J7128DFQD68X83C1@risoe.dk> Message-ID: <36B03945.BC5A4A8C@ph.tum.de> Hello, > Ok. I have modified the Monitor component to create a Monitor_flux > component that does exactly this. It takes two extra input parameters: > the lower and upper limit of the wavelength range to consider (eg. lmin > = sqrt(81.81/(E+dE)), lmax = sqrt(81.81/(E-dE)) in your case). I think > that letting the user supply the wavelength range is more general than > just taking the values from the source component (ie. what happens if > another source component with no dE is used?). Thank you very much! This will help a lot. Yesterday we have started several jobs and up to now all fits well! May be you are right that it is better to let the user supply the limits. > The unit for lmin and lmax of the Monitor_flux component is AA and the > output is in n/cm**2/AA, which is what you need, I think. There is > starting to be a lot of inconsistency between using neutron energies in > meV and neutron wavelengths in AA in the different components, but that > I something I have to sort out in some way. One idea I have is to build > in knowledge about common units in McStas so that the user can just say > "20 [meV]" or "4 [AA]" or "2000 [m/s]" and McStas will sort it out by > itself, but that is for the future. Yes, the two units, AA and meV, don't make things easier. Your solution seems good to me. Depending on the instrument one is either used to AA or eV. I have programmed the calculation from AA to meV in the INITIALIZE section. I have another suggestion: All instruments are built in vacuum, which normally is not the case. It would be helpful if you had a chance to say, that you have e.g. 2m He, 5mm Al and 6m Air in the beam. In a first approximation the location of teh material in the beam is not important. This is just to get an estimate for the loss due to absorption by materials. Other materials like Mg, PG, Be, Glass... could also be interesting. To realize this with the Filter component is possible, but still affords calculating many things by hand. Best wishes, Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen FRM-II Reaktorstation D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From bernhard at amos.krist.uni-erlangen.de Tue Feb 2 17:16:15 1999 From: bernhard at amos.krist.uni-erlangen.de (Philipp Bernhardt) Date: Tue, 02 Feb 1999 17:16:15 +0100 (MET) Subject: No subject In-Reply-To: <01J6U3L665WE8X77XL@risoe.dk> Message-ID: Hello, I have used McStas with following configuration: DEFINE INSTRUMENT FE(WEL) TRACE COMPONENT a1 = Arm() AT (0,0,0) ABSOLUTE COMPONENT source = Source_rectangular( xw=0.1, yw=0.1, lambda=WEL, gammax=0.002, gammay=0.002, dtx=0.0004) AT (0,0,0) RELATIVE a1 ROTATED (0,0,0) RELATIVE a1 COMPONENT fermi=Fermi_Chopper( rad=0.05, nu=400, delta=0.000200, ymin=-0.05, ymax=0.05, w=0.005, n=100, r_slit=-100) AT (0,0,0.1) RELATIVE a1 ROTATED (0,0,0) RELATIVE a1 COMPONENT mon=TOF_monitor( xmin=-1,xmax=1,ymin=-1,ymax=1, nchan=1000, dt=0.1, filename="tim.mon") AT (0,0,0.2) RELATIVE a1 ROTATED (0,0,0) RELATIVE a1 END Source_rectangular is producing neutrons with the wavelength of lambda at the positon (+-xw,+-yw,0) with a maximal divergence of gamma_x and gamma_y and a time between 0 and dtx. (see attachment) When I use the option --trace, I get, for example, following result: ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.00524055, -0.0428509, 0, -2.85016, -2.11707, 1977.96, 0.000270516, 0, 0, 1 COMP: "fermi" STATE: -0.00825353, -0.0428509, -0.1, -4.48881, -2.11707, 1977.96, 0.000270516, 0, 0, 1 STATE: -0.00836861, -0.0429051, -0.0492947, -4.48881, -2.11707, 1977.96, 0.000296151, 0, 0, 1 ABSORB: LEAVE: STATE: -0.00836861, -0.0429051, -0.0492947, -4.48881, -2.11707, 1977.96, 0.000296151, 0, 0, 1 The x and vx value have changed between the component source and fermi without any reason (there should only be a translation in the z direction). What could be the reason for this change? I have another question: Is it possible to use functions in a component and how could that be realized? Thanks for any help. Philipp --------------------------- Philipp Bernhardt Lehrstuhl f?r Kristallographie und Strukturphysik email: philipp.bernhardt at krist.uni-erlangen.de -------------- next part -------------- DEFINE COMPONENT Source_rectangular DEFINITION PARAMETERS (xw, yw, lambda, gammax, gammay, dtx) SETTING PARAMETERS () OUTPUT PARAMETERS () STATE PARAMETERS (x, y, z, vx, vy, vz, t, s1, s2, p) DECLARE %{ %} INITIALIZE %{ %} TRACE %{ double gamma_x,gamma_y,vges; x=rand01()*xw-xw/2; y=rand01()*yw-yw/2; z=0.0; gamma_x=2.0*rand01()*gammax*lambda-gammax*lambda; gamma_y=2.0*rand01()*gammay*lambda-gammay*lambda; vges=3955.931/lambda; vz=sqrt(vges*vges/(tan(gamma_x)*tan(gamma_x)+tan(gamma_y)*tan(gamma_y)+1.0)); vx=tan(gamma_x)*vz; vy=tan(gamma_y)*vz; p=1.0; t=rand01()*dtx; %} FINALLY %{ %} END From kristian.nielsen at risoe.dk Wed Feb 3 14:41:26 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Wed, 03 Feb 1999 14:41:26 +0100 Subject: Inter-component transformations In-Reply-To: (message from Philipp Bernhardt on Tue, 02 Feb 1999 17:16:15 +0100 (MET)) Message-ID: <01J7B6X786QI8X95YO@risoe.dk> Hi Philipp, > When I use the option --trace, I get, for example, following result: > > ENTER: > COMP: "source" > STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 > STATE: -0.00524055, -0.0428509, 0, -2.85016, -2.11707, 1977.96, 0.000270516, 0, 0, 1 > COMP: "fermi" > STATE: -0.00825353, -0.0428509, -0.1, -4.48881, -2.11707, 1977.96, 0.000270516, 0, 0, 1 > The x and vx value have changed between the component source and fermi > without any reason (there should only be a translation in the z Indeed, this looks strange. I tried running your example myself, and I could not repeat the strange behaviour: ------------------------------------------------------------------------ bash-2.01$ ./instr1 --trace -n1 -s1 WEL=2 ENTER: [...] COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.0340188, -0.0105617, 0, 4.47967, 4.72242, 1977.95, 0.000364659, 0, 0, 1 COMP: "fermi" STATE: 0.0340188, -0.0105617, -0.1, 4.47967, 4.72242, 1977.95, 0.000364659, 0, 0, 1 [...] ------------------------------------------------------------------------ I have seen something like this before being caused by compiler bugs. I think the pgcc (pentium-optimized compiler) for one got the coordinate transformations wrong with aggressive optimization. Could you try running the example without compiler optimizations, or is there anything special I should do to repeat the results you got? > I have another question: Is it possible to use functions in a component > and how could that be realized? Hm, I am not completely sure I understand what you are asking here. I think you mean to write a complex component, where part of the code is put in a special C function that is part of the component source file? One way is to put the function definition in the DECLARE section: ------------------------------------------------------------------------ DEFINE COMPONENT My_comp [...] DECLARE %{ double foo(double a) { return a*a; } %} [...] TRACE %{ ... foo(vx*vx+vy*vy) ... %} ------------------------------------------------------------------------ In the current version of McStas this may not work if the component is used several times in a single instrument. This will be fixed in a later version, but for now a workaround is to protect the declaration with #define: ------------------------------------------------------------------------ DEFINE COMPONENT My_comp [...] DECLARE %{ #ifndef MY_COMP_DECLARE #define MY_COMP_DECLARE double foo(double a) { return a*a; } #endif %} ------------------------------------------------------------------------ The #ifndef / #endif ensures that the function declaration is only compiled once. Hope this helps, - Kristian. From kristian.nielsen at risoe.dk Thu Feb 4 14:41:10 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Thu, 04 Feb 1999 14:41:10 +0100 Subject: Inter-component transformations In-Reply-To: (message from Philipp Bernhardt on Thu, 04 Feb 1999 11:33:36 +0100 (MET)) Message-ID: <01J7CL78CG3Y8X9VGO@risoe.dk> > I tried to change the the compiler optimation, > but there was no change in the results. I will run the simulation on > another computer this weekend. Don't bother, I found the problem. It turns out you ran into a nasty "off-by-one" bug in the TOF_monitor component. Any neutrons with time-of-flight beyond the upper detector limit would be placed in the position just after the last array element of the detector output, overwriting whatever value was there. Ouch. To fix it, download a new version of the TOF_monitor from http://neutron.risoe.dk/mcstas/support/philipp/TOF_monitor.comp or to do the fix manually: change the line in TOF_monitor.comp (usually found in "/usr/local/lib/mcstas/TOF_monitor.comp") that reads if(i >= nchan) i = nchan; to read if(i >= nchan) i = nchan - 1; I verified that this fixes the problem you saw. I will put this information in the "known bugs" list on the web page on Monday. It also seems to me that the TOF monitor in your instrument has a little too few bins for the 2AA wavelength you ran in the example, but perhaps that was intentional. Thanks for your effort in finding this bug! - Kristian. From bernhard at amos.krist.uni-erlangen.de Thu Feb 4 11:33:36 1999 From: bernhard at amos.krist.uni-erlangen.de (Philipp Bernhardt) Date: Thu, 04 Feb 1999 11:33:36 +0100 (MET) Subject: Inter-component transformations In-Reply-To: <01J7B6X786QI8X95YO@risoe.dk> Message-ID: Hi Kristian, Thank you for your help. I tried to change the the compiler optimation, but there was no change in the results. I will run the simulation on another computer this weekend. Maybe your simulation was to short to see the effect. There is no change of x and vx for the first neutrons, but whenever a neutron can pass the whole instrument without absorbtion, the factor, which is changing x and vx between source and fermi, increases for the following neutrons. I have added the output of the first twenty neutrons with -seed1. The fifth neutron could pass the fermi-component and after that, x and vx values are changed by 1.07...and so on. If you change the variable dt in the component TOF_monitor from 0.1 to 0.7 or bigger the simulation works fine. - Philipp -------------- next part -------------- INSTRUMENT: COMPONENT: "a1" POS: 0, 0, 0, 1, 0, 0, -0, 1, 0, 0, -0, 1 COMPONENT: "source" POS: 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1 COMPONENT: "fermi" POS: 0, 0, 0.1, 1, 0, 0, 0, 1, 0, 0, 0, 1 COMPONENT: "mon" POS: 0, 0, 0.2, 1, 0, 0, 0, 1, 0, 0, 0, 1 INSTRUMENT END: ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.0340188, -0.0105617, 0, 4.47967, 4.72242, 1977.95, 0.000364659, 0, 0, 1 COMP: "fermi" STATE: 0.0340188, -0.0105617, -0.1, 4.47967, 4.72242, 1977.95, 0.000364659, 0, 0, 1 STATE: 0.0341626, -0.0104101, -0.0365092, 4.47967, 4.72242, 1977.95, 0.000396758, 0, 0, 1 ABSORB: LEAVE: STATE: 0.0341626, -0.0104101, -0.0365092, 4.47967, 4.72242, 1977.95, 0.000396758, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.0302449, -0.0164777, 0, 4.24438, -3.51642, 1977.96, 0.000221588, 0, 0, 1 COMP: "fermi" STATE: -0.0302449, -0.0164777, -0.1, 4.24438, -3.51642, 1977.96, 0.000221588, 0, 0, 1 STATE: -0.0301159, -0.0165845, -0.0399128, 4.24438, -3.51642, 1977.96, 0.000251966, 0, 0, 1 ABSORB: LEAVE: STATE: -0.0301159, -0.0165845, -0.0399128, 4.24438, -3.51642, 1977.96, 0.000251966, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.00226029, 0.0128871, 0, -2.13961, 0.212052, 1977.96, 0.000380892, 0, 0, 1 COMP: "fermi" STATE: -0.00226029, 0.0128871, -0.1, -2.13961, 0.212052, 1977.96, 0.000380892, 0, 0, 1 STATE: -0.00231444, 0.0128925, -0.0499464, -2.13961, 0.212052, 1977.96, 0.000406198, 0, 0, 1 ABSORB: LEAVE: STATE: -0.00231444, 0.0128925, -0.0499464, -2.13961, 0.212052, 1977.96, 0.000406198, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.0416195, 0.0135712, 0, 3.43843, -5.67117, 1977.95, 0.000242788, 0, 0, 1 COMP: "fermi" STATE: 0.0416195, 0.0135712, -0.1, 3.43843, -5.67117, 1977.95, 0.000242788, 0, 0, 1 STATE: 0.0417455, 0.0133634, -0.0275193, 3.43843, -5.67117, 1977.95, 0.000279432, 0, 0, 1 ABSORB: LEAVE: STATE: 0.0417455, 0.0133634, -0.0275193, 3.43843, -5.67117, 1977.95, 0.000279432, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.0483699, -0.0257113, 0, -5.74032, 4.81318, 1977.95, 6.26716e-05, 0, 0, 1 COMP: "fermi" STATE: -0.0483699, -0.0257113, -0.1, -5.74032, 4.81318, 1977.95, 6.26716e-05, 0, 0, 1 STATE: -0.0486264, -0.0254963, -0.0116394, -5.74032, 4.81318, 1977.95, 0.000107344, 0, 0, 0.0775835 COMP: "mon" STATE: -0.0486264, -0.0254963, -0.111639, -5.74032, 4.81318, 1977.95, 0.000107344, 0, 0, 0.0775835 STATE: -0.0489504, -0.0252246, 0, -5.74032, 4.81318, 1977.95, 0.000163786, 0, 0, 0.0775835 LEAVE: STATE: -0.0489504, -0.0252246, 0, -5.74032, 4.81318, 1977.95, 0.000163786, 0, 0, 0.0775835 ---------> neutron passes the instrument -----> now x and vx are changed by 1.07... ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.00990556, -0.037021, 0, -6.19004, 7.89478, 1977.94, 8.73028e-05, 0, 0, 1 COMP: "fermi" STATE: -0.0106741, -0.037021, -0.1, -6.67029, 7.89478, 1977.94, 8.73028e-05, 0, 0, 1 STATE: -0.0108467, -0.0368166, -0.0488093, -6.67029, 7.89478, 1977.94, 0.000113184, 0, 0, 1 ABSORB: LEAVE: STATE: -0.0108467, -0.0368166, -0.0488093, -6.67029, 7.89478, 1977.94, 0.000113184, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.00129324, 0.0339112, 0, 1.78238, -3.22754, 1977.96, 0.000255021, 0, 0, 1 COMP: "fermi" STATE: 0.00139357, 0.0339112, -0.1, 1.92066, -3.22754, 1977.96, 0.000255021, 0, 0, 1 STATE: 0.00144215, 0.0338296, -0.0499792, 1.92066, -3.22754, 1977.96, 0.00028031, 0, 0, 1 ABSORB: LEAVE: STATE: 0.00144215, 0.0338296, -0.0499792, 1.92066, -3.22754, 1977.96, 0.00028031, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.00242872, -0.000641701, 0, 7.48103, -3.28313, 1977.95, 0.000308543, 0, 0, 1 COMP: "fermi" STATE: 0.00261715, -0.000641701, -0.1, 8.06144, -3.28313, 1977.95, 0.000308543, 0, 0, 1 STATE: 0.00282125, -0.000724827, -0.0499203, 8.06144, -3.28313, 1977.95, 0.000333862, 0, 0, 1 ABSORB: LEAVE: STATE: 0.00282125, -0.000724827, -0.0499203, 8.06144, -3.28313, 1977.95, 0.000333862, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.0026745, 0.0269914, 0, -1.57875, 6.19544, 1977.96, 0.000113326, 0, 0, 1 COMP: "fermi" STATE: 0.00288199, 0.0269914, -0.1, -1.70123, 6.19544, 1977.96, 0.000113326, 0, 0, 1 STATE: 0.00283892, 0.0271482, -0.0499193, -1.70123, 6.19544, 1977.96, 0.000138645, 0, 0, 1 ABSORB: LEAVE: STATE: 0.00283892, 0.0271482, -0.0499193, -1.70123, 6.19544, 1977.96, 0.000138645, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.0147542, 0.0307725, 0, 6.63051, -6.80802, 1977.94, 0.000379731, 0, 0, 1 COMP: "fermi" STATE: -0.0158988, 0.0307725, -0.1, 7.14493, -6.80802, 1977.94, 0.000379731, 0, 0, 1 STATE: -0.0157091, 0.0305916, -0.0474681, 7.14493, -6.80802, 1977.94, 0.00040629, 0, 0, 1 ABSORB: LEAVE: STATE: -0.0157091, 0.0305916, -0.0474681, 7.14493, -6.80802, 1977.94, 0.00040629, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.00259953, -0.0413944, 0, -4.87031, 2.58285, 1977.96, 0.000356093, 0, 0, 1 COMP: "fermi" STATE: 0.00280122, -0.0413944, -0.1, -5.24817, 2.58285, 1977.96, 0.000356093, 0, 0, 1 STATE: 0.00266836, -0.041329, -0.0499287, -5.24817, 2.58285, 1977.96, 0.000381408, 0, 0, 1 ABSORB: LEAVE: STATE: 0.00266836, -0.041329, -0.0499287, -5.24817, 2.58285, 1977.96, 0.000381408, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.0151107, -0.0435829, 0, -7.595, -0.669311, 1977.95, 2.52383e-05, 0, 0, 1 COMP: "fermi" STATE: -0.016283, -0.0435829, -0.1, -8.18425, -0.669311, 1977.95, 2.52383e-05, 0, 0, 1 STATE: -0.0165015, -0.0436007, -0.0471985, -8.18425, -0.669311, 1977.95, 5.19334e-05, 0, 0, 1 ABSORB: LEAVE: STATE: -0.0165015, -0.0436007, -0.0471985, -8.18425, -0.669311, 1977.95, 5.19334e-05, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.026172, 0.0470634, 0, 6.36439, 5.55282, 1977.95, 0.000106666, 0, 0, 1 COMP: "fermi" STATE: -0.0282025, 0.0470634, -0.1, 6.85817, 5.55282, 1977.95, 0.000106666, 0, 0, 1 STATE: -0.0279994, 0.0472279, -0.041425, 6.85817, 5.55282, 1977.95, 0.00013628, 0, 0, 1 ABSORB: LEAVE: STATE: -0.0279994, 0.0472279, -0.041425, 6.85817, 5.55282, 1977.95, 0.00013628, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.00397603, -0.0124793, 0, 4.1181, 0.198356, 1977.96, 0.00026709, 0, 0, 1 COMP: "fermi" STATE: 0.00428451, -0.0124793, -0.1, 4.4376, 0.198356, 1977.96, 0.00026709, 0, 0, 1 STATE: 0.00439712, -0.0124743, -0.0498063, 4.4376, 0.198356, 1977.96, 0.000292466, 0, 0, 1 ABSORB: LEAVE: STATE: 0.00439712, -0.0124743, -0.0498063, 4.4376, 0.198356, 1977.96, 0.000292466, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.00316064, -0.046072, 0, -0.9868, 6.83322, 1977.95, 0.000372324, 0, 0, 1 COMP: "fermi" STATE: 0.00340586, -0.046072, -0.1, -1.06336, 6.83322, 1977.95, 0.000372324, 0, 0, 1 STATE: 0.00337892, -0.0458988, -0.0498857, -1.06336, 6.83322, 1977.95, 0.00039766, 0, 0, 1 ABSORB: LEAVE: STATE: 0.00337892, -0.0458988, -0.0498857, -1.06336, 6.83322, 1977.95, 0.00039766, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.0220952, -0.0215707, 0, 3.7745, 2.21498, 1977.96, 0.000141619, 0, 0, 1 COMP: "fermi" STATE: 0.0238095, -0.0215707, -0.1, 4.06734, 2.21498, 1977.96, 0.000141619, 0, 0, 1 STATE: 0.0239248, -0.0215078, -0.0439045, 4.06734, 2.21498, 1977.96, 0.00016998, 0, 0, 0.290076 COMP: "mon" STATE: 0.0239248, -0.0215078, -0.143904, 4.06734, 2.21498, 1977.96, 0.00016998, 0, 0, 0.290076 STATE: 0.0242207, -0.0213467, 0, 4.06734, 2.21498, 1977.96, 0.000242734, 0, 0, 0.290076 LEAVE: STATE: 0.0242207, -0.0213467, 0, 4.06734, 2.21498, 1977.96, 0.000242734, 0, 0, 0.290076 ------------> next neutron passed -------------> x and vy are now changed by 1.36..... ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.0187861, -0.0334026, 0, -0.947765, 6.0142, 1977.96, 0.00033168, 0, 0, 1 COMP: "fermi" STATE: 0.025693, -0.0334026, -0.1, -1.29622, 6.0142, 1977.96, 0.00033168, 0, 0, 1 STATE: 0.0256556, -0.033229, -0.0429161, -1.29622, 6.0142, 1977.96, 0.00036054, 0, 0, 1 ABSORB: LEAVE: STATE: 0.0256556, -0.033229, -0.0429161, -1.29622, 6.0142, 1977.96, 0.00036054, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: -0.0169663, -0.0271032, 0, 6.2246, -2.36785, 1977.95, 0.000274668, 0, 0, 1 COMP: "fermi" STATE: -0.0232041, -0.0271032, -0.1, 8.51314, -2.36785, 1977.95, 0.000274668, 0, 0, 1 STATE: -0.0229649, -0.0271697, -0.0444141, 8.51314, -2.36785, 1977.95, 0.000302771, 0, 0, 1 ABSORB: LEAVE: STATE: -0.0229649, -0.0271697, -0.0444141, 8.51314, -2.36785, 1977.95, 0.000302771, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.0456468, 0.00886401, 0, 2.48912, 5.67558, 1977.96, 0.000175824, 0, 0, 1 COMP: "fermi" STATE: 0.0624293, 0.00886401, -0.1, 3.40428, 5.67558, 1977.96, 0.000175824, 0, 0, 1 STATE: 0.0624293, 0.00886401, -0.1, 3.40428, 5.67558, 1977.96, 0.000175824, 0, 0, 1 ABSORB: LEAVE: STATE: 0.0624293, 0.00886401, -0.1, 3.40428, 5.67558, 1977.96, 0.000175824, 0, 0, 1 ENTER: STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "a1" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 COMP: "source" STATE: 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 STATE: 0.042397, -0.0101563, 0, 4.98077, 2.91501, 1977.96, 0.000364389, 0, 0, 1 COMP: "fermi" STATE: 0.0579846, -0.0101563, -0.1, 6.812, 2.91501, 1977.96, 0.000364389, 0, 0, 1 STATE: 0.0579846, -0.0101563, -0.1, 6.812, 2.91501, 1977.96, 0.000364389, 0, 0, 1 ABSORB: LEAVE: STATE: 0.0579846, -0.0101563, -0.1, 6.812, 2.91501, 1977.96, 0.000364389, 0, 0, 1 Neutrons: 2, Deviation: 81.6172, Deviation: 81.617% Detector: mon_I=0 mon_ERR=0 From farhi at ill.fr Fri Feb 5 15:21:59 1999 From: farhi at ill.fr (emmanuel farhi) Date: Fri, 05 Feb 1999 15:21:59 +0100 (MET) Subject: Component libraries Message-ID: <199902051421.PAA28606@biceps.ill.fr> Hello Kristian, I'm now getting acustomed to McStas, and I began to create/modify some components. Particularly, I've been adding in all detectors/monitors which produce output files two lines specifying who created the file, and date/time of creation. Also, I added a line in begining of mcstas.h lib file : #include in order to avoid warnings in linking. And how about having an ftp location were everybody could up/download components and instruments ? For instance, the component Source_flux isn't provided in v1.01 beta, and I'm deeply interested in it. Also, are there some other types of curved monochromators/analysers ? Here is attached my current lib. Cheers. EF. -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 23128 bytes Desc: mcslib.tar.gz URL: From kristian.nielsen at risoe.dk Wed Feb 10 08:31:32 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 10 Feb 1999 08:31:32 +0100 Subject: Component libraries In-Reply-To: <199902051421.PAA28606@biceps.ill.fr> (message from emmanuel farhi on Fri, 05 Feb 1999 15:21:59 +0100 (MET)) Message-ID: > Particularly, I've been adding in all detectors/monitors which produce output > files two lines specifying who created the file, and date/time of creation. Yes, this sounds like a good idea. The whole issue of output file formats really need to be addressed, and I am working on a complete solution. The long-term goal is to provide data in an intermediate McStas-specific ASCII format with (optional) automatic translation to the NeXus format. Our development version already has some of this, and I will add the information you suggested to our output format. Expect to see something in the next official release. My current approach is a bit different though - I do not add information in comments in the data files themselves. Instead, all data files for a simulation are stored together in a subdirectory with a special file (say "mcstas.sim") containing all information about the data. We have a front-end that will read the information in this file and plot all the data with correct title and axis labels etc. This is very useful for a quick overview of the simulation. The reason for keeping the extra information out of the data files themselves is to maintain maximum compatibility with other programs. Almost any program will read straight ASCII colums of numbers, but I am not sure if there is a universal standard for a comment character (though the '#' you used is fairly common, I guess). What do you think? The use of a separate directory for the data files becomes useful when the simulation uses a lot of data files. For example, some of our recent simulations generate more than 50 output files! > And how about having an ftp location were everybody could up/download components > and instruments ? For instance, the component Source_flux isn't provided in > v1.01 beta, and I'm deeply interested in it. Also, are there some other types > of curved monochromators/analysers ? Yes, this is also a good idea. I set up a download area for "unofficial McStas additions" on the web page at http://elu-alf-2.risoe.dk/~elu-krni/mcstas/unofficial.html Initially, I think I will function as an "editor", so that submissions are sent to me, and I put them on the page with a few comments. But as the activity of McStas increases, a proper upload area might be useful. The Source_flux component is on the page. We do not currently have any new Monochromator components. - Kristian. From kristian.nielsen at risoe.dk Fri Feb 12 08:58:47 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 12 Feb 1999 08:58:47 +0100 Subject: Component libraries In-Reply-To: (farhi@ill.fr) Message-ID: Hi Emmanuel, > Have you been testing such things, and did you noticed it ? Yes, I've seen something similar before. Possible causes include physically overlapping components, typos in the definition, wrong sign in monochromator/analyzer focusing, and even bugs in McStas. Send me the details and I will have a look. - Kristian. From farhi at ill.fr Thu Feb 11 20:18:55 1999 From: farhi at ill.fr (Emmanuel Farhi (71 83)) Date: Thu, 11 Feb 1999 20:18:55 +0100 Subject: Component libraries In-Reply-To: <01J7KM2FVJTW8XAKMG@risoe.dk> References: <199902051421.PAA28606@biceps.ill.fr> (message from emmanuel farhi on Fri, 05 Feb 1999 15:21:59 +0100 (MET)) Message-ID: Hello Kristian, I'm now finishing to modelize a typical ILL TAS instrument, using all motors available in an experiment. But there seem to be something strange. The orientation of the instrument should not modify detector counts. I mean that if you change signs of monochromator and analyser angles (PHM,TTM) and (OMA,TTA), for reasons of symetry, same countings should be obtained. But it isn't the case ! One can find variations in a factor 4 or 5. Have you been testing such things, and did you noticed it ? I'll send you some details, and source instrument file, in order that you can see by yourself. Cheers. E. -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ Avenue des Martyrs, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From bernhard at amos.krist.uni-erlangen.de Fri Feb 12 11:01:05 1999 From: bernhard at amos.krist.uni-erlangen.de (Philipp Bernhardt) Date: Fri, 12 Feb 1999 11:01:05 +0100 (MET) Subject: Inter-component transformations - Bender In-Reply-To: <01J7CL78CG3Y8X9VGO@risoe.dk> Message-ID: Hi Kristian, Sorry for answering so late. Thanks for your help. I have changed the TOF-monitor component and now everything works fine. I have included a new bender-version, which is a little bit shorter, has more explanations and accepts also benders, where it is possible for neutrons to pass without a reflection. There are also two pictures (xfig-format) to show the geometry. (Input.fig shows the input-variables and variab.fig shows variables, which are used by the programme). - Philipp --------------------------- Philipp Bernhardt Lehrstuhl f?r Kristallographie und Strukturphysik email: philipp.bernhardt at krist.uni-erlangen.de -------------- next part -------------- /******************************************************************************* * * Component: Bender * * Written by: Philipp Bernhardt, Februar 7 1999 * * Models a curved neutron guide. The entrance lies in the X-Y plane, centered * on the Z axis. The neutrons will also leave the bender in the X-Y plane at * the z-value r*Win, so you do not have to calculate the real exit coordinates * and you do not need a new arm. The bender is bent to the negative X axis; * it behaves like a parallel guide in the Y axis. * There is no warning, if the input parameters are wrong, so please make sure * that * w,h,r,d,Win,k are positive numbers and * k*d is smaller than the width w. * * INPUT PARAMETERS: * * w: (m) Width at the bender entry and exit * h: (m) Height at the bender entry and exit * r: (m) Radius of the bender * d: (m) Thickness of the partition, which separates the channels * Win: (rad) Angle of the deflection of the whole bender * k: (1) Number of channels inside the bender * R0a,Qca,alphaa,ma,Wa: Parameters, which are describing the mirror at concave * side of the bender * R0i,Qci,alphai,mi,Wi: Parameters, which are describing the mirror at convex * side of the bender * R0s,Qcs,alphas,ms,Ws: Parameters, which are describing the mirror at the top * and bottom side of the bender * * Example values: w=0.05 h=0.12 r=250 d=0.001 Win=0.04 k=3 ma=3 mi=2 ms=2 *******************************************************************************/ DEFINE COMPONENT Bender DEFINITION PARAMETERS (w,h,r,d,Win,k,R0a,Qca,alphaa,ma,Wa,R0i,Qci,alphai,mi,Wi,R0s,Qcs,alphas,ms,Ws) SETTING PARAMETERS () OUTPUT PARAMETERS () STATE PARAMETERS (x, y, z, vx, vy, vz, t, s1, s2, p) DECLARE %{ double bk; #ifndef BENDER_DECLARE #define BENDER_DECLARE double sgn(double x) { if (x>=0) return 1.0; else return -1.0; } #endif %} INITIALIZE %{ /* width of one channel + thickness d of partition */ bk=(w+d)/k; %} TRACE %{ int i,num,numa,numi; double dru,ab,dab,R,Q,arg,arga,argi,Ta,vpl; double einwin,auswin,zykwin,aeuwin,innwin,ref,innref,aeuref; double einzei,auszei,zykzei; /* does the neutron hit the bender at the entrance? */ PROP_Z0; if ((fabs(x)>w/2) || (fabs(y)>h/2)) ABSORB; /*** reflections in the XZ-plane ***/ /* distance between neutron and concave side of the channel at the entrance */ dru=floor((w/2-x)/bk)*bk; ab=w/2.0-x-dru; /* radius of the channel */ R=r-dru; /* does the neutron hit the partition at the entrance? */ if (ab>bk-d) ABSORB; /* velocity in the XZ-plane */ vpl=sqrt(vx*vx+vz*vz); /* divergence of the neutron at the entrance */ einwin=atan(vx/vz); /* maximal distance between neutron and concave side of the channel */ dab=R-cos(einwin)*(R-ab); /* reflection angle at the concave side */ aeuwin=acos((R-dab)/R); /* reflection coefficient at the concave side */ arga=0.0; Q=2.0*V2K*vpl*sin(aeuwin); if (Q<=Qca) aeuref=R0a; else { arga=(Q-ma*Qca)/Wa; aeuref=0.5*R0a*(1.0-tanh(arga))*(1.0-alphaa*(Q-Qca)); } /* does the neutron hit the convex side of the channel? */ innwin=0.0; innref=1.0; argi=0.0; if (dab>bk-d) { /* reflection coefficient at the convex side */ innwin=acos((R-dab)/(R-bk+d)); Q=2.0*V2K*vpl*sin(innwin); if (Q<=Qci) innref=R0i; else { argi=(Q-mi*Qci)/Wi; innref=0.5*R0i*(1.0-tanh(argi))*(1.0-alphai*(Q-Qci)); } } /* divergence of the neutron at the exit */ zykwin=2.0*(aeuwin-innwin); auswin=fmod(Win+einwin+aeuwin-innwin*(1.0+sgn(einwin)),zykwin)-zykwin/2.0; auswin+=innwin*sgn(auswin); /* number of reflections at the concave side */ numa=(Win+einwin+aeuwin-innwin*(1.0+sgn(einwin)))/zykwin; /* number of reflections at the convex side */ numi=numa; if (auswin*einwin<0) { if (auswin-einwin>0) numi++; else numi--; } /* is the reflection coefficient too small? */ if (((numa>0) && (arga>10.0)) || ((numi>0) && (argi>10.0))) ABSORB; /* calculation of the neutron probability weight p */ for (i=1;i<=numa;i++) p*=aeuref; for (i=1;i<=numi;i++) p*=innref; /* time to cross the bender */ Ta=(2*numa*(tan(aeuwin)-tan(innwin))+tan(auswin)-tan(einwin)-tan(innwin)* (sgn(auswin)-sgn(einwin)))*(R-dab)/vpl; t+=Ta; /* distance between neutron and concave side of channel at the exit */ ab=R-(R-dab)/cos(auswin); /* calculation of the exit coordinates in the XZ-plane */ x=w/2.0-ab-dru; z=r*Win; vx=sin(auswin)*vpl; vz=cos(auswin)*vpl; /*** reflections at top and bottom side (Y axis) ***/ if (vy!=0.0) { /* reflection coefficent at the top and bottom side */ Q=2.0*V2K*fabs(vy); if (Q<=Qcs) ref=R0s; else { arg=(Q-ms*Qcs)/Ws; ref=0.5*R0s*(1.0-tanh(arg))*(1.0-alphas*(Q-Qcs)); } /* number of reflections at top and bottom */ einzei=h/2.0/fabs(vy)+y/vy; zykzei=h/fabs(vy); num=(Ta+einzei)/zykzei; /* time between the last reflection and the exit */ auszei=fmod(Ta+einzei,zykzei); /* is the reflection coefficient too small? */ if ((num>0) && (arg>10.0)) ABSORB; /* calculation of the probability weight p */ for (i=1;i<=num;i++) { p*=ref; vy*=-1.0; } /* calculation of the exit coordinate */ y=auszei*vy-vy*h/fabs(vy)/2.0; } %} END -------------- next part -------------- #FIG 3.2 Landscape Center Metric A4 100.00 Single -2 1200 2 5 1 0 2 0 7 0 0 -1 0.000 0 0 0 0 4050.000 5700.000 900 2700 4050 1350 7200 2700 5 1 0 2 0 7 0 0 -1 0.000 0 0 0 0 4034.255 6078.912 1890 3705 4050 2880 6195 3720 5 1 0 1 0 7 0 0 -1 0.000 0 0 1 1 4055.600 5777.681 3735 5550 4035 5385 4365 5535 1 1 1.00 60.00 120.00 1 1 1.00 60.00 120.00 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4012.742 5763.083 1560 3375 4050 2340 6480 3390 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4013.279 5712.100 1515 3315 4050 2250 6540 3345 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4042.494 5855.371 1230 3060 4050 1890 6840 3045 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4035.000 5784.281 1185 3000 4050 1800 6885 3000 2 2 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 5 450 450 7650 450 7650 6300 450 6300 450 450 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 1 2 1 1 1.00 60.00 120.00 1 1 1.00 60.00 120.00 4050 5850 5055 1470 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 1 2 1 1 1.00 60.00 120.00 1 1 1.00 60.00 120.00 2310 1740 2880 3090 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 1845 2580 1350 4485 2145 2910 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 1440 2250 1350 4470 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 900 2715 4050 5865 7200 2715 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 6465 2670 6750 1665 6150 3045 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 3330 1845 3390 3660 3555 2250 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 3735 2880 3405 3615 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 5265 2835 5760 1305 5625 2430 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 5850 1980 5760 1305 2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2 1162 3007 1229 3074 4 0 0 0 0 0 12 0.0000 4 90 135 2445 1980 w\001 4 0 0 0 0 0 12 0.0000 4 135 315 3675 5370 Win\001 4 0 0 0 0 0 12 0.0000 4 90 60 4575 3990 r\001 4 0 0 0 0 0 12 0.0000 4 135 1650 5760 5760 k: number of channels\001 4 0 0 0 0 0 12 0.0000 4 180 645 5760 5400 h: height\001 4 0 0 0 0 0 12 0.0000 4 180 1290 3420 6630 Input parameters\001 4 0 0 0 0 0 12 0.0000 4 135 990 900 4770 concave side\001 4 0 0 0 0 0 12 0.0000 4 135 900 2940 3870 convex side\001 4 0 0 0 0 0 12 0.0000 4 135 675 5445 1125 channels\001 4 0 0 0 0 0 12 0.0000 4 135 540 3825 900 Bender\001 4 0 0 0 0 0 12 0.0000 4 135 90 1058 3218 d\001 4 0 0 0 0 0 12 0.0000 4 180 720 6465 1530 partitions\001 -------------- next part -------------- #FIG 3.2 Landscape Center Metric A4 100.00 Single -2 1200 2 5 1 0 2 0 7 0 0 -1 0.000 0 0 0 0 4050.000 5700.000 900 2700 4050 1350 7200 2700 5 1 0 2 0 7 0 0 -1 0.000 0 0 0 0 4034.255 6078.912 1890 3705 4050 2880 6195 3720 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4012.742 5763.083 1560 3375 4050 2340 6480 3390 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4013.279 5712.100 1515 3315 4050 2250 6540 3345 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4042.494 5855.371 1230 3060 4050 1890 6840 3045 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4035.000 5784.281 1185 3000 4050 1800 6885 3000 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 2112.500 2500.833 2160 2385 2235 2475 2220 2565 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4081.428 5172.143 3915 5025 4080 4950 4260 5040 5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 5906.786 2711.786 5940 2655 5970 2730 5925 2775 2 2 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 5 450 450 7650 450 7650 6300 450 6300 450 450 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 900 2715 4050 5865 7200 2715 2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 9 1395 3240 1815 2595 2620 2540 3345 1942 4140 2250 5040 2025 5580 2610 6390 2655 6615 3285 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 3352 1965 4050 5850 5032 2025 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 1680 2970 1110 3525 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 6435 3120 6840 3510 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 3 1500 3945 1605 3015 1605 3000 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 6495 3135 6450 4080 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 5835 2730 5700 2880 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 2280 2940 2085 2505 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 4095 4545 4095 5100 2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2 1240 3079 1396 3231 2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 2 3795 1335 3810 1620 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 1725 1410 2940 2280 2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 0 0 2 4725 1605 5655 1035 2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 0 0 4 1080 2895 2317 1717 5340 1560 7005 2910 4 0 0 0 0 0 12 0.0000 4 180 540 3855 4410 zykwin\001 4 0 0 0 0 0 12 0.0000 4 135 495 5490 3075 innwin\001 4 0 0 0 0 0 12 0.0000 4 135 495 1245 4230 einwin\001 4 0 0 0 0 0 12 0.0000 4 135 540 6210 4320 auswin\001 4 0 0 0 0 0 12 0.0000 4 135 690 3660 6570 variables\001 4 0 0 0 0 0 12 0.0000 4 135 180 1117 3300 ab\001 4 0 0 0 0 0 12 0.0000 4 135 285 7185 4200 exit\001 4 0 0 0 0 0 12 0.0000 4 105 660 480 3945 entrance\001 4 0 0 0 0 0 12 0.0000 4 135 270 3870 1552 dab\001 4 0 0 0 0 0 12 0.0000 4 180 1380 5820 1080 garland-reflection\001 4 0 0 0 0 0 12 0.0000 4 135 1545 705 1245 zick-zack reflection\001 4 0 0 0 0 0 12 0.0000 4 135 540 2340 3000 aeuwin\001 From kristian.nielsen at risoe.dk Fri Feb 12 11:51:31 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 12 Feb 1999 11:51:31 +0100 Subject: Inter-component transformations - Bender In-Reply-To: (message from Philipp Bernhardt on Fri, 12 Feb 1999 11:01:05 +0100 (MET)) Message-ID: > I have included a new bender-version, which is a little bit shorter, = > has > more explanations and > accepts also benders, where it is possible for neutrons to pass witho= > ut a > reflection. There are also two pictures (xfig-format) to show the > geometry. (Input.fig shows the input-variables and variab.fig shows > variables, which are used by the programme).=20 Hi Philipp, Thanks a lot for the updated information. With the figures you supplied, I think I can include your Bender component in the McStas manual in the next release. - Kristian. From stuart at studsvik.uu.se Fri Feb 12 11:39:50 1999 From: stuart at studsvik.uu.se (stuart) Date: Fri, 12 Feb 1999 11:39:50 +0100 Subject: Mcstas example programs Message-ID: <36C404F5.5FEA5D5C@studsvik.uu.se> Hello I'm mailing from Studsvik, Sweden because we're interested in learning about the Mcstas simulation package. We eventually hope to use it to assist us in the design of a reflectometer. The simulation was installed on a digital unix system. I was trying to reproduce the results in the manual for the simulation of prisma by using the example file prisma2.instr. To start I used the command ./prisma2 --ncount=2e6 TT=-30 PHA=22 PHA1=-3 PHA2=-2 PHA3=-1 PHA4=0 PHA5=1 PHA6=2 PHA7=3 TTA=44 No counts register on the detector. Although they are registered on the monitor. I wondered if you could tell me what's going wrong! Thank you. Regards, Stuart Rycroft From kristian.nielsen at risoe.dk Fri Feb 12 13:52:27 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 12 Feb 1999 13:52:27 +0100 Subject: Mcstas example programs In-Reply-To: <36C404F5.5FEA5D5C@studsvik.uu.se> (message from stuart on Fri, 12 Feb 1999 11:39:50 +0100) Message-ID: > I'm mailing from Studsvik, Sweden because we're interested in learning > about the Mcstas simulation package. We eventually hope to use it to > assist us in the design of a reflectometer. Good luck, I hope you find it useful. > The simulation was installed on a digital unix system. I was trying to > reproduce the results in the manual for the simulation of prisma by > using the example file prisma2.instr. To start I used the command > > ./prisma2 --ncount=2e6 TT=-30 PHA=22 PHA1=-3 PHA2=-2 PHA3=-1 PHA4=0 > PHA5=1 PHA6=2 PHA7=3 TTA=44 > > No counts register on the detector. Although they are registered on the > monitor. I wondered if you could tell me what's going wrong! That is difficult to say without more information. When I run the same command, I do get counts in all the detectors and monitors. We have some alpha machines at Ris?, so if you could send me the prisma2.c file generated by McStas and the prisma2 executable produced by the C compiler, I could try to repeat your problems and find the cause. Btw., you might consider joining the neutron-mc mailing list (see http://neutron.risoe.dk/neutron-mc/ ). This is a general list for discussing Monte Carlo simulation and neutron scattering. It is not too busy but sometimes contains useful discussions. - Kristian. From stuart at studsvik.uu.se Fri Feb 12 14:07:59 1999 From: stuart at studsvik.uu.se (stuart) Date: Fri, 12 Feb 1999 14:07:59 +0100 Subject: Mcstas example programs References: <01J7NPU1FPAG8ZDUWL@risoe.dk> Message-ID: <36C427AE.58DB74F3@studsvik.uu.se> Hi Thankyou for your reply. The files are attached. Stuart Rycroft Kristian Nielsen wrote: > We have some alpha machines at Ris?, so if you could send me the > prisma2.c file generated by McStas and the prisma2 executable produced > by the C compiler, I could try to repeat your problems and find the > cause. -------------- next part -------------- A non-text attachment was scrubbed... Name: prisma2.out Type: application/x-unknown-content-type-out_auto_file Size: 82124 bytes Desc: not available URL: -------------- next part -------------- /* Automatically generated file. Do not edit. */ #define MC_USE_DEFAULT_MAIN #define MC_EMBEDDED_RUNTIME #line 1 "mcstas-r.h" /******************************************************************************* * Runtime system for McStas. * * Project: Monte Carlo Simulation of Triple Axis Spectrometers * File name: mcstas-r.h * * Author: K.N. Aug 29, 1997 * * $Id: mcstas-r.h,v 1.20 1998/10/09 07:53:48 kn Exp kn $ * * $Log: mcstas-r.h,v $ * Revision 1.20 1998/10/09 07:53:48 kn * Added some unit conversion constants. * * Revision 1.19 1998/10/02 08:38:36 kn * Added DETECTOR_OUT support. * Fixed header comment. * * Revision 1.18 1998/10/01 08:12:42 kn * Support for embedding the file in the output from McStas. * Added mcstas_main() function. * Added support for command line arguments. * * Revision 1.17 1998/09/24 13:01:39 kn * Minor conversion factor additions. * * Revision 1.16 1998/09/23 13:52:08 kn * Added conversion factors. * McStas now uses its own random() implementation (unless * USE_SYSTEM_RANDOM is defined). * * Revision 1.15 1998/05/19 07:59:45 kn * Hack to make random number generation work with HP's CC C compiler. * * Revision 1.14 1998/04/17 11:50:31 kn * Added sphere_intersect. * * Revision 1.13 1998/04/17 10:53:08 kn * Added randvec_target_sphere. * * Revision 1.12 1998/03/25 07:23:24 kn * Fixed RAND_MAX #define for HPUX. * * Revision 1.11 1998/03/24 13:59:26 lefmann * Added #define for RAND_MAX, needed on HPUX. * * Revision 1.10 1998/03/24 13:24:40 lefmann * Added HBAR, MNEUTRON. * * Revision 1.9 1998/03/24 07:42:35 kn * Added definition for PI. * * Revision 1.8 1998/03/24 07:36:20 kn * Make ABSORB macro work better in control structures. * Add test_printf(). * Add rand01(), randpm1(), rand0max(), and randminmax(). * Add PROP_X0, PROP_Y0, PROP_DT, vec_prod(), scalar_prod(), NORM(), and * rotate(). * Fix typos. * * Revision 1.7 1998/03/20 14:20:10 lefmann * Added a few definitions. * * Revision 1.6 1998/03/18 13:21:48 elu_krni * Added definition of PROP_Z0 macro. * * Revision 1.5 1998/03/16 08:04:16 kn * Added normal distributed random number function randnorm(). * * Revision 1.4 1997/12/03 13:34:19 kn * Added definition of ABSORB macro. * * Revision 1.3 1997/10/16 14:27:28 kn * Added debugging output used by the "display" graphical visualization * tool. * * Revision 1.2 1997/09/08 11:31:27 kn * Added mcsetstate() function. * * Revision 1.1 1997/09/08 10:39:44 kn * Initial revision * * * Copyright (C) Risoe National Laboratory, 1997-1998, All rights reserved *******************************************************************************/ #ifndef MCSTAS_R_H #define MCSTAS_R_H #include #include #include #include /* If the runtime is embedded in the simulation program, some definitions can be made static. */ #ifdef MC_EMBEDDED_RUNTIME #define mcstatic static #else #define mcstatic #endif typedef double MCNUM; typedef struct {MCNUM x, y, z;} Coords; typedef MCNUM Rotation[3][3]; struct mcinputtable_struct { char *name; MCNUM *par; }; extern struct mcinputtable_struct mcinputtable[]; extern int mcnumipar; extern char mcinstrument_name[], mcinstrument_source[]; extern int mctraceenabled, mcdefaultmain; void mcinit(void); void mcraytrace(void); void mcfinally(void); #define ABSORB do {mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz, \ mcnlt,mcnls1,mcnls2, mcnlp); mcDEBUG_ABSORB(); goto mcabsorb;} while(0) #define MC_GETPAR(comp, par) mcc ## comp ## _ ## par #define DETECTOR_OUT(p0,p1,p2) printf("Detector: %s_I=%g %s_ERR=%g\n", \ mccompcurname, p1, mccompcurname, mcestimate_error(p0,p1,p2)) #ifdef MC_TRACE_ENABLED #define DEBUG #endif #ifdef DEBUG #define mcDEBUG_INSTR() if(!mcdotrace); else printf("INSTRUMENT:\n"); #define mcDEBUG_COMPONENT(name,c,t) if(!mcdotrace); else \ printf("COMPONENT: \"%s\"\n" \ "POS: %g, %g, %g, %g, %g, %g, %g, %g, %g, %g, %g, %g\n", \ name, c.x, c.y, c.z, t[0][0], t[0][1], t[0][2], \ t[1][0], t[1][1], t[1][2], t[2][0], t[2][1], t[2][2]); #define mcDEBUG_INSTR_END() if(!mcdotrace); else printf("INSTRUMENT END:\n"); #define mcDEBUG_ENTER() if(!mcdotrace); else printf("ENTER:\n"); #define mcDEBUG_COMP(c) if(!mcdotrace); else printf("COMP: \"%s\"\n", c); #define mcDEBUG_STATE(x,y,z,vx,vy,vz,t,s1,s2,p) if(!mcdotrace); else \ printf("STATE: %g, %g, %g, %g, %g, %g, %g, %g, %g, %g\n", \ x,y,z,vx,vy,vz,t,s1,s2,p); #define mcDEBUG_LEAVE() if(!mcdotrace); else printf("LEAVE:\n"); #define mcDEBUG_ABSORB() if(!mcdotrace); else printf("ABSORB:\n"); #else #define mcDEBUG_INSTR() #define mcDEBUG_COMPONENT(name,c,t) #define mcDEBUG_INSTR_END() #define mcDEBUG_ENTER() #define mcDEBUG_COMP(c) #define mcDEBUG_STATE(x,y,z,vx,vy,vz,t,s1,s2,p) #define mcDEBUG_LEAVE() #define mcDEBUG_ABSORB() #endif #ifdef TEST #define test_printf printf #else #define test_printf while(0) printf #endif #define MIN2RAD (PI/(180*60)) #define DEG2RAD (PI/180) #define RAD2DEG (180/PI) #define AA2MS 629.719 /* Convert k[1/AA] to v[m/s] */ #define MS2AA 1.58801E-3 /* Convert v[m/s] to k[1/AA] */ #define K2V AA2MS #define V2K MS2AA #define Q2V AA2MS #define V2Q MS2AA #define SE2V 437.3949 /* Convert sqrt(E)[meV] to v[m/s] */ #define VS2E 5.227e-6 /* Convert v[m/s] to sqrt(E)[meV] */ #define HBAR 1.05459E-34 #define MNEUTRON 1.67492E-27 #ifndef PI # ifdef M_PI # define PI M_PI # else # define PI 3.14159265358979323846 # endif #endif typedef int mc_int32_t; mc_int32_t mc_random(void); void mc_srandom (unsigned int x); #ifndef USE_SYSTEM_RANDOM #ifdef RAND_MAX # undef RAND_MAX #endif #define RAND_MAX 0x7fffffff #define random mc_random #define srandom mc_srandom #endif /* !USE_SYSTEM_RANDOM */ #define rand01() ( ((double)random())/((double)RAND_MAX+1) ) #define randpm1() ( ((double)random()) / (((double)RAND_MAX+1)/2) - 1 ) #define rand0max(max) ( ((double)random()) / (((double)RAND_MAX+1)/(max)) ) #define randminmax(min,max) ( rand0max((max)-(min)) - (min) ) #define PROP_X0 \ { \ double mc_dt; \ if(mcnlvx == 0) ABSORB; \ mc_dt = -mcnlx/mcnlvx; \ if(mc_dt < 0) ABSORB; \ mcnly += mcnlvy*mc_dt; \ mcnlz += mcnlvz*mc_dt; \ mcnlt += mc_dt; \ mcnlx = 0; \ } #define PROP_Y0 \ { \ double mc_dt; \ if(mcnlvy == 0) ABSORB; \ mc_dt = -mcnly/mcnlvy; \ if(mc_dt < 0) ABSORB; \ mcnlx += mcnlvx*mc_dt; \ mcnlz += mcnlvz*mc_dt; \ mcnlt += mc_dt; \ mcnly = 0; \ } #define PROP_Z0 \ { \ double mc_dt; \ if(mcnlvz == 0) ABSORB; \ mc_dt = -mcnlz/mcnlvz; \ if(mc_dt < 0) ABSORB; \ mcnlx += mcnlvx*mc_dt; \ mcnly += mcnlvy*mc_dt; \ mcnlt += mc_dt; \ mcnlz = 0; \ } #define PROP_DT(dt) \ { \ mcnlx += mcnlvx*(dt); \ mcnly += mcnlvy*(dt); \ mcnlz += mcnlvz*(dt); \ mcnlt += (dt); \ } #define vec_prod(x, y, z, x1, y1, z1, x2, y2, z2) \ { \ double mcvp_tmpx, mcvp_tmpy, mcvp_tmpz; \ mcvp_tmpx = (y1)*(z2) - (y2)*(z1); \ mcvp_tmpy = (z1)*(x2) - (z2)*(x1); \ mcvp_tmpz = (x1)*(y2) - (x2)*(y1); \ (x) = mcvp_tmpx; (y) = mcvp_tmpy; (z) = mcvp_tmpz; \ } #define scalar_prod(x1, y1, z1, x2, y2, z2) \ ((x1)*(x2) + (y1)*(y2) + (z1)*(z2)) #define NORM(x,y,z) \ { \ double mcnm_tmp = sqrt((x)*(x) + (y)*(y) + (z)*(z)); \ if(mcnm_tmp != 0.0) \ { \ (x) /= mcnm_tmp; \ (y) /= mcnm_tmp; \ (z) /= mcnm_tmp; \ } \ } #define rotate(x, y, z, vx, vy, vz, phi, ax, ay, az) \ { \ double mcrt_tmpx = (ax), mcrt_tmpy = (ay), mcrt_tmpz = (az); \ double mcrt_vp, mcrt_vpx, mcrt_vpy, mcrt_vpz; \ double mcrt_vnx, mcrt_vny, mcrt_vnz, mcrt_vn1x, mcrt_vn1y, mcrt_vn1z; \ double mcrt_bx, mcrt_by, mcrt_bz, mcrt_v1x, mcrt_v1y, mcrt_v1z; \ double mcrt_cos, mcrt_sin; \ NORM(mcrt_tmpx, mcrt_tmpy, mcrt_tmpz); \ mcrt_vp = scalar_prod((vx), (vy), (vz), mcrt_tmpx, mcrt_tmpy, mcrt_tmpz); \ mcrt_vpx = mcrt_vp*mcrt_tmpx; \ mcrt_vpy = mcrt_vp*mcrt_tmpy; \ mcrt_vpz = mcrt_vp*mcrt_tmpz; \ mcrt_vnx = (vx) - mcrt_vpx; \ mcrt_vny = (vy) - mcrt_vpy; \ mcrt_vnz = (vz) - mcrt_vpz; \ vec_prod(mcrt_bx, mcrt_by, mcrt_bz, \ mcrt_tmpx, mcrt_tmpy, mcrt_tmpz, mcrt_vnx, mcrt_vny, mcrt_vnz); \ mcrt_cos = cos((phi)); mcrt_sin = sin((phi)); \ mcrt_vn1x = mcrt_vnx*mcrt_cos + mcrt_bx*mcrt_sin; \ mcrt_vn1y = mcrt_vny*mcrt_cos + mcrt_by*mcrt_sin; \ mcrt_vn1z = mcrt_vnz*mcrt_cos + mcrt_bz*mcrt_sin; \ (x) = mcrt_vpx + mcrt_vn1x; \ (y) = mcrt_vpy + mcrt_vn1y; \ (z) = mcrt_vpz + mcrt_vn1z; \ } Coords coords_set(MCNUM x, MCNUM y, MCNUM z); Coords coords_add(Coords a, Coords b); Coords coords_sub(Coords a, Coords b); Coords coords_neg(Coords a); void rot_set_rotation(Rotation t, double phx, double phy, double phz); void rot_mul(Rotation t1, Rotation t2, Rotation t3); void rot_copy(Rotation dest, Rotation src); void rot_transpose(Rotation src, Rotation dst); Coords rot_apply(Rotation t, Coords a); void mccoordschange(Coords a, Rotation t, double *x, double *y, double *z, double *vx, double *vy, double *vz, double *time, double *s1, double *s2); double mcestimate_error(int N, double p1, double p2); void mcreadparams(void); void mcsetstate(double x, double y, double z, double vx, double vy, double vz, double t, double s1, double s2, double p); void mcgenstate(void); double randnorm(void); int cylinder_intersect(double *t0, double *t1, double x, double y, double z, double vx, double vy, double vz, double r, double h); int sphere_intersect(double *t0, double *t1, double x, double y, double z, double vx, double vy, double vz, double r); void randvec_target_sphere(double *xo, double *yo, double *zo, double *solid_angle, double xi, double yi, double zi, double radius); void mcset_ncount(double count); int mcstas_main(int argc, char *argv[]); #endif /* MCSTAS_R_H */ /* End of file "mcstas-r.h". */ #line 1 "mcstas-r.c" /******************************************************************************* * Runtime system for McStas. * * Project: Monte Carlo Simulation of Triple Axis Spectrometers * File name: mcstas-r.c * * Author: K.N. Aug 27, 1997 * * $Id: mcstas-r.c,v 1.15 1998/10/02 08:38:27 kn Exp kn $ * * $Log: mcstas-r.c,v $ * Revision 1.15 1998/10/02 08:38:27 kn * Added DETECTOR_OUT support. * Fixed header comment. * * Revision 1.14 1998/10/01 08:12:26 kn * Support for embedding the file in the output from McStas. * Added mcstas_main() function. * Added support for command line arguments. * * Revision 1.13 1998/09/23 13:51:35 kn * McStas now uses its own random() implementation (unless * USE_SYSTEM_RANDOM is defined). * * Revision 1.12 1998/05/19 07:54:05 kn * In randvec_target_sphere, accept radius=0 to mean that no focusing is to * be done (choose direction uniformly in full 4PI solid angle). * * Revision 1.11 1998/05/11 12:08:49 kn * Fix bug in cylinder_intersect that caused an infinite cylinder height in * some cases. * * Revision 1.10 1998/04/17 11:50:08 kn * Added sphere_intersect. * * Revision 1.9 1998/04/17 10:52:27 kn * Better names in randvec_target_sphere. * * Revision 1.8 1998/04/16 14:21:49 kn * Added randvec_target() function. * * Revision 1.7 1998/03/24 07:34:03 kn * Use rand01() in randnorm(). Fix typos. * * Revision 1.6 1998/03/20 14:19:52 lefmann * Added cylinder_intersect(). * * Revision 1.5 1998/03/16 08:03:41 kn * Added normal distributed random number function randnorm(). * * Revision 1.4 1997/10/16 14:27:05 kn * Add missing #include. Change in mcreadparams() to fit better with the * "display" visualization tool. * * Revision 1.3 1997/09/08 11:31:22 kn * Added mcsetstate() function. * * Revision 1.2 1997/09/08 11:16:43 kn * Bug fix in mccoordschange(). * * Revision 1.1 1997/09/08 10:40:03 kn * Initial revision * * * Copyright (C) Risoe National Laboratory, 1997-1998, All rights reserved *******************************************************************************/ #include #include #include #ifndef MCSTAS_R_H #include "mcstas-r.h" #endif #ifdef MC_ANCIENT_COMPATIBILITY int mctraceenabled = 0; int mcdefaultmain = 0; #endif /* Assign coordinates. */ Coords coords_set(MCNUM x, MCNUM y, MCNUM z) { Coords a; a.x = x; a.y = y; a.z = z; return a; } /* Add two coordinates. */ Coords coords_add(Coords a, Coords b) { Coords c; c.x = a.x + b.x; c.y = a.y + b.y; c.z = a.z + b.z; return c; } /* Subtract two coordinates. */ Coords coords_sub(Coords a, Coords b) { Coords c; c.x = a.x - b.x; c.y = a.y - b.y; c.z = a.z - b.z; return c; } /* Negate coordinates. */ Coords coords_neg(Coords a) { Coords b; b.x = -a.x; b.y = -a.y; b.z = -a.z; return b; } /******************************************************************************* * Get transformation for rotation first phx around x axis, then phy around y, * then phz around z. *******************************************************************************/ void rot_set_rotation(Rotation t, double phx, double phy, double phz) { double cx = cos(phx); double sx = sin(phx); double cy = cos(phy); double sy = sin(phy); double cz = cos(phz); double sz = sin(phz); t[0][0] = cy*cz; t[0][1] = sx*sy*cz + cx*sz; t[0][2] = sx*sz - cx*sy*cz; t[1][0] = -cy*sz; t[1][1] = cx*cz - sx*sy*sz; t[1][2] = sx*cz + cx*sy*sz; t[2][0] = sy; t[2][1] = -sx*cy; t[2][2] = cx*cy; } /******************************************************************************* * Matrix multiplication of transformations (this corresponds to combining * transformations). After rot_mul(T1, T2, T3), doing T3 is equal to doing * first T2, then T1. * Note that T3 must not alias (use the same array as) T1 or T2. *******************************************************************************/ void rot_mul(Rotation t1, Rotation t2, Rotation t3) { int i,j, k; for(i = 0; i < 3; i++) for(j = 0; j < 3; j++) t3[i][j] = t1[i][0]*t2[0][j] + t1[i][1]*t2[1][j] + t1[i][2]*t2[2][j]; } /******************************************************************************* * Copy a rotation transformation (needed since arrays cannot be assigned in C). *******************************************************************************/ void rot_copy(Rotation dest, Rotation src) { dest[0][0] = src[0][0]; dest[0][1] = src[0][1]; dest[0][2] = src[0][2]; dest[1][0] = src[1][0]; dest[1][1] = src[1][1]; dest[1][2] = src[1][2]; dest[2][0] = src[2][0]; dest[2][1] = src[2][1]; dest[2][2] = src[2][2]; } void rot_transpose(Rotation src, Rotation dst) { dst[0][0] = src[0][0]; dst[0][1] = src[1][0]; dst[0][2] = src[2][0]; dst[1][0] = src[0][1]; dst[1][1] = src[1][1]; dst[1][2] = src[2][1]; dst[2][0] = src[0][2]; dst[2][1] = src[1][2]; dst[2][2] = src[2][2]; } Coords rot_apply(Rotation t, Coords a) { Coords b; b.x = t[0][0]*a.x + t[0][1]*a.y + t[0][2]*a.z; b.y = t[1][0]*a.x + t[1][1]*a.y + t[1][2]*a.z; b.z = t[2][0]*a.x + t[2][1]*a.y + t[2][2]*a.z; return b; } void mccoordschange(Coords a, Rotation t, double *x, double *y, double *z, double *vx, double *vy, double *vz, double *time, double *s1, double *s2) { Coords b, c; b.x = *x; b.y = *y; b.z = *z; c = rot_apply(t, b); b = coords_add(c, a); *x = b.x; *y = b.y; *z = b.z; b.x = *vx; b.y = *vy; b.z = *vz; c = rot_apply(t, b); *vx = c.x; *vy = c.y; *vz = c.z; /* ToDo: What to do about the spin? */ } double mcestimate_error(int N, double p1, double p2) { double pmean, n1; if(N <= 1) return 0; pmean = p1 / N; n1 = N - 1; return sqrt((N/n1)*(p2 - pmean*pmean)); } void mcreadparams(void) { extern struct mcinputtable_struct mcinputtable[]; int i; for(i = 0; mcinputtable[i].name != 0; i++) { printf("Set value of instrument parameter %s:\n", mcinputtable[i].name); fflush(stdout); scanf("%lf", mcinputtable[i].par); } } void mcsetstate(double x, double y, double z, double vx, double vy, double vz, double t, double s1, double s2, double p) { extern double mcnx, mcny, mcnz, mcnvx, mcnvy, mcnvz; extern double mcnt, mcns1, mcns2, mcnp; mcnx = x; mcny = y; mcnz = z; mcnvx = vx; mcnvy = vy; mcnvz = vz; mcnt = t; mcns1 = s1; mcns2 = s2; mcnp = p; } void mcgenstate(void) { mcsetstate(0, 0, 0, 0, 0, 1, 0, 0, 0, 1); } /* McStas random number routine. */ /* * Copyright (c) 1983 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ /* * This is derived from the Berkeley source: * @(#)random.c 5.5 (Berkeley) 7/6/88 * It was reworked for the GNU C Library by Roland McGrath. * Rewritten to use reentrant functions by Ulrich Drepper, 1995. */ /******************************************************************************* * Modified for McStas from glibc 2.0.7pre1 stdlib/random.c and * stdlib/random_r.c. * * This way random() is more than four times faster compared to calling * standard glibc random() on ix86 Linux, probably due to multithread support, * ELF shared library overhead, etc. It also makes McStas generated * simulations more portable (more likely to behave identically across * platforms, important for parrallel computations). *******************************************************************************/ #define TYPE_3 3 #define BREAK_3 128 #define DEG_3 31 #define SEP_3 3 static mc_int32_t randtbl[DEG_3 + 1] = { TYPE_3, -1726662223, 379960547, 1735697613, 1040273694, 1313901226, 1627687941, -179304937, -2073333483, 1780058412, -1989503057, -615974602, 344556628, 939512070, -1249116260, 1507946756, -812545463, 154635395, 1388815473, -1926676823, 525320961, -1009028674, 968117788, -123449607, 1284210865, 435012392, -2017506339, -911064859, -370259173, 1132637927, 1398500161, -205601318, }; static mc_int32_t *fptr = &randtbl[SEP_3 + 1]; static mc_int32_t *rptr = &randtbl[1]; static mc_int32_t *state = &randtbl[1]; #define rand_deg DEG_3 #define rand_sep SEP_3 static mc_int32_t *end_ptr = &randtbl[sizeof (randtbl) / sizeof (randtbl[0])]; mc_int32_t mc_random (void) { mc_int32_t result; *fptr += *rptr; /* Chucking least random bit. */ result = (*fptr >> 1) & 0x7fffffff; ++fptr; if (fptr >= end_ptr) { fptr = state; ++rptr; } else { ++rptr; if (rptr >= end_ptr) rptr = state; } return result; } void mc_srandom (unsigned int x) { /* We must make sure the seed is not 0. Take arbitrarily 1 in this case. */ state[0] = x ? x : 1; { long int i; for (i = 1; i < rand_deg; ++i) { /* This does: state[i] = (16807 * state[i - 1]) % 2147483647; but avoids overflowing 31 bits. */ long int hi = state[i - 1] / 127773; long int lo = state[i - 1] % 127773; long int test = 16807 * lo - 2836 * hi; state[i] = test + (test < 0 ? 2147483647 : 0); } fptr = &state[rand_sep]; rptr = &state[0]; for (i = 0; i < 10 * rand_deg; ++i) random (); } } /* End of McStas random number routine. */ double randnorm(void) { static double v1, v2, s; static int phase = 0; double X, u1, u2; if(phase == 0) { do { u1 = rand01(); u2 = rand01(); v1 = 2*u1 - 1; v2 = 2*u2 - 1; s = v1*v1 + v2*v2; } while(s >= 1 || s == 0); X = v1*sqrt(-2*log(s)/s); } else { X = v2*sqrt(-2*log(s)/s); } phase = 1 - phase; return X; } /* Written by: EM,NB,ABA 4.2.98 */ int cylinder_intersect(double *t0, double *t1, double x, double y, double z, double vx, double vy, double vz, double r, double h) { double v, D, t_in, t_out, y_in, y_out; v = sqrt(vx*vx+vy*vy+vz*vz); D = (2*vx*x + 2*vz*z)*(2*vx*x + 2*vz*z) - 4*(vx*vx + vz*vz)*(x*x + z*z - r*r); if (D>=0) { t_in = (-(2*vz*z + 2*vx*x) - sqrt(D))/(2*(vz*vz + vx*vx)); t_out = (-(2*vz*z + 2*vx*x) + sqrt(D))/(2*(vz*vz + vx*vx)); y_in = vy*t_in + y; y_out =vy*t_out + y; if ( (y_in > h/2 && y_out > h/2) || (y_in < -h/2 && y_out < -h/2) ) return 0; else { if (y_in > h/2) t_in = ((h/2)-y)/vy; if (y_in < -h/2) t_in = ((-h/2)-y)/vy; if (y_out > h/2) t_out = ((h/2)-y)/vy; if (y_out < -h/2) t_out = ((-h/2)-y)/vy; } *t0 = t_in; *t1 = t_out; return 1; } else { *t0 = *t1 = 0; return 0; } } /* Calculate intersection between line and sphere. */ int sphere_intersect(double *t0, double *t1, double x, double y, double z, double vx, double vy, double vz, double r) { double A, B, C, D, v; v = sqrt(vx*vx + vy*vy + vz*vz); A = v*v; B = 2*(x*vx + y*vy + z*vz); C = x*x + y*y + z*z - r*r; D = B*B - 4*A*C; if(D < 0) return 0; D = sqrt(D); *t0 = (-B - D) / (2*A); *t1 = (-B + D) / (2*A); return 1; } /* Choose random direction towards target at (x,y,z) with given radius. */ /* If radius is zero, choose random direction in full 4PI, no target. */ /* ToDo: It should be possible to optimize this to avoid computing angles. */ void randvec_target_sphere(double *xo, double *yo, double *zo, double *solid_angle, double xi, double yi, double zi, double radius) { double l, theta0, phi, theta, nx, ny, nz, xt, yt, zt; if(radius == 0.0) { /* No target, choose uniformly a direction in full 4PI solid angle. */ theta = acos (1 - rand0max(2)); phi = rand0max(2 * PI); if(solid_angle) *solid_angle = 4*PI; nx = 1; ny = 0; nz = 0; xi = 0; yi = 1; zi = 0; } else { l = sqrt(xi*xi + yi*yi + zi*zi); /* Distance to target. */ theta0 = asin(radius / l); /* Target size as seen from origin */ if(solid_angle) { /* Compute solid angle of target as seen from origin. */ *solid_angle = 2*PI*(1 - cos(theta0)); } /* Now choose point uniformly on sphere surface within angle theta0 */ theta = acos (1 - rand0max(1 - cos(theta0))); phi = rand0max(2 * PI); /* Now, to obtain the desired vector rotate (x,y,z) angle theta around a perpendicular axis (nx,ny,nz) and then angle phi around (x,y,z). */ if(xi == 0 && yi == 0) { nx = 1; ny = 0; nz = 0; } else { nx = -yi; ny = xi; nz = 0; } } rotate(xt, yt, zt, xi, yi, zi, theta, nx, ny, nz); rotate(*xo, *yo, *zo, xt, yt, zt, phi, xi, yi, zi); } /* Number of neutron histories to simulate. */ static double mcncount = 1e6; void mcset_ncount(double count) { mcncount = count; } mcstatic int mcdotrace = 0; static void mcsetn_arg(char *arg) { mcset_ncount(strtod(arg, NULL)); } static void mcsetseed(char *arg) { srandom(atol(arg)); } static void mchelp(char *pgmname) { int i; fprintf(stderr, "Usage: %s [options] [parm=value ...]\n", pgmname); fprintf(stderr, "Options are:\n" " -s seed --seed=seed Set random seed\n" " -n count --ncount=count Set number of neutrons to simulate.\n" " -t --trace Enable trace of neutron through instrument\n" " -h --help Show help message\n" " -i --info Detailed instrument information\n" "Instrument parameters are:\n"); for(i = 0; i < mcnumipar; i++) fprintf(stderr, " %s\n", mcinputtable[i].name); } static void mcshowhelp(char *pgmname) { mchelp(pgmname); exit(0); } static void mcusage(char *pgmname) { fprintf(stderr, "Error: incorrect commad line arguments\n"); mchelp(pgmname); exit(1); } static void mcinfo(void) { int i; printf("Name: %s\n", mcinstrument_name); printf("Parameters:"); for(i = 0; i < mcnumipar; i++) printf(" %s", mcinputtable[i].name); printf("\n"); printf("Instrument-source: %s\n", mcinstrument_source); printf("Trace-enabled: %s\n", mctraceenabled ? "yes" : "no"); printf("Default-main: %s\n", mcdefaultmain ? "yes" : "no"); printf("Embedded-runtime: %s\n", #ifdef MC_EMBEDDED_RUNTIME "yes" #else "no" #endif ); exit(0); } static void mcenabletrace(void) { if(mctraceenabled) mcdotrace = 1; else { fprintf(stderr, "Error: trace not enabled.\n" "Please re-run the McStas compiler with the --trace option\n"); exit(1); } } void mcparseoptions(int argc, char *argv[]) { int i, j, pos; char *p; int paramset = 0, *paramsetarray; paramsetarray = malloc(mcnumipar*sizeof(*paramsetarray)); if(paramsetarray == NULL) { fprintf(stderr, "Error: insufficient memory\n"); exit(1); } for(j = 0; j < mcnumipar; j++) paramsetarray[j] = 0; for(i = 1; i < argc; i++) { if(!strcmp("-s", argv[i]) && (i + 1) < argc) mcsetseed(argv[++i]); else if(!strncmp("-s", argv[i], 2)) mcsetseed(&argv[i][2]); else if(!strcmp("--seed", argv[i]) && (i + 1) < argc) mcsetseed(argv[++i]); else if(!strncmp("--seed=", argv[i], 7)) mcsetseed(&argv[i][7]); else if(!strcmp("-n", argv[i]) && (i + 1) < argc) mcsetn_arg(argv[++i]); else if(!strncmp("-n", argv[i], 2)) mcsetn_arg(&argv[i][2]); else if(!strcmp("--ncount", argv[i]) && (i + 1) < argc) mcsetn_arg(argv[++i]); else if(!strncmp("--ncount=", argv[i], 9)) mcsetn_arg(&argv[i][9]); else if(!strcmp("-h", argv[i])) mcshowhelp(argv[0]); else if(!strcmp("--help", argv[i])) mcshowhelp(argv[0]); else if(!strcmp("-i", argv[i])) mcinfo(); else if(!strcmp("--info", argv[i])) mcinfo(); else if(!strcmp("-t", argv[i])) mcenabletrace(); else if(!strcmp("--trace", argv[i])) mcenabletrace(); else if(argv[i][0] != '-' && (p = strchr(argv[i], '=')) != NULL) { *p++ = '\0'; for(j = 0; j < mcnumipar; j++) if(!strcmp(mcinputtable[j].name, argv[i])) { *(mcinputtable[j].par) = strtod(p, NULL); paramsetarray[j] = 1; paramset = 1; break; } if(j == mcnumipar) { /* Unrecognized parameter name */ fprintf(stderr, "Error: unrecognized parameter %s\n", argv[i]); exit(1); } } else mcusage(argv[0]); } if(!paramset) mcreadparams(); /* Prompt for parameters if not specified. */ else { for(j = 0; j < mcnumipar; j++) if(!paramsetarray[j]) { fprintf(stderr, "Error: Instrument parameter %s left unset\n", mcinputtable[j].name); exit(1); } } } /* McStas main() function. */ int mcstas_main(int argc, char *argv[]) { int run_num = 0; srandom(time(NULL)); mcparseoptions(argc, argv); mcinit(); while(run_num < mcncount) { mcsetstate(0, 0, 0, 0, 0, 1, 0, 0, 0, 1); mcraytrace(); run_num++; } mcfinally(); return 0; } /* End of file "mcstas-r.c". */ int mctraceenabled = 0; int mcdefaultmain = 1; char mcinstrument_name[] = "prisma2"; char mcinstrument_source[] = "examples/prisma2.instr"; int main(int argc, char *argv[]){return mcstas_main(argc, argv);} void mcinit(void); void mcraytrace(void); void mcfinally(void); /* Instrument parameters. */ MCNUM mcipTT; MCNUM mcipPHA; MCNUM mcipPHA1; MCNUM mcipPHA2; MCNUM mcipPHA3; MCNUM mcipPHA4; MCNUM mcipPHA5; MCNUM mcipPHA6; MCNUM mcipPHA7; MCNUM mcipTTA; #define mcNUMIPAR 10 int mcnumipar = 10; struct mcinputtable_struct mcinputtable[mcNUMIPAR+1] = { "TT", &mcipTT, "PHA", &mcipPHA, "PHA1", &mcipPHA1, "PHA2", &mcipPHA2, "PHA3", &mcipPHA3, "PHA4", &mcipPHA4, "PHA5", &mcipPHA5, "PHA6", &mcipPHA6, "PHA7", &mcipPHA7, "TTA", &mcipTTA, NULL, NULL }; /* User declarations from instrument definition. */ #define TT mcipTT #define PHA mcipPHA #define PHA1 mcipPHA1 #define PHA2 mcipPHA2 #define PHA3 mcipPHA3 #define PHA4 mcipPHA4 #define PHA5 mcipPHA5 #define PHA6 mcipPHA6 #define PHA7 mcipPHA7 #define TTA mcipTTA #line 171 "examples/prisma2.instr" int neu_color; /* "Color" of current neutron */ /* 30' mosaicity used on analysator */ double prisma_ana_mosaic = 30; /* Q vector for bragg scattering with monochromator and analysator */ double prisma_ana_q = 1.87325; double prisma_ana_r0 = 0.6; double focus_x,focus_z; double apos1, apos2, apos3, apos4, apos5, apos6, apos7; #undef TTA #undef PHA7 #undef PHA6 #undef PHA5 #undef PHA4 #undef PHA3 #undef PHA2 #undef PHA1 #undef PHA #undef TT /* Declarations of component definition and setting parameters. */ /* Definition parameters for component 'mod'. */ #define mccmod_radius 0.0707 #define mccmod_E0 10 #define mccmod_E1 15 #define mccmod_dist 9.035 #define mccmod_xw 0.021 #define mccmod_yh 0.021 #define mccmod_t0 37.15 #define mccmod_Ec 9 #define mccmod_gam 39.1 /* Definition parameters for component 'modslit'. */ #define mccmodslit_xmin -0.05 #define mccmodslit_xmax 0.05 #define mccmodslit_ymin -0.05 #define mccmodslit_ymax 0.05 /* Definition parameters for component 'tof_test'. */ #define mcctof_test_xmin -0.05 #define mcctof_test_xmax 0.05 #define mcctof_test_ymin -0.05 #define mcctof_test_ymax 0.05 #define mcctof_test_nchan 10000 #define mcctof_test_dt 10 #define mcctof_test_filename "sim/prisma2.mon" /* Definition parameters for component 'mon1'. */ #define mccmon1_xmin -0.1 #define mccmon1_xmax 0.1 #define mccmon1_ymin -0.1 #define mccmon1_ymax 0.1 /* Definition parameters for component 'slit1'. */ #define mccslit1_xmin -0.05 #define mccslit1_xmax 0.05 #define mccslit1_ymin -0.05 #define mccslit1_ymax 0.05 /* Definition parameters for component 'slit2'. */ #define mccslit2_xmin -0.02 #define mccslit2_xmax 0.02 #define mccslit2_ymin -0.03 #define mccslit2_ymax 0.03 /* Definition parameters for component 'mon2'. */ #define mccmon2_xmin -0.1 #define mccmon2_xmax 0.1 #define mccmon2_ymin -0.1 #define mccmon2_ymax 0.1 /* Definition parameters for component 'sample'. */ #define mccsample_radius_i 1e-05 #define mccsample_radius_o 0.01 #define mccsample_h 0.02 #define mccsample_pack 1 #define mccsample_focus_r 0.03 /* Setting parameters for component 'sample'. */ MCNUM mccsample_target_x; MCNUM mccsample_target_y; MCNUM mccsample_target_z; /* Definition parameters for component 'mon3'. */ #define mccmon3_xmin -0.1 #define mccmon3_xmax 0.1 #define mccmon3_ymin -0.1 #define mccmon3_ymax 0.1 /* Definition parameters for component 'coll2'. */ #define mcccoll2_xmin -0.015 #define mcccoll2_xmax 0.015 #define mcccoll2_ymin -0.025 #define mcccoll2_ymax 0.025 #define mcccoll2_len 0.12 #define mcccoll2_divergence 120 /* Definition parameters for component 'mon4'. */ #define mccmon4_xmin -0.1 #define mccmon4_xmax 0.1 #define mccmon4_ymin -0.1 #define mccmon4_ymax 0.1 /* Definition parameters for component 'ana1'. */ #define mccana1_zmin -0.006 #define mccana1_zmax 0.006 #define mccana1_ymin -0.0375 #define mccana1_ymax 0.0375 #define mccana1_mosaich prisma_ana_mosaic #define mccana1_mosaicv prisma_ana_mosaic #define mccana1_r0 prisma_ana_r0 #define mccana1_Q prisma_ana_q #define mccana1_color 0 /* Definition parameters for component 'ana2'. */ #define mccana2_zmin -0.006 #define mccana2_zmax 0.006 #define mccana2_ymin -0.0375 #define mccana2_ymax 0.0375 #define mccana2_mosaich prisma_ana_mosaic #define mccana2_mosaicv prisma_ana_mosaic #define mccana2_r0 prisma_ana_r0 #define mccana2_Q prisma_ana_q #define mccana2_color 1 /* Definition parameters for component 'ana3'. */ #define mccana3_zmin -0.006 #define mccana3_zmax 0.006 #define mccana3_ymin -0.0375 #define mccana3_ymax 0.0375 #define mccana3_mosaich prisma_ana_mosaic #define mccana3_mosaicv prisma_ana_mosaic #define mccana3_r0 prisma_ana_r0 #define mccana3_Q prisma_ana_q #define mccana3_color 2 /* Definition parameters for component 'ana4'. */ #define mccana4_zmin -0.006 #define mccana4_zmax 0.006 #define mccana4_ymin -0.0375 #define mccana4_ymax 0.0375 #define mccana4_mosaich prisma_ana_mosaic #define mccana4_mosaicv prisma_ana_mosaic #define mccana4_r0 prisma_ana_r0 #define mccana4_Q prisma_ana_q #define mccana4_color 3 /* Definition parameters for component 'ana5'. */ #define mccana5_zmin -0.006 #define mccana5_zmax 0.006 #define mccana5_ymin -0.0375 #define mccana5_ymax 0.0375 #define mccana5_mosaich prisma_ana_mosaic #define mccana5_mosaicv prisma_ana_mosaic #define mccana5_r0 prisma_ana_r0 #define mccana5_Q prisma_ana_q #define mccana5_color 4 /* Definition parameters for component 'ana6'. */ #define mccana6_zmin -0.006 #define mccana6_zmax 0.006 #define mccana6_ymin -0.0375 #define mccana6_ymax 0.0375 #define mccana6_mosaich prisma_ana_mosaic #define mccana6_mosaicv prisma_ana_mosaic #define mccana6_r0 prisma_ana_r0 #define mccana6_Q prisma_ana_q #define mccana6_color 5 /* Definition parameters for component 'ana7'. */ #define mccana7_zmin -0.006 #define mccana7_zmax 0.006 #define mccana7_ymin -0.0375 #define mccana7_ymax 0.0375 #define mccana7_mosaich prisma_ana_mosaic #define mccana7_mosaicv prisma_ana_mosaic #define mccana7_r0 prisma_ana_r0 #define mccana7_Q prisma_ana_q #define mccana7_color 6 /* Definition parameters for component 'mon5'. */ #define mccmon5_xmin -0.05 #define mccmon5_xmax 0.05 #define mccmon5_ymin -0.05 #define mccmon5_ymax 0.05 /* Definition parameters for component 'mon6'. */ #define mccmon6_xmin -0.1 #define mccmon6_xmax 0.1 #define mccmon6_ymin -0.1 #define mccmon6_ymax 0.1 /* Definition parameters for component 'psd'. */ #define mccpsd_xmin -0.05 #define mccpsd_xmax 0.05 #define mccpsd_ymin -0.05 #define mccpsd_ymax 0.05 #define mccpsd_nx 100 #define mccpsd_ny 100 #define mccpsd_filename "sim/prisma2.psd" /* Definition parameters for component 'detector'. */ #define mccdetector_xmin -0.05 #define mccdetector_xmax 0.05 #define mccdetector_ymin -0.05 #define mccdetector_ymax 0.05 #define mccdetector_nchan 10000 #define mccdetector_dt 10 #define mccdetector_filename "sim/prisma2.tof" #define mccdetector_maxcolor 6 /* Definition parameters for component 'mon9'. */ #define mccmon9_xmin -0.1 #define mccmon9_xmax 0.1 #define mccmon9_ymin -0.1 #define mccmon9_ymax 0.1 /* User component declarations. */ /* User declarations for component 'mod'. */ #define mccompcurname "mod" #define radius mccmod_radius #define E0 mccmod_E0 #define E1 mccmod_E1 #define dist mccmod_dist #define xw mccmod_xw #define yh mccmod_yh #define t0 mccmod_t0 #define Ec mccmod_Ec #define gam mccmod_gam #line 33 "/usr/users/batman/mc01/lib/mcstas/Moderator.comp" double hdiv,vdiv; /* ToDo: Should be component local */ double moder_v0, moder_dv; double p_in; #undef gam #undef Ec #undef t0 #undef yh #undef xw #undef dist #undef E1 #undef E0 #undef radius #undef mccompcurname /* User declarations for component 'tof_test'. */ #define mccompcurname "tof_test" #define xmin mcctof_test_xmin #define xmax mcctof_test_xmax #define ymin mcctof_test_ymin #define ymax mcctof_test_ymax #define nchan mcctof_test_nchan #define dt mcctof_test_dt #define filename mcctof_test_filename #define TOF_N mcctof_test_TOF_N #define TOF_p mcctof_test_TOF_p #define TOF_p2 mcctof_test_TOF_p2 #line 39 "/usr/users/batman/mc01/lib/mcstas/TOF_monitor.comp" int TOF_N[nchan]; double TOF_p[nchan]; double TOF_p2[nchan]; #undef TOF_p2 #undef TOF_p #undef TOF_N #undef filename #undef dt #undef nchan #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'mon1'. */ #define mccompcurname "mon1" #define xmin mccmon1_xmin #define xmax mccmon1_xmax #define ymin mccmon1_ymin #define ymax mccmon1_ymax #define Nsum mccmon1_Nsum #define psum mccmon1_psum #define p2sum mccmon1_p2sum #line 36 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" int Nsum; double psum, p2sum; #undef p2sum #undef psum #undef Nsum #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'mon2'. */ #define mccompcurname "mon2" #define xmin mccmon2_xmin #define xmax mccmon2_xmax #define ymin mccmon2_ymin #define ymax mccmon2_ymax #define Nsum mccmon2_Nsum #define psum mccmon2_psum #define p2sum mccmon2_p2sum #line 36 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" int Nsum; double psum, p2sum; #undef p2sum #undef psum #undef Nsum #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'sample'. */ #define mccompcurname "sample" #define radius_i mccsample_radius_i #define radius_o mccsample_radius_o #define h mccsample_h #define pack mccsample_pack #define focus_r mccsample_focus_r #define target_x mccsample_target_x #define target_y mccsample_target_y #define target_z mccsample_target_z #line 38 "/usr/users/batman/mc01/lib/mcstas/V_sample.comp" /* ToDo: Should be component local names. */ #define V_sigma_a 5.08 /* Absorption cross section per atom (barns) */ #define V_sigma_i 4.935 /* Incoherent scattering cross section per atom (barns) */ #define V_rho (2*pack/(3.024*3.024*3.024)) /* Density of atoms (AA-3) */ #define V_my_s (V_rho * 100 * V_sigma_i) #define V_my_a_v (V_rho * 100 * V_sigma_a * 2200) #undef target_z #undef target_y #undef target_x #undef focus_r #undef pack #undef h #undef radius_o #undef radius_i #undef mccompcurname /* User declarations for component 'mon3'. */ #define mccompcurname "mon3" #define xmin mccmon3_xmin #define xmax mccmon3_xmax #define ymin mccmon3_ymin #define ymax mccmon3_ymax #define Nsum mccmon3_Nsum #define psum mccmon3_psum #define p2sum mccmon3_p2sum #line 36 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" int Nsum; double psum, p2sum; #undef p2sum #undef psum #undef Nsum #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'coll2'. */ #define mccompcurname "coll2" #define xmin mcccoll2_xmin #define xmax mcccoll2_xmax #define ymin mcccoll2_ymin #define ymax mcccoll2_ymax #define len mcccoll2_len #define divergence mcccoll2_divergence #define slope mcccoll2_slope #line 36 "/usr/users/batman/mc01/lib/mcstas/Soller.comp" double slope; #undef slope #undef divergence #undef len #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'mon4'. */ #define mccompcurname "mon4" #define xmin mccmon4_xmin #define xmax mccmon4_xmax #define ymin mccmon4_ymin #define ymax mccmon4_ymax #define Nsum mccmon4_Nsum #define psum mccmon4_psum #define p2sum mccmon4_p2sum #line 36 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" int Nsum; double psum, p2sum; #undef p2sum #undef psum #undef Nsum #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'ana1'. */ #define mccompcurname "ana1" #define zmin mccana1_zmin #define zmax mccana1_zmax #define ymin mccana1_ymin #define ymax mccana1_ymax #define mosaich mccana1_mosaich #define mosaicv mccana1_mosaicv #define r0 mccana1_r0 #define Q mccana1_Q #define color mccana1_color #line 29 "examples/prisma2.instr" #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname /* User declarations for component 'ana2'. */ #define mccompcurname "ana2" #define zmin mccana2_zmin #define zmax mccana2_zmax #define ymin mccana2_ymin #define ymax mccana2_ymax #define mosaich mccana2_mosaich #define mosaicv mccana2_mosaicv #define r0 mccana2_r0 #define Q mccana2_Q #define color mccana2_color #line 29 "examples/prisma2.instr" #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname /* User declarations for component 'ana3'. */ #define mccompcurname "ana3" #define zmin mccana3_zmin #define zmax mccana3_zmax #define ymin mccana3_ymin #define ymax mccana3_ymax #define mosaich mccana3_mosaich #define mosaicv mccana3_mosaicv #define r0 mccana3_r0 #define Q mccana3_Q #define color mccana3_color #line 29 "examples/prisma2.instr" #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname /* User declarations for component 'ana4'. */ #define mccompcurname "ana4" #define zmin mccana4_zmin #define zmax mccana4_zmax #define ymin mccana4_ymin #define ymax mccana4_ymax #define mosaich mccana4_mosaich #define mosaicv mccana4_mosaicv #define r0 mccana4_r0 #define Q mccana4_Q #define color mccana4_color #line 29 "examples/prisma2.instr" #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname /* User declarations for component 'ana5'. */ #define mccompcurname "ana5" #define zmin mccana5_zmin #define zmax mccana5_zmax #define ymin mccana5_ymin #define ymax mccana5_ymax #define mosaich mccana5_mosaich #define mosaicv mccana5_mosaicv #define r0 mccana5_r0 #define Q mccana5_Q #define color mccana5_color #line 29 "examples/prisma2.instr" #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname /* User declarations for component 'ana6'. */ #define mccompcurname "ana6" #define zmin mccana6_zmin #define zmax mccana6_zmax #define ymin mccana6_ymin #define ymax mccana6_ymax #define mosaich mccana6_mosaich #define mosaicv mccana6_mosaicv #define r0 mccana6_r0 #define Q mccana6_Q #define color mccana6_color #line 29 "examples/prisma2.instr" #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname /* User declarations for component 'ana7'. */ #define mccompcurname "ana7" #define zmin mccana7_zmin #define zmax mccana7_zmax #define ymin mccana7_ymin #define ymax mccana7_ymax #define mosaich mccana7_mosaich #define mosaicv mccana7_mosaicv #define r0 mccana7_r0 #define Q mccana7_Q #define color mccana7_color #line 29 "examples/prisma2.instr" #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname /* User declarations for component 'mon5'. */ #define mccompcurname "mon5" #define xmin mccmon5_xmin #define xmax mccmon5_xmax #define ymin mccmon5_ymin #define ymax mccmon5_ymax #define Nsum mccmon5_Nsum #define psum mccmon5_psum #define p2sum mccmon5_p2sum #line 36 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" int Nsum; double psum, p2sum; #undef p2sum #undef psum #undef Nsum #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'mon6'. */ #define mccompcurname "mon6" #define xmin mccmon6_xmin #define xmax mccmon6_xmax #define ymin mccmon6_ymin #define ymax mccmon6_ymax #define Nsum mccmon6_Nsum #define psum mccmon6_psum #define p2sum mccmon6_p2sum #line 36 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" int Nsum; double psum, p2sum; #undef p2sum #undef psum #undef Nsum #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'psd'. */ #define mccompcurname "psd" #define xmin mccpsd_xmin #define xmax mccpsd_xmax #define ymin mccpsd_ymin #define ymax mccpsd_ymax #define nx mccpsd_nx #define ny mccpsd_ny #define filename mccpsd_filename #define PSD_N mccpsd_PSD_N #define PSD_p mccpsd_PSD_p #define PSD_p2 mccpsd_PSD_p2 #line 40 "/usr/users/batman/mc01/lib/mcstas/PSD_monitor.comp" int PSD_N[nx][ny]; double PSD_p[nx][ny]; double PSD_p2[nx][ny]; #undef PSD_p2 #undef PSD_p #undef PSD_N #undef filename #undef ny #undef nx #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'detector'. */ #define mccompcurname "detector" #define xmin mccdetector_xmin #define xmax mccdetector_xmax #define ymin mccdetector_ymin #define ymax mccdetector_ymax #define nchan mccdetector_nchan #define dt mccdetector_dt #define filename mccdetector_filename #define maxcolor mccdetector_maxcolor #define TOF_N mccdetector_TOF_N #define TOF_p mccdetector_TOF_p #define TOF_p2 mccdetector_TOF_p2 #line 99 "examples/prisma2.instr" int TOF_N[maxcolor+1][nchan]; double TOF_p[maxcolor+1][nchan]; double TOF_p2[maxcolor+1][nchan]; #undef TOF_p2 #undef TOF_p #undef TOF_N #undef maxcolor #undef filename #undef dt #undef nchan #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname /* User declarations for component 'mon9'. */ #define mccompcurname "mon9" #define xmin mccmon9_xmin #define xmax mccmon9_xmax #define ymin mccmon9_ymin #define ymax mccmon9_ymax #define Nsum mccmon9_Nsum #define psum mccmon9_psum #define p2sum mccmon9_p2sum #line 36 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" int Nsum; double psum, p2sum; #undef p2sum #undef psum #undef Nsum #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname Coords mcposamod, mcposrmod; Rotation mcrotamod, mcrotrmod; Coords mcposamodslit, mcposrmodslit; Rotation mcrotamodslit, mcrotrmodslit; Coords mcposatof_test, mcposrtof_test; Rotation mcrotatof_test, mcrotrtof_test; Coords mcposamon1, mcposrmon1; Rotation mcrotamon1, mcrotrmon1; Coords mcposaslit1, mcposrslit1; Rotation mcrotaslit1, mcrotrslit1; Coords mcposaslit2, mcposrslit2; Rotation mcrotaslit2, mcrotrslit2; Coords mcposamon2, mcposrmon2; Rotation mcrotamon2, mcrotrmon2; Coords mcposasample, mcposrsample; Rotation mcrotasample, mcrotrsample; Coords mcposaa2, mcposra2; Rotation mcrotaa2, mcrotra2; Coords mcposamon3, mcposrmon3; Rotation mcrotamon3, mcrotrmon3; Coords mcposacoll2, mcposrcoll2; Rotation mcrotacoll2, mcrotrcoll2; Coords mcposamon4, mcposrmon4; Rotation mcrotamon4, mcrotrmon4; Coords mcposarita_ana, mcposrrita_ana; Rotation mcrotarita_ana, mcrotrrita_ana; Coords mcposaana1, mcposrana1; Rotation mcrotaana1, mcrotrana1; Coords mcposaana2, mcposrana2; Rotation mcrotaana2, mcrotrana2; Coords mcposaana3, mcposrana3; Rotation mcrotaana3, mcrotrana3; Coords mcposaana4, mcposrana4; Rotation mcrotaana4, mcrotrana4; Coords mcposaana5, mcposrana5; Rotation mcrotaana5, mcrotrana5; Coords mcposaana6, mcposrana6; Rotation mcrotaana6, mcrotrana6; Coords mcposaana7, mcposrana7; Rotation mcrotaana7, mcrotrana7; Coords mcposaa3, mcposra3; Rotation mcrotaa3, mcrotra3; Coords mcposamon5, mcposrmon5; Rotation mcrotamon5, mcrotrmon5; Coords mcposamon6, mcposrmon6; Rotation mcrotamon6, mcrotrmon6; Coords mcposapsd, mcposrpsd; Rotation mcrotapsd, mcrotrpsd; Coords mcposadetector, mcposrdetector; Rotation mcrotadetector, mcrotrdetector; Coords mcposamon9, mcposrmon9; Rotation mcrotamon9, mcrotrmon9; MCNUM mcnx, mcny, mcnz, mcnvx, mcnvy, mcnvz, mcnt, mcns1, mcns2, mcnp; void mcinit(void) { #define TT mcipTT #define PHA mcipPHA #define PHA1 mcipPHA1 #define PHA2 mcipPHA2 #define PHA3 mcipPHA3 #define PHA4 mcipPHA4 #define PHA5 mcipPHA5 #define PHA6 mcipPHA6 #define PHA7 mcipPHA7 #define TTA mcipTTA #line 184 "examples/prisma2.instr" { focus_x = 0.52 * sin(TT*DEG2RAD); focus_z = 0.52 * cos(TT*DEG2RAD); /* Rita-style analyser. */ { double l = 0.0125; apos1 = -3*l; apos2 = -2*l; apos3 = -1*l; apos4 = 0*l; apos5 = 1*l; apos6 = 2*l; apos7 = 3*l; } } #undef TTA #undef PHA7 #undef PHA6 #undef PHA5 #undef PHA4 #undef PHA3 #undef PHA2 #undef PHA1 #undef PHA #undef TT /* Component initializations. */ /* Initializations for component mod. */ #define mccompcurname "mod" #define radius mccmod_radius #define E0 mccmod_E0 #define E1 mccmod_E1 #define dist mccmod_dist #define xw mccmod_xw #define yh mccmod_yh #define t0 mccmod_t0 #define Ec mccmod_Ec #define gam mccmod_gam #line 38 "/usr/users/batman/mc01/lib/mcstas/Moderator.comp" { hdiv = atan(xw/(2.0*dist)); vdiv = atan(yh/(2.0*dist)); moder_v0 = SE2V*sqrt(E0); moder_dv = SE2V*sqrt(E1) - moder_v0; p_in = (4*hdiv*vdiv)/(4*PI); } #undef gam #undef Ec #undef t0 #undef yh #undef xw #undef dist #undef E1 #undef E0 #undef radius #undef mccompcurname /* Initializations for component modslit. */ /* Initializations for component tof_test. */ #define mccompcurname "tof_test" #define xmin mcctof_test_xmin #define xmax mcctof_test_xmax #define ymin mcctof_test_ymin #define ymax mcctof_test_ymax #define nchan mcctof_test_nchan #define dt mcctof_test_dt #define filename mcctof_test_filename #define TOF_N mcctof_test_TOF_N #define TOF_p mcctof_test_TOF_p #define TOF_p2 mcctof_test_TOF_p2 #line 44 "/usr/users/batman/mc01/lib/mcstas/TOF_monitor.comp" { int i; for (i=0; ixmax || yymax) ABSORB; } #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component tof_test. */ mcDEBUG_COMP("tof_test") mccoordschange(mcposrtof_test, mcrotrtof_test, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "tof_test" #define xmin mcctof_test_xmin #define xmax mcctof_test_xmax #define ymin mcctof_test_ymin #define ymax mcctof_test_ymax #define nchan mcctof_test_nchan #define dt mcctof_test_dt #define filename mcctof_test_filename #define TOF_N mcctof_test_TOF_N #define TOF_p mcctof_test_TOF_p #define TOF_p2 mcctof_test_TOF_p2 #line 55 "/usr/users/batman/mc01/lib/mcstas/TOF_monitor.comp" { int i; PROP_Z0; if (x>xmin && xymin && y= nchan) i = nchan; if(i < 0) { printf("FATAL ERROR: negative time-of-flight.\n"); exit(1); } TOF_N[i]++; TOF_p[i] += p; TOF_p2[i] += p*p; } } #undef TOF_p2 #undef TOF_p #undef TOF_N #undef filename #undef dt #undef nchan #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component mon1. */ mcDEBUG_COMP("mon1") mccoordschange(mcposrmon1, mcrotrmon1, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "mon1" #define xmin mccmon1_xmin #define xmax mccmon1_xmax #define ymin mccmon1_ymin #define ymax mccmon1_ymax #define Nsum mccmon1_Nsum #define psum mccmon1_psum #define p2sum mccmon1_p2sum #line 46 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" { PROP_Z0; if (x>xmin && xymin && yxmax || yymax) ABSORB; } #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component slit2. */ mcDEBUG_COMP("slit2") mccoordschange(mcposrslit2, mcrotrslit2, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "slit2" #define xmin mccslit2_xmin #define xmax mccslit2_xmax #define ymin mccslit2_ymin #define ymax mccslit2_ymax #line 28 "/usr/users/batman/mc01/lib/mcstas/Slit.comp" { PROP_Z0; if (xxmax || yymax) ABSORB; } #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component mon2. */ mcDEBUG_COMP("mon2") mccoordschange(mcposrmon2, mcrotrmon2, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "mon2" #define xmin mccmon2_xmin #define xmax mccmon2_xmax #define ymin mccmon2_ymin #define ymax mccmon2_ymax #define Nsum mccmon2_Nsum #define psum mccmon2_psum #define p2sum mccmon2_p2sum #line 46 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" { PROP_Z0; if (x>xmin && xymin && y dt0) dt += dt1; PROP_DT(dt+t0); /* Point of scattering */ aim_x = target_x-x; /* Vector pointing at target (anal./det.) */ aim_y = target_y-y; aim_z = target_z-z; randvec_target_sphere(&vx, &vy, &vz, &solid_angle, aim_x, aim_y, aim_z, focus_r); NORM(vx, vy, vz); vx *= v; vy *= v; vz *= v; if(!cylinder_intersect(&t0, &t3, x, y, z, vx, vy, vz, radius_o, h)) { /* ??? did not hit cylinder */ printf("FATAL ERROR: Did not hit cylinder from inside.\n"); exit(1); } dt = t3; if(cylinder_intersect(&t1, &t2, x, y, z, vx, vy, vz, radius_i, h) && t2 > 0) dt -= (t2-t1); /* Subtract hollow part */ l_o = v*dt; my_a = V_my_a_v/v; p *= l_full*V_my_s*exp(-(my_a+V_my_s)*(l_i+l_o)); p /= 4*PI/solid_angle; } else ABSORB; } #undef target_z #undef target_y #undef target_x #undef focus_r #undef pack #undef h #undef radius_o #undef radius_i #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component a2. */ mcDEBUG_COMP("a2") mccoordschange(mcposra2, mcrotra2, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define mccompcurname "a2" #undef mccompcurname mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component mon3. */ mcDEBUG_COMP("mon3") mccoordschange(mcposrmon3, mcrotrmon3, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "mon3" #define xmin mccmon3_xmin #define xmax mccmon3_xmax #define ymin mccmon3_ymin #define ymax mccmon3_ymax #define Nsum mccmon3_Nsum #define psum mccmon3_psum #define p2sum mccmon3_p2sum #line 46 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" { PROP_Z0; if (x>xmin && xymin && yxmax || yymax) ABSORB; dt = len/vz; PROP_DT(dt); if (xxmax || yymax) ABSORB; if(slope > 0.0) { phi = fabs(vx/vz); if (phi > slope) ABSORB; else p *= 1.0 - phi/slope; } } #undef slope #undef divergence #undef len #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component mon4. */ mcDEBUG_COMP("mon4") mccoordschange(mcposrmon4, mcrotrmon4, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "mon4" #define xmin mccmon4_xmin #define xmax mccmon4_xmax #define ymin mccmon4_ymin #define ymax mccmon4_ymax #define Nsum mccmon4_Nsum #define psum mccmon4_psum #define p2sum mccmon4_p2sum #line 46 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" { PROP_Z0; if (x>xmin && xymin && y= 0.0) { y += vy*dt; z += vz*dt; t += dt; x = 0.0; if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; neu_color = color; } } else { x = old_x; y = old_y; z = old_z; t = old_t; } } } #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component ana2. */ mcDEBUG_COMP("ana2") mccoordschange(mcposrana2, mcrotrana2, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "ana2" #define zmin mccana2_zmin #define zmax mccana2_zmax #define ymin mccana2_ymin #define ymax mccana2_ymax #define mosaich mccana2_mosaich #define mosaicv mccana2_mosaicv #define r0 mccana2_r0 #define Q mccana2_Q #define color mccana2_color #line 33 "examples/prisma2.instr" { double dphi,tmp1,tmp2,tmp3,vratio,phi,theta0,theta,v,cs,sn; double old_x = x, old_y = y, old_z = z, old_t = t; double dt; if(vx != 0.0 && (dt = -x/vx) >= 0.0) { y += vy*dt; z += vz*dt; t += dt; x = 0.0; if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; neu_color = color; } } else { x = old_x; y = old_y; z = old_z; t = old_t; } } } #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component ana3. */ mcDEBUG_COMP("ana3") mccoordschange(mcposrana3, mcrotrana3, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "ana3" #define zmin mccana3_zmin #define zmax mccana3_zmax #define ymin mccana3_ymin #define ymax mccana3_ymax #define mosaich mccana3_mosaich #define mosaicv mccana3_mosaicv #define r0 mccana3_r0 #define Q mccana3_Q #define color mccana3_color #line 33 "examples/prisma2.instr" { double dphi,tmp1,tmp2,tmp3,vratio,phi,theta0,theta,v,cs,sn; double old_x = x, old_y = y, old_z = z, old_t = t; double dt; if(vx != 0.0 && (dt = -x/vx) >= 0.0) { y += vy*dt; z += vz*dt; t += dt; x = 0.0; if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; neu_color = color; } } else { x = old_x; y = old_y; z = old_z; t = old_t; } } } #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component ana4. */ mcDEBUG_COMP("ana4") mccoordschange(mcposrana4, mcrotrana4, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "ana4" #define zmin mccana4_zmin #define zmax mccana4_zmax #define ymin mccana4_ymin #define ymax mccana4_ymax #define mosaich mccana4_mosaich #define mosaicv mccana4_mosaicv #define r0 mccana4_r0 #define Q mccana4_Q #define color mccana4_color #line 33 "examples/prisma2.instr" { double dphi,tmp1,tmp2,tmp3,vratio,phi,theta0,theta,v,cs,sn; double old_x = x, old_y = y, old_z = z, old_t = t; double dt; if(vx != 0.0 && (dt = -x/vx) >= 0.0) { y += vy*dt; z += vz*dt; t += dt; x = 0.0; if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; neu_color = color; } } else { x = old_x; y = old_y; z = old_z; t = old_t; } } } #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component ana5. */ mcDEBUG_COMP("ana5") mccoordschange(mcposrana5, mcrotrana5, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "ana5" #define zmin mccana5_zmin #define zmax mccana5_zmax #define ymin mccana5_ymin #define ymax mccana5_ymax #define mosaich mccana5_mosaich #define mosaicv mccana5_mosaicv #define r0 mccana5_r0 #define Q mccana5_Q #define color mccana5_color #line 33 "examples/prisma2.instr" { double dphi,tmp1,tmp2,tmp3,vratio,phi,theta0,theta,v,cs,sn; double old_x = x, old_y = y, old_z = z, old_t = t; double dt; if(vx != 0.0 && (dt = -x/vx) >= 0.0) { y += vy*dt; z += vz*dt; t += dt; x = 0.0; if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; neu_color = color; } } else { x = old_x; y = old_y; z = old_z; t = old_t; } } } #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component ana6. */ mcDEBUG_COMP("ana6") mccoordschange(mcposrana6, mcrotrana6, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "ana6" #define zmin mccana6_zmin #define zmax mccana6_zmax #define ymin mccana6_ymin #define ymax mccana6_ymax #define mosaich mccana6_mosaich #define mosaicv mccana6_mosaicv #define r0 mccana6_r0 #define Q mccana6_Q #define color mccana6_color #line 33 "examples/prisma2.instr" { double dphi,tmp1,tmp2,tmp3,vratio,phi,theta0,theta,v,cs,sn; double old_x = x, old_y = y, old_z = z, old_t = t; double dt; if(vx != 0.0 && (dt = -x/vx) >= 0.0) { y += vy*dt; z += vz*dt; t += dt; x = 0.0; if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; neu_color = color; } } else { x = old_x; y = old_y; z = old_z; t = old_t; } } } #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component ana7. */ mcDEBUG_COMP("ana7") mccoordschange(mcposrana7, mcrotrana7, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "ana7" #define zmin mccana7_zmin #define zmax mccana7_zmax #define ymin mccana7_ymin #define ymax mccana7_ymax #define mosaich mccana7_mosaich #define mosaicv mccana7_mosaicv #define r0 mccana7_r0 #define Q mccana7_Q #define color mccana7_color #line 33 "examples/prisma2.instr" { double dphi,tmp1,tmp2,tmp3,vratio,phi,theta0,theta,v,cs,sn; double old_x = x, old_y = y, old_z = z, old_t = t; double dt; if(vx != 0.0 && (dt = -x/vx) >= 0.0) { y += vy*dt; z += vz*dt; t += dt; x = 0.0; if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; neu_color = color; } } else { x = old_x; y = old_y; z = old_z; t = old_t; } } } #undef color #undef Q #undef r0 #undef mosaicv #undef mosaich #undef ymax #undef ymin #undef zmax #undef zmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component a3. */ mcDEBUG_COMP("a3") mccoordschange(mcposra3, mcrotra3, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define mccompcurname "a3" #undef mccompcurname mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component mon5. */ mcDEBUG_COMP("mon5") mccoordschange(mcposrmon5, mcrotrmon5, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "mon5" #define xmin mccmon5_xmin #define xmax mccmon5_xmax #define ymin mccmon5_ymin #define ymax mccmon5_ymax #define Nsum mccmon5_Nsum #define psum mccmon5_psum #define p2sum mccmon5_p2sum #line 46 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" { PROP_Z0; if (x>xmin && xymin && yxmin && xymin && yxmin && xymin && yxmin && xymin && y= nchan) i = nchan; if(i < 0) { printf("FATAL ERROR: negative time-of-flight.\n"); exit(1); } if(neu_color < 0 || neu_color > maxcolor) { printf("FATAL ERROR: wrong color neutron.\n"); exit(1); } TOF_N[neu_color][i]++; TOF_p[neu_color][i] += p; TOF_p2[neu_color][i] += p*p; } } #undef TOF_p2 #undef TOF_p #undef TOF_N #undef maxcolor #undef filename #undef dt #undef nchan #undef ymax #undef ymin #undef xmax #undef xmin #undef mccompcurname #undef p #undef s2 #undef s1 #undef t #undef vz #undef vy #undef vx #undef z #undef y #undef x mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) /* Component mon9. */ mcDEBUG_COMP("mon9") mccoordschange(mcposrmon9, mcrotrmon9, &mcnlx, &mcnly, &mcnlz, &mcnlvx, &mcnlvy, &mcnlvz, &mcnlt, &mcnls1, &mcnls2); mcDEBUG_STATE(mcnlx, mcnly, mcnlz, mcnlvx, mcnlvy, mcnlvz,mcnlt,mcnls1,mcnls2, mcnlp) #define x mcnlx #define y mcnly #define z mcnlz #define vx mcnlvx #define vy mcnlvy #define vz mcnlvz #define t mcnlt #define s1 mcnls1 #define s2 mcnls2 #define p mcnlp #define mccompcurname "mon9" #define xmin mccmon9_xmin #define xmax mccmon9_xmax #define ymin mccmon9_ymin #define ymax mccmon9_ymax #define Nsum mccmon9_Nsum #define psum mccmon9_psum #define p2sum mccmon9_p2sum #line 46 "/usr/users/batman/mc01/lib/mcstas/Monitor.comp" { PROP_Z0; if (x>xmin && xymin && y (message from stuart on Fri, 12 Feb 1999 14:07:59 +0100) Message-ID: Hi Stuart, Ok, I was able to reproduce the problem on out alpha machine, and find the cause. I assume that your problem was similar. The problem is that, by default, the Digital Unix C compiler 'cc' is not fully ANSI-C compliant. McStas simulations require an ANSI-C compiler. Unfortunately, 'cc' by default is close enought to ANSI-C so that no compilation errors occur, it just generates bad code! To enable full ANSI-C support, the Digital Unix compiler requires the '-std1' flag. Thus, when I compiled the prisma2 simulation using the command cc -std1 -o prisma2.out prisma2.c -lm the simulation produced the correct results. Probably this will solve your problem also. Anyway, it is good that you pointed out this problem; it is clearly something that we need to address in future releases of McStas. - Kristian. From stuart at studsvik.uu.se Wed Feb 17 15:33:26 1999 From: stuart at studsvik.uu.se (stuart) Date: Wed, 17 Feb 1999 15:33:26 +0100 Subject: Mcstas example programs References: <01J7ROSXDAS28ZE4J0@risoe.dk> Message-ID: <36CAD335.92A27EBF@studsvik.uu.se> Hi I used the extra option in the compilation and now get counts in the detector file. However I'm still uncertain that I get the correct result. I've attached the resulting detector file when the simulation was executed using the command ./prisma2.out --ncount=2e6 TT=-30 PHA=22 PHA1=-3 PHA2=-2 PHA3=-1 PHA4=0 PHA5=1 PHA6=2 PHA7=3 TTA=44 I wondered if you let me know if it is working OK now. Thankyou, Stuart Rycroft -------------- next part -------------- A non-text attachment was scrubbed... Name: prisma2.psd Type: application/x-unknown-content-type-photoshop.image.4 Size: 62620 bytes Desc: not available URL: From kristian.nielsen at risoe.dk Thu Feb 18 10:52:54 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 18 Feb 1999 10:52:54 +0100 Subject: Mcstas example programs In-Reply-To: <36CAD335.92A27EBF@studsvik.uu.se> (message from stuart on Wed, 17 Feb 1999 15:33:26 +0100) Message-ID: > I used the extra option in the compilation and now get counts in the > detector file. However I'm still uncertain that I get the correct result. > I've attached the resulting detector file when the simulation was executed > using the command > > ./prisma2.out --ncount=2e6 TT=-30 PHA=22 PHA1=-3 PHA2=-2 PHA3=-1 PHA4=0 > PHA5=1 PHA6=2 PHA7=3 TTA=44 > > I wondered if you let me know if it is working OK now. I compared the file you sent me with my own results, and they matched. So it would appear that things are working ok. Btw, I fully understand your concern about the correctness of the compiler. I had a nasty experience with compiler bugs early in the McStas project. Two different compilers produced wrong code for McStas simulations when optimization was enabled (HPUX ANSI-C compiler and pentium-optimized GCC). - Kristian. From stuart at studsvik.uu.se Mon Feb 22 15:46:23 1999 From: stuart at studsvik.uu.se (stuart) Date: Mon, 22 Feb 1999 15:46:23 +0100 Subject: Mcstas example programs References: <01J7VXBL3PGE8ZE4UR@risoe.dk> Message-ID: <36D16DBD.EABD3522@studsvik.uu.se> Hi Thanks for your time. I have no more problems...yet! Regards, Stuart Rycroft > I compared the file you sent me with my own results, and they > matched. So it would appear that things are working ok. > > Btw, I fully understand your concern about the correctness of the > compiler. I had a nasty experience with compiler bugs early in the > McStas project. Two different compilers produced wrong code for McStas > simulations when optimization was enabled (HPUX ANSI-C compiler and > pentium-optimized GCC). > > - Kristian. From Georg_Artus at Physik.TU-Muenchen.DE Mon Feb 22 18:12:30 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Mon, 22 Feb 1999 17:12:30 +0000 Subject: rounding errors? References: <01J7128DFQD68X83C1@risoe.dk> Message-ID: <36D18FFE.5E8FF413@ph.tum.de> Hello Kristian, today I encountered some results I don't understand. I wanted to examine deltalambda/lambda at the sample and for tracing reasons I set energy detectors right before the monochromator, right after the monochromator and at the sample position. If you plot the curves of all energy detectors into one diagram the curve for the first detector looks ok. It is just an even distribution (without guide). The one at the sample gives you a gaussian like peak, looks ok also. For the energy detector right after the monochromator I would have expected a gaussian like curve with the maximum at the desired wavelength but with higher intensity as the oone at the sample. But the maximum is shifted to longer wavelengths (about 3%)! I've tried several configurations and it is always the same. The attached example shows the effect. Q, theta and lambda should match. How many decimals do you recommend for these values? Is it a rounding error or a stupid error or something else? Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen Neue Forschungsneutronenquelle Garching D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de -------------- next part -------------- DEFINE INSTRUMENT RESI() TRACE COMPONENT arm = Arm() AT (0,0,0) ABSOLUTE COMPONENT source = Source_flat( radius = 0.1, dist = 5.0, xw = 0.04, yh = 0.09, E0 = 81.0425, /* 1AA */ dE = 8.2215) /* delta lambda / lambda = 0.1 */ /* dE = 0.8181) delta lambda / lambda = 0.01 */ AT (0,0,0) RELATIVE arm COMPONENT enbemon = E_monitor( xmin = -0.03, xmax = 0.03, ymin = -0.05, ymax = 0.05, Emin = 72.821, Emax = 89.264, nchan = 10, filename = "enbemon.out") AT (0,0,4.84) RELATIVE arm COMPONENT arm45m = Arm() AT (0,0,5) RELATIVE arm ROTATED (0,45,0) RELATIVE arm COMPONENT arm90m = Arm() AT (0,0,5) RELATIVE arm ROTATED (0,90,0) RELATIVE arm COMPONENT mono = Monochromator( zmin = -0.03, zmax = 0.03, ymin = -0.05, ymax = 0.05, mosaich = 10, mosaicv = 10, r0 = 0.5, Q = 8.88577) /* 45? at 1AA */ AT (0,0,0) RELATIVE arm45m COMPONENT enafmon = E_monitor( xmin = -0.04, xmax = 0.04, ymin = -0.06, ymax = 0.06, Emin = 72.821, Emax = 89.264, nchan = 10, filename = "enafmon.out") AT (0,0,0.1) RELATIVE arm90m COMPONENT ensample = E_monitor( xmin = -0.005, xmax = 0.005, ymin = -0.005, ymax = 0.005, Emin = 72.821, Emax = 89.264, nchan = 10, filename = "ensample.out") AT (0,0,2.0) RELATIVE arm90m COMPONENT psdsamar = PSD_monitor( xmin = -0.03, xmax = 0.03, ymin = -0.07, ymax = 0.07, nx = 30, ny = 70, filename = "psdsamar.out") AT (0,0,2.0) RELATIVE arm90m END From kristian.nielsen at risoe.dk Tue Feb 23 08:53:20 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 23 Feb 1999 08:53:20 +0100 Subject: rounding errors? In-Reply-To: <36D18FFE.5E8FF413@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: Hi Georg, > today I encountered some results I don't understand. I wanted to examine > deltalambda/lambda at the sample and for tracing reasons I set energy > detectors right before the monochromator, right after the monochromator > and at the sample position. If you plot the curves of all energy > detectors into one diagram the curve for the first detector looks ok. It > is just an even distribution (without guide). The one at the sample > gives you a gaussian like peak, looks ok also. For the energy detector > right after the monochromator I would have expected a gaussian like > curve with the maximum at the desired wavelength but with higher > intensity as the oone at the sample. But the maximum is shifted to > longer wavelengths (about 3%)! I've tried several configurations and it > is always the same. > The attached example shows the effect. Q, theta and lambda should match. > How many decimals do you recommend for these values? Is it a rounding > error or a stupid error or something else? Hm, I tried your example, and the results look ok to me. You set the Q value for the monochromator to 8.88577. At 45 degrees I calculate this to correspond to 81.8 meV, and both plots are nicely centered around this value. Did you calculate another energy for this Q? Then perhaps either the constants for unit conversion in McStas are wrong, or you made an error? The spectrum in the energy monitor after the monochromator is not symmetric, as is to be expected; the monochromator scatters symetrically in Q space, which is not symmetric in energy space. I have put a plot of the four detectors on the web page, at http://neutron.risoe.dk/mcstas/support/artus/resi-plot.gif Take a look and see if it looks similar to your results. This also gives you a preview of what the next version of McStas will provide. This plot is produced automatically by running an 'mcplot' front-end after the simulation. Clicking the mouse produces a full-screen version of the plot under the cursor. - Kristian. From Georg_Artus at Physik.TU-Muenchen.DE Tue Feb 23 11:02:02 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Tue, 23 Feb 1999 10:02:02 +0000 Subject: rounding errors? References: <01J82SM9ZMIU8ZFMUK@risoe.dk> Message-ID: <36D27C9A.FB4F69E7@ph.tum.de> Hello, > You set the Q value for the monochromator to 8.88577. At 45 degrees I > calculate this to correspond to 81.8 meV, and both plots are nicely > centered around this value. Did you calculate another energy for this Q? > Then perhaps either the constants for unit conversion in McStas are > wrong, or you made an error? Your plots in fact look much better than mine. Conversion between k, Q, v, E and lambda seems to be the problem. Which formula do you use for calculating Q? For Q=8.88577 I calculate an energy of 81.0425meV at 45?? I calculate it with Q=4*PI*sin(theta)/lambda with E(meV)=81.80425/lamda(AA)**2. Do I have the wrong formula? 81.80425 is correct. Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen Neue Forschungsneutronenquelle Garching D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Tue Feb 23 11:24:30 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 23 Feb 1999 11:24:30 +0100 Subject: rounding errors? In-Reply-To: <36D27C9A.FB4F69E7@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: > Your plots in fact look much better than mine. Conversion between k, Q, > v, E and lambda seems to be the problem. > Which formula do you use for calculating Q? For Q=3D8.88577 I calculate an > energy of 81.0425meV at 45=B0? I calculate it with > Q=3D4*PI*sin(theta)/lambda > with E(meV)=3D81.80425/lamda(AA)**2. > Do I have the wrong formula? 81.80425 is correct. These are the McStas conversion constants (from mcstas-r.h): v[m/s] = 629.719 * k[1/AA] = 437.3949 * sqrt(E[meV]) Thus: E[meV] = (k[1/AA]*629.719/437.3949)**2 k[1/AA] = sqrt(E[meV])*437.3949/*629.719 Q[1/AA] = 4*PI*sin(theta)/lambda = 2*k*sin(theta) = 2*sin(theta)*sqrt(E[meV])*437.3949/*629.719 E=81.0425 meV gives Q=8.8430 1/AA E=81.80425 meV gives Q=8.8844 1/AA Does that clarify? Anyway, this again shows how nice it would be to have support for unit conversions in McStas. Won't be in the upcoming release, though. - Kristian. From Georg_Artus at Physik.TU-Muenchen.DE Tue Feb 23 15:38:29 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Tue, 23 Feb 1999 14:38:29 +0000 Subject: rounding errors? References: <01J82XVQ7SNO8ZFMQV@risoe.dk> Message-ID: <36D2BD65.CB17EBD0@ph.tum.de> Hello, ok, I have to confess a typing error. A 8 was missing in my Q. So the conversion between units is ok within rounding errors. Unfortunately this doesn't solve my problem. Your plot for the curve intensity against wavelength shows a curve symmetrically around the energy which should be selected by the monochromator. Mine still is way off. I have modified the input file slightly. It is attached. I would like to send you my curves I produce with this file. Probrably you can solve the problem at once. I have it in Excel. Can you use that? Or is transmission via Fax better? Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen Neue Forschungsneutronenquelle Garching D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de -------------- next part -------------- DEFINE INSTRUMENT RESI() DECLARE %{ double energy = 81.804246; /* double d_energy = 8.2215; */ double d_energy = 31.804; double l_energy = 50.000; double h_energy = 90.000; %} TRACE COMPONENT arm = Arm() AT (0,0,0) ABSOLUTE COMPONENT source = Source_flat( radius = 0.1, dist = 5.0, xw = 0.04, yh = 0.09, E0 = energy, dE = d_energy) AT (0,0,0) RELATIVE arm COMPONENT enbemon = E_monitor( xmin = -0.03, xmax = 0.03, ymin = -0.05, ymax = 0.05, Emin = l_energy, Emax = h_energy, nchan = 20, filename = "enbemon.out") AT (0,0,4.84) RELATIVE arm COMPONENT arm45m = Arm() AT (0,0,5) RELATIVE arm ROTATED (0,45,0) RELATIVE arm COMPONENT arm90m = Arm() AT (0,0,5) RELATIVE arm ROTATED (0,90,0) RELATIVE arm COMPONENT mono = Monochromator( zmin = -0.03, zmax = 0.03, ymin = -0.05, ymax = 0.05, mosaich = 10, mosaicv = 10, r0 = 0.5, Q = 8.88577) /* 45? at 1AA */ AT (0,0,0) RELATIVE arm45m /* COMPONENT psdafmon = PSD_monitor( xmin = -0.03, xmax = 0.03, ymin = -0.06, ymax = 0.06, nx = 30, ny = 70, filename = "psdafmon.out") AT (0,0,0.1) RELATIVE arm90m */ COMPONENT enafmon = E_monitor( xmin = -0.03, xmax = 0.03, ymin = -0.06, ymax = 0.06, Emin = l_energy, Emax = h_energy, nchan = 20, filename = "enafmon.out") AT (0,0,0.1) RELATIVE arm90m COMPONENT ensample = E_monitor( xmin = -0.005, xmax = 0.005, ymin = -0.005, ymax = 0.005, Emin = l_energy, Emax = h_energy, nchan = 20, filename = "ensample.out") AT (0,0,2.0) RELATIVE arm90m /* COMPONENT psdsamar = PSD_monitor( xmin = -0.03, xmax = 0.03, ymin = -0.07, ymax = 0.07, nx = 30, ny = 70, filename = "psdsamar.out") AT (0,0,2.0) RELATIVE arm90m */ END -------------- next part -------------- A non-text attachment was scrubbed... Name: energie.xls Type: application/vnd.ms-excel Size: 25600 bytes Desc: not available URL: From kristian.nielsen at risoe.dk Wed Feb 24 08:12:47 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 24 Feb 1999 08:12:47 +0100 Subject: rounding errors? In-Reply-To: <36D2BD65.CB17EBD0@ph.tum.de> (Georg_Artus@Physik.TU-Muenchen.DE) Message-ID: > I have modified the input file slightly. It is attached. I would like to > send you my curves I produce with this file. Probrably you can solve the > problem at once. I have it in Excel. Can you use that? Or is > transmission via Fax better? I managed to use the excel files using Excel 5 and a windows emulator. Ah, now I see the problem. Your numbers are all integers, and look like the values of N (neutron events) in the monitors with 5e7 simulated neutrons. That will not work; because of neutron weights, the N values are not very meaningful in McStas. You need to use the I values instead (the 3rd column in the file). In about half an hour, I will put up a new plot on http://neutron.risoe.dk/mcstas/support/artus/resi2-plot.gif for you to see. Hm, I wonder if a better file format would have helped to avoid this problem for you. I am in the process of designing a proper output file format for McStas. Do you have any suggestions resulting from your experience with McStas? I am considering NeXus, of course. There will also be an ASCII format, the challenge of which is to remain compatible with many different programs (excel, matlab, perldl, gnuplot, ...) while getting as much information in as possible. - Kristian. From bernhard at amos.krist.uni-erlangen.de Wed Feb 24 13:38:18 1999 From: bernhard at amos.krist.uni-erlangen.de (Philipp Bernhardt) Date: Wed, 24 Feb 1999 13:38:18 +0100 (MET) Subject: Visiting =?UNKNOWN?Q?Ris=F8?= In-Reply-To: <01J7TB7EWMEE8ZEABA@risoe.dk> Message-ID: Hi Kristian, I'm sorry, I still don't know, if it is possible to visit Risoe, because I still no possibility to ask Mr Magerl. Is there any interest from Laszlo, because then we could coordinate the times. I have also found a small bug in the Bender. I didn't initialize the variable arg, which is the argument for the calculation of the reflection coefficient for top and bottom, and if Q is smaller than the critical vector Qcs, arg is keeping the value from the neutron before, so especially in cases of Ni58 at top and bottom there will be too small transmissions. But maybe we can discuss this when I'm in Denmark. - Philipp -------------- next part -------------- /******************************************************************************* * * Component: Bender * * Written by: Philipp Bernhardt, Februar 7 1999 * modified Februar 22 1999 * * Models a curved neutron guide. The entrance lies in the X-Y plane, centered * on the Z axis. The neutrons will also leave the bender in the X-Y plane at * the z-value r*Win, so you do not have to calculate the real exit coordinates * and you do not need a new arm. The bender is bent to the negative X axis; * it behaves like a parallel guide in the Y axis. * There is no warning, if the input parameters are wrong, so please make sure * that * w,h,r,d,Win,k are positive numbers and * k*d is smaller than the width w. * * INPUT PARAMETERS: * * w: (m) Width at the bender entry and exit * h: (m) Height at the bender entry and exit * r: (m) Radius of the bender * d: (m) Thickness of the partition, which separates the channels * Win: (rad) Angle of the deflection of the whole bender * k: (1) Number of channels inside the bender * R0a,Qca,alphaa,ma,Wa: Parameters, which are describing the mirror at concave * side of the bender * R0i,Qci,alphai,mi,Wi: Parameters, which are describing the mirror at convex * side of the bender * R0s,Qcs,alphas,ms,Ws: Parameters, which are describing the mirror at the top * and bottom side of the bender * * Example values: w=0.05 h=0.12 r=250 d=0.001 Win=0.04 k=3 ma=3 mi=2 ms=2 *******************************************************************************/ DEFINE COMPONENT Bender DEFINITION PARAMETERS (w,h,r,d,Win,k,R0a,Qca,alphaa,ma,Wa,R0i,Qci,alphai,mi,Wi,R0s,Qcs,alphas,ms,Ws) SETTING PARAMETERS () OUTPUT PARAMETERS () STATE PARAMETERS (x, y, z, vx, vy, vz, t, s1, s2, p) DECLARE %{ double bk; #ifndef BENDER_DECLARE #define BENDER_DECLARE double sgn(double x) { if (x>=0) return 1.0; else return -1.0; } #endif %} INITIALIZE %{ /* width of one channel + thickness d of partition */ bk=(w+d)/k; %} TRACE %{ int i,num,numa,numi; double dru,ab,dab,R,Q,arg,arga,argi,Ta,vpl; double einwin,auswin,zykwin,aeuwin,innwin,ref,innref,aeuref; double einzei,auszei,zykzei; /* does the neutron hit the bender at the entrance? */ PROP_Z0; if ((fabs(x)>w/2) || (fabs(y)>h/2)) ABSORB; /*** reflections in the XZ-plane ***/ /* distance between neutron and concave side of the channel at the entrance */ dru=floor((w/2-x)/bk)*bk; ab=w/2.0-x-dru; /* radius of the channel */ R=r-dru; /* does the neutron hit the partition at the entrance? */ if (ab>bk-d) ABSORB; /* velocity in the XZ-plane */ vpl=sqrt(vx*vx+vz*vz); /* divergence of the neutron at the entrance */ einwin=atan(vx/vz); /* maximal distance between neutron and concave side of the channel */ dab=R-cos(einwin)*(R-ab); /* reflection angle at the concave side */ aeuwin=acos((R-dab)/R); /* reflection coefficient at the concave side */ arga=0.0; Q=2.0*V2K*vpl*sin(aeuwin); if (Q<=Qca) aeuref=R0a; else { arga=(Q-ma*Qca)/Wa; aeuref=0.5*R0a*(1.0-tanh(arga))*(1.0-alphaa*(Q-Qca)); } /* does the neutron hit the convex side of the channel? */ innwin=0.0; innref=1.0; argi=0.0; if (dab>bk-d) { /* reflection coefficient at the convex side */ innwin=acos((R-dab)/(R-bk+d)); Q=2.0*V2K*vpl*sin(innwin); if (Q<=Qci) innref=R0i; else { argi=(Q-mi*Qci)/Wi; innref=0.5*R0i*(1.0-tanh(argi))*(1.0-alphai*(Q-Qci)); } } /* divergence of the neutron at the exit */ zykwin=2.0*(aeuwin-innwin); auswin=fmod(Win+einwin+aeuwin-innwin*(1.0+sgn(einwin)),zykwin)-zykwin/2.0; auswin+=innwin*sgn(auswin); /* number of reflections at the concave side */ numa=(Win+einwin+aeuwin-innwin*(1.0+sgn(einwin)))/zykwin; /* number of reflections at the convex side */ numi=numa; if (auswin*einwin<0) { if (auswin-einwin>0) numi++; else numi--; } /* is the reflection coefficient too small? */ if (((numa>0) && (arga>10.0)) || ((numi>0) && (argi>10.0))) ABSORB; /* calculation of the neutron probability weight p */ for (i=1;i<=numa;i++) p*=aeuref; for (i=1;i<=numi;i++) p*=innref; /* time to cross the bender */ Ta=(2*numa*(tan(aeuwin)-tan(innwin))+tan(auswin)-tan(einwin)-tan(innwin)* (sgn(auswin)-sgn(einwin)))*(R-dab)/vpl; t+=Ta; /* distance between neutron and concave side of channel at the exit */ ab=R-(R-dab)/cos(auswin); /* calculation of the exit coordinates in the XZ-plane */ x=w/2.0-ab-dru; z=r*Win; vx=sin(auswin)*vpl; vz=cos(auswin)*vpl; /*** reflections at top and bottom side (Y axis) ***/ if (vy!=0.0) { /* reflection coefficent at the top and bottom side */ arg=0.0; Q=2.0*V2K*fabs(vy); if (Q<=Qcs) ref=R0s; else { arg=(Q-ms*Qcs)/Ws; ref=0.5*R0s*(1.0-tanh(arg))*(1.0-alphas*(Q-Qcs)); } /* number of reflections at top and bottom */ einzei=h/2.0/fabs(vy)+y/vy; zykzei=h/fabs(vy); num=(Ta+einzei)/zykzei; /* time between the last reflection and the exit */ auszei=fmod(Ta+einzei,zykzei); /* is the reflection coefficient too small? */ if ((num>0) && (arg>10.0)) ABSORB; /* calculation of the probability weight p */ for (i=1;i<=num;i++) { p*=ref; vy*=-1.0; } /* calculation of the exit coordinate */ y=auszei*vy-vy*h/fabs(vy)/2.0; } %} END From Georg_Artus at Physik.TU-Muenchen.DE Wed Feb 24 11:46:23 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Wed, 24 Feb 1999 10:46:23 +0000 Subject: rounding errors? References: <01J845HDLK428ZFT4Z@risoe.dk> Message-ID: <36D3D87F.414DBDE@ph.tum.de> Hello, > Ah, now I see the problem. Your numbers are all integers, and look like > the values of N (neutron events) in the monitors with 5e7 simulated > neutrons. That will not work; because of neutron weights, the N values > are not very meaningful in McStas. You need to use the I values instead > (the 3rd column in the file). Bingo! Stupid, but probably I was confused because all other monitors have only one column (the correct one) in the output and energy monitors have three. It was rather naive to use the first column without thinking. Unfortunately the patterns of two detectors looked ok that way! > Hm, I wonder if a better file format would have helped to avoid this > problem for you. I am in the process of designing a proper output file > format for McStas. Do you have any suggestions resulting from your > experience with McStas? I am considering NeXus, of course. There will > also be an ASCII format, the challenge of which is to remain compatible > with many different programs (excel, matlab, perldl, gnuplot, ...) while > getting as much information in as possible. A general solution fitting all needs will not be easy. Thousand programs, thousand formats, in practice conversion impossible. So the best thing would be to give the user as much choices as possible instead of fixing anything to one format. May be it would be useful if Mcstas would title any column in output files. So confusion like above might be avoided. Otherwise this might disturb any automated graphical display with other programs afterwards. Comfortable would be to let this be controlled by a user defined option or variable, do it or leave it. I don't know the nexus format and how it can be used by all common programs for graphical display. Which common programs read nexus or which graphic packages do you need for it? May be it would be a good idea for the ascii output, if the user could select the output format. For me it would be very helpful it I could chose '.' or ',' for the decimal separation and blank or tab for separating columns. I'm using Excel under the windows3.11 emulation wabi for display. Unfortunately we only have the german version and I cannot switch to . instead of ,! It's not comfortable but the best I can do. I also have tried Applixware 4.4.1 but there are a lot of flaws in it and this packages still is too uncommon. I'm no fan of Microsoft but Excel and Word are spoken nearly everywhere. :-{ Here some forther suggestion for McStas: Any output files produced by e.g. psd monitors are always overwritten!!! This is a heavy loss of calculated data! It would be advantageous to keep them by version numbers or user defined names or anything like this. For some instruments one needs many conponents of the same type, think of focussing monochromators. It would be nice to have something like a loop construction for such setups in the *.instr files. At the Risoe meeting last November discussion also turned on how to estimate the background. I know this leads very far but I think you could 'easily invert' the simulation if you calculate the neutrons leaving the instrument with weight 1-p. The user may define the hitted material surrounding the instrument (Fe, B4C, PE would be enough) and with some principle interactions (e.g. for three neutron energy reanges) one might get an estimate for background sources around the instrument. Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen Neue Forschungsneutronenquelle Garching D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From Georg_Artus at Physik.TU-Muenchen.DE Mon Mar 1 16:47:31 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Mon, 01 Mar 1999 15:47:31 +0000 Subject: monochromator mosaicites <-> deltalambda/lambda References: <01J7B6X786QI8X95YO@risoe.dk> Message-ID: <36DAB693.4935B094@ph.tum.de> Hello McStas users, I would like to know if any of you has simulated and examined the broadness of the wavelength band at the sample with the energy detector. What would you expect from theory for (delta lambda)/lambda if you vary the mosaicity of the monochromator? Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen Neue Forschungsneutronenquelle Garching D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From Georg_Artus at Physik.TU-Muenchen.DE Tue Mar 2 10:39:48 1999 From: Georg_Artus at Physik.TU-Muenchen.DE (Dr. Georg Artus) Date: Tue, 02 Mar 1999 09:39:48 +0000 Subject: answer of del_k/k References: <199903020444.NAA36918@comp.metro-u.ac.jp> Message-ID: <36DBB1E4.9612D245@ph.tum.de> Hello, thanks for the answer to the del_k/k problem. I fear that all formulas (Cooper&Nathans, Caglioti...) can't describe our instrument. The calculated values are in no agreement with the simulations. I should have given a better description of the instrument in the last mail, I'm sorry. The major problem is, that we use a focussing guide between source and monochromator. So we don't illuminate the monochromator with a point source but with a rectangular source. Also intensity distrubution, kx, ky... before the monochromator do not correspond to a primary beam collimated in a 'classical' way. So any assumptions like triangular or Gaussian profiles are not valid. Does anybody know of a paper with a quantitave (or qualitative) analysis of del_k/k using neutron guides in combination with monochromators and all other usual components? Georg -- ********************************************* Dr. Georg Artus Technische Universitaet Muenchen Neue Forschungsneutronenquelle Garching D-85747 Garching Tel: +49 (0)89/289-14675 Fax: +49 (0)89/289-14666 or 12112 E-mail: gartus at ph.tum.de From kristian.nielsen at risoe.dk Mon Mar 22 14:59:16 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Mon, 22 Mar 1999 14:59:16 +0100 Subject: order of moving and rotating In-Reply-To: <36F0FB1D.F5AABF3F@ph.tum.de> (message from Ralph Gilles on Thu, 18 Mar 1999 14:09:49 +0100) Message-ID: <01J94V8JLJBW90Q8JY@risoe.dk> > Hello Kristian, > > I am working together with Georg Artus on the program MCSTAS and I am very > satisfied how it works. Congratulation to you and your colleague. > > I am responsible for the powder diffractometer in munich. Up to now I > finished simulations from source over neutron guide, monochromator second > neutron guide, soller collimator and to the sample. > > Now I would like to include the sample of you (Al2O3) , another soller > collimator and finally the detector. > > Two questions: > > 1.) Is it possible to save the result at the sample and for scanning the > Bragg peak only to simulate the part sample to detector with an input file > =66rom the sample (to save a lot of computing time), because all calculations > up to the sample are equal if I would like to see a Bragg scan ? > > 2.) Or do you have another idea how to simulate the last part of the > diffractometer efficiently to see how Bragg peaks look like ? > > greetings, Ralph We have so far not had the need to simulate only part of an instrument. All simulations have run sufficiently fast for our purposes, even when doing the whole instrument. It would certainly be possible to do what you suggest. A simple way would be to write a new detector that simply dumps the complete neutron state to a file (x,y,z,vx,vy,vz,p,t). Essentially just one line: fprintf(outfile, "%g %g %g %g %g %g %g %g\n", x,y,z,vx,vy,vz,p,t); (plus some code to open and close the file). A new source component would then be written that simply reads this file: fscanf(outfile, "%lf %lf %lf %lf %lf %lf %lf %lf\n", &x,&y,&z,&vx,&vy,&vz,&p,&t); (again plus some extra open()/close() code). One must be careful about the statistics though, since the same random number sequence is now used for all runs. One could also try to fit the beam profile at the sample or built a histogram and use that in another source component, but handling such a multi-dimentional data set could be difficult. But my advice would be to initially just try and see if the complete simulation is not fast enough. McStas will generate hundreds of neutron histories in the time it takes to read a single neutron state from disk. - Kristian. From kristian.nielsen at risoe.dk Wed Mar 31 20:05:20 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: Wed, 31 Mar 1999 20:05:20 +0200 Subject: New release v1.1 of McStas Message-ID: <01J9HQK48M1Q90RMZK@risoe.dk> I am pleased to announce that McStas v1.1 has been released and may be downloaded from the web site: http://elu-alf-2.risoe.dk/~elu-krni/mcstas/ The main new features include an extended component library, a new and better output file format, and a new "mcplot" graphical front-end, as well as a much improved "mcdisplay" front-end. See the CHANGES file in the distribution for details on what is new in v1.1. As usual, please report any problems so that they may be fixed in a later version. Especially Windows and Macintosh users are encouraged to test the new output file format, since this has potential portability problems that we cannot test ourself at Ris?. There will be a bug-fix release on April 30, so any problems reported before then stand a good chance of a quick solution. - Kristian. -- Kristian Nielsen kristian.nielsen at risoe.dk Ris? National Laboratory Condensed Matter Physics and Chemistry Department Tel. +45 4677 5515 Fax +45 4677 4790 From hansen at ill.fr Wed Mar 10 20:26:26 1999 From: hansen at ill.fr (Thomas Hansen) Date: Wed, 10 Mar 1999 20:26:26 +0100 Subject: cylinder_intersect Message-ID: Dear Kristian, As 'promised', I've got some trouble with mcstas, trying to put in the powder1 sample. In fact, all incoming neutrons are absorbed by the condition: ... if (cylinder_intersect(&t0, &t1, x, y, z, vx, vy, vz, radius, h)) { printf("t0 %lf t1 %lf \n",t0, t1); if (t0 < 0) { ABSORB; } ... I checked the neutron parameters, and a typical neutron comes in with: vx= 15 vy= -29 vz= 2903 m/s x=-0.003 y=-0.014 z= 0.000 m The sample is defined as radius 0.020000 height 0.050000 m And the routine cylinder_intersect gives finally t0 -0.000007 t1 0.000007 Unfortunately that routine cylinder_intersect is not very clear, especially the meanings of D, t_in, y_in etc. The other way round it's probably easy to understand, but coming from the source code to guess the systam is not evident. I'd like to understand what's happening, why my neutron gets a negative time t0 (I guess it's because the neutron arrives already at z=0, so is already IN the sample at that time). If it is okay that the neutron gets a negative time t0, why has it to be excluded from any diffraction, even absorbed? So up to now with the existing components, the neutrons cannot pass the sample. On the other hand, up to that point, the sample position, I managed to simulate fairly well the beam with focussing monochromators etc. and with a better 'neutron production' in my Maxwell source in order to have better efficiency. So now I can at least do rocking curves and check the focussing of the monochromators, also in transmission (I just added xmin and xmax) for my component Monochromator0. Best wishes, Thomas ________________________________________________________________________ Dr.Thomas HANSEN, Science/Diffrac/D20, Institut Laue-Langevin (ILL4-100) BP 156, 38042 GRENOBLE Cedex 9, FRANCE, hansen at ill.fr, http://www.ill.fr Phone (+33/0)4.76.20-70.44 Fax:(~)4.76.48.39.06 Home:(~)4.76.18.05.53 From hansen at ill.fr Wed Mar 10 21:06:40 1999 From: hansen at ill.fr (Thomas Hansen) Date: Wed, 10 Mar 1999 21:06:40 +0100 Subject: mcstas Message-ID: Dear Kristion, Up to now I think that t0 in Powder1.comp may be negative without absorption as this finally gives some diffracted neutron intensity that seems correct. Good night, Thomas ________________________________________________________________________ Dr.Thomas HANSEN, Science/Diffrac/D20, Institut Laue-Langevin (ILL4-100) BP 156, 38042 GRENOBLE Cedex 9, FRANCE, hansen at ill.fr, http://www.ill.fr Phone (+33/0)4.76.20-70.44 Fax:(~)4.76.48.39.06 Home:(~)4.76.18.05.53 From kristian.nielsen at risoe.dk Thu Mar 11 08:35:32 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 11 Mar 1999 08:35:32 +0100 Subject: cylinder_intersect In-Reply-To: (hansen@ill.fr) Message-ID: > As 'promised', I've got some trouble with mcstas, trying to put in the > powder1 sample. In fact, all incoming neutrons are absorbed by the > condition: > ... > if (cylinder_intersect(&t0, &t1, x, y, z, vx, vy, vz, radius, h)) > { > printf("t0 %lf t1 %lf \n",t0, t1); > if (t0 < 0) > { > ABSORB; > } > ... > I checked the neutron parameters, and a typical neutron comes in with: > vx= 15 vy= -29 vz= 2903 m/s > x=-0.003 y=-0.014 z= 0.000 m > The sample is defined as > radius 0.020000 height 0.050000 m > And the routine cylinder_intersect gives finally > t0 -0.000007 t1 0.000007 As you mention yourself, the problem is that the neutron is already in the middle of the sample (z=0) when the sample scattering is computed, so a negative flight time to the sample surface is computed. Since neutrons cannot pass backwards in time, McStas absorbs in this case (of course, it should really provide some warning about this condition; that will be in a later version). This kind of problem is usually caused by overlapping components. My guess is that you have some kind of monitor/detector at the same physical position as the sample, but before the sample in the logical ordering. Move the monitor 0.021 cm closer to the monochromator so that it does not overlap the sample, and I think the problem will be solved. Good luck with your simulations! - Kristian. From hansen at ill.fr Fri Mar 12 10:36:34 1999 From: hansen at ill.fr (Thomas Hansen) Date: Fri, 12 Mar 1999 10:36:34 +0100 Subject: McStas Message-ID: Dear Kristian, You promised some headache in your manual about conventions ... In your proposed convention about xyz a word is missing about rotations, what's their convention? Thanks! Regards, Thomas ________________________________________________________________________ Dr.Thomas HANSEN, Science/Diffrac/D20, Institut Laue-Langevin (ILL4-100) BP 156, 38042 GRENOBLE Cedex 9, FRANCE, hansen at ill.fr, http://www.ill.fr Phone (+33/0)4.76.20-70.44 Fax:(~)4.76.48.39.06 Home:(~)4.76.18.05.53 From kristian.nielsen at risoe.dk Fri Mar 12 10:48:39 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 12 Mar 1999 10:48:39 +0100 Subject: McStas In-Reply-To: (hansen@ill.fr) Message-ID: > You promised some headache in your manual about conventions ... In your > proposed convention about xyz a word is missing about rotations, what's > their convention? I am not quite sure what you mean here ... I do not think we have any special conventions for rotations, since the meanings of rotations is pretty much given when the meaning of the axes is fixed. Eg. once we say that the Y axis is pointing upwards, it is clear what a rotation around the Y axis means. Maybe the following copy of an answer by me on the mailing list will be of help to you, otherwise ask again. - Kristian. ------------------------------------------------------------------------ > Now the question: > I'm trying to optimize the angle of a specific mirror in the neutron > path. From the manual and also the results of the calculations it is not > quite clear to me, how the mirror is moved and rotated and what the > reference points are. Yes, this is a point that can be a bit confusing, and I am planning on writing a clarification in the next version of the manual. But if you approach the issue in the right way, it is not at all complicated. The coordinate system of a component has a position and an orientation. The position is the spatial location of the reference point. The orientation is the direction of the axes. Now, when a component is specified in the instrument definition, it has an AT and a ROTATED specification. The AT specifies the position and the ROTATED specifies the orientation. Thus if component C is AT (x,y,z) relative component A and ROTATED (v,0,0) relative component B, the reference point of C is at (x,y,z) in the coordinate system of A and the axes of C are the axes of B rotated the angle v around the X axis of B. From hansen at ill.fr Fri Mar 12 10:48:35 1999 From: hansen at ill.fr (Thomas Hansen) Date: Fri, 12 Mar 1999 10:48:35 +0100 Subject: McStas Message-ID: Dear Kristian, As for my last question, I found some answer immediately after having send the message. In fact, as you have written, no convention is necessary, but the instrument definition has to be consistent. And I was not consistent, so I had some surprises with monochromator focussing ... So it is not important if the rotations follow some right hand rule or the clockwise sense, you have just to apply the same rule rigorously throughout the instrument, that's all. Sorry for having bothered you with these trivialities! Regards, Thomas ________________________________________________________________________ Dr.Thomas HANSEN, Science/Diffrac/D20, Institut Laue-Langevin (ILL4-100) BP 156, 38042 GRENOBLE Cedex 9, FRANCE, hansen at ill.fr, http://www.ill.fr Phone (+33/0)4.76.20-70.44 Fax:(~)4.76.48.39.06 Home:(~)4.76.18.05.53 From hansen at ill.fr Fri Mar 12 14:21:25 1999 From: hansen at ill.fr (Thomas Hansen) Date: Fri, 12 Mar 1999 14:21:25 +0100 Subject: McStas: String to INSTRUMENT Message-ID: Dear Kristian, Is it possible to give a string (e.g., filename) as input parameter to an INSTRUMENT? Up to now I did not succeed. Thanks a lot, Thomas ________________________________________________________________________ Dr.Thomas HANSEN, Science/Diffrac/D20, Institut Laue-Langevin (ILL4-100) BP 156, 38042 GRENOBLE Cedex 9, FRANCE, hansen at ill.fr, http://www.ill.fr Phone (+33/0)4.76.20-70.44 Fax:(~)4.76.48.39.06 Home:(~)4.76.18.05.53 From kristian.nielsen at risoe.dk Fri Mar 12 15:32:17 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 12 Mar 1999 15:32:17 +0100 Subject: McStas: String to INSTRUMENT In-Reply-To: (hansen@ill.fr) Message-ID: > Dear Kristian, > > Is it possible to give a string (e.g., filename) as input parameter to an > INSTRUMENT? Up to now I did not succeed. No, strings are not possible for instrument parameters, these have to be numbers only. But having strings sound like a good idea, I will add it to my list of future plans for additions. - Kristian. From hansen at ill.fr Thu Mar 11 14:02:44 1999 From: hansen at ill.fr (Thomas Hansen) Date: Thu, 11 Mar 1999 14:02:44 +0100 Subject: cylinder_intersect Message-ID: >> As 'promised', I've got some trouble with mcstas, trying to put in the >> powder1 sample. In fact, all incoming neutrons are absorbed by the >> condition: >> ... >> if (cylinder_intersect(&t0, &t1, x, y, z, vx, vy, vz, radius, h)) >> { >> printf("t0 %lf t1 %lf \n",t0, t1); >> if (t0 < 0) >> { >> ABSORB; >> } >> ... >> I checked the neutron parameters, and a typical neutron comes in with: >> vx= 15 vy= -29 vz= 2903 m/s >> x=-0.003 y=-0.014 z= 0.000 m >> The sample is defined as >> radius 0.020000 height 0.050000 m >> And the routine cylinder_intersect gives finally >> t0 -0.000007 t1 0.000007 > >As you mention yourself, the problem is that the neutron is already in >the middle of the sample (z=0) when the sample scattering is computed, >so a negative flight time to the sample surface is computed. Since >neutrons cannot pass backwards in time, McStas absorbs in this case (of >course, it should really provide some warning about this condition; that >will be in a later version). > >This kind of problem is usually caused by overlapping components. My >guess is that you have some kind of monitor/detector at the same >physical position as the sample, but before the sample in the logical >ordering. Move the monitor 0.021 cm closer to the monochromator so that >it does not overlap the sample, and I think the problem will be solved. > >Good luck with your simulations! > > - Kristian. I am just comming into my office after having had some cross country skiing with lots of snow but spring temperatures ... thanks for your quick answer, in fact, I actually have had, as you may see, a monitor of sample cross section in order to get the flux at sample position - that explains the negative time. ... COMPONENT mon7 = L_monitor(xmin = Sample_xmin, xmax = Sample_xmax, ymin = Sample_ymin, ymax = Sample_ymax, Lmin = Monit_Lmin, Lmax = Monit_Lmax, nchan = Monit_ncan, filename="sim/mon7.dat", columns=Monit_columns) AT (0, 0, 3.2) RELATIVE beta COMPONENT sample = Powder0 (d_phi0 = d_phi0, radius = Sample_r, h = Sample_h, pack = 1, Vc=100, sigma_a = 0, q = HOPG_Q, j = 1, F2 = 1, DW = 1, target_x = 0, target_y = 0, target_z = 1) AT (0,0,3.200) RELATIVE beta ... Ian Anderson encouraged us to comment the necessarity of instrument simulations, the usefullness of McStas in special and to suggest further steps. I will do so soon as I have now some - in spite of difficulties mostly good - experiences and a lot of suggestions - which might make you working hard, if you take everything serious ... Bye, Thomas ________________________________________________________________________ Dr.Thomas HANSEN, Science/Diffrac/D20, Institut Laue-Langevin (ILL4-100) BP 156, 38042 GRENOBLE Cedex 9, FRANCE, hansen at ill.fr, http://www.ill.fr Phone (+33/0)4.76.20-70.44 Fax:(~)4.76.48.39.06 Home:(~)4.76.18.05.53 From kristian.nielsen at risoe.dk Wed Mar 17 14:59:18 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 17 Mar 1999 14:59:18 +0100 Subject: Polarisation in McStas Message-ID: Dear Trefor, Thanks for the copy of your thesis. I have implemented a first version of McStas that can handle polarisation. See http://neutron.risoe.dk/mcstas/support/trefor/mcstas-1.04a.html Let me know if you have any problem. I am really keen on getting polarisation in McStas, so I will do my best to help you getting started on the components that will be needed for doing polarisation. - Kristian. From kristian.nielsen at risoe.dk Thu Mar 18 08:02:51 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 18 Mar 1999 08:02:51 +0100 Subject: McStas pre-release Message-ID: Hi Ron, At my visit at the ILL, I promised you I would send you a pre-release of McStas containing the new graphics front-ends. I have made it available now on the following web page: http://neutron.risoe.dk/mcstas/support/trefor/mcstas-1.04a.html Please do not install this as the official McStas version at the ILL; there are known problems that will be addressed in the official release, which I am currently working hard to release on March 31. But it may be useful to sort out problems with the various libraries (pgplot, pgperl, pdl) before the official release. I hope that everything is well for you and at the ILL, - Kristian. -- Kristian Nielsen kristian.nielsen at risoe.dk Ris? National Laboratory Condensed Matter Physics and Chemistry Department Tel. +45 4677 5515 Fax +45 4677 4790 From roberts at ill.fr Wed Mar 17 15:33:57 1999 From: roberts at ill.fr (Trefor Roberts) Date: Wed, 17 Mar 1999 15:33:57 +0100 Subject: Polarisation in McStas In-Reply-To: <01J8XVRTJ7A890P47O@risoe.dk> Message-ID: Hi Kristian, Crumbs that was quick! I will have a look at this and get back to you when I get stuck or have something useful. Hope that things are fab 'n groovy with you, Cheers Tref >Dear Trefor, > >Thanks for the copy of your thesis. > >I have implemented a first version of McStas that can handle >polarisation. See > > http://neutron.risoe.dk/mcstas/support/trefor/mcstas-1.04a.html > >Let me know if you have any problem. I am really keen on getting >polarisation in McStas, so I will do my best to help you getting started >on the components that will be needed for doing polarisation. > > - Kristian. --------------------------------------------------------------------------- _/ _/ _/ Trefor Roberts _/ _/ _/ Institut Laue Langevin _/ _/ _/ B.P. 156 _/ _/_/_/ _/_/_/ F-38042 Grenoble Cedex 9 France --------------------------------------------------------------------------- Email: roberts at ill.fr Office: ILL4/138 from France: Tel: 04 76 20 75 11 Fax: 04 76 48 39 06 International: Tel: +33 4 76 20 75 11 Fax: +33 4 76 48 39 06 --------------------------------------------------------------------------- From kristian.nielsen at risoe.dk Fri Mar 19 15:15:17 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 19 Mar 1999 15:15:17 +0100 Subject: PhD-Thesis In-Reply-To: <36EE7577.F64EBFED@fz-juelich.de> (message from Oliver Kirstein on Tue, 16 Mar 1999 16:15:03 +0100) Message-ID: Hi Oliver, Thanks for the copy of your thesis, I will look at it later. As I promised you, I have found a copy of the proposal rapport for the new guide system at Ris?, maybe you will find some useful information in it. It is a huge microsoft word file, I hope you will be able to print it (otherwise let me know and I will try to fax you a copy). Because of the size, I put it on our web server, at http://neutron.risoe.dk/mcstas/support/kirstein/GUIDEPRO.DOC Thanks for a pleasant evening in Grenoble! Regards, - Kristian. From kim.lefmann at risoe.dk Fri Mar 19 09:54:47 1999 From: kim.lefmann at risoe.dk (Kim Lefmann) Date: Fri, 19 Mar 1999 09:54:47 +0100 (MET) Subject: mcdisplay Message-ID: <199903190854.JAA15007@fys-hp-1.risoe.dk> ------------- Begin Forwarded Message ------------- >From Bertrand.Roessli at psi.ch Wed Mar 17 10:18:25 MET 1999 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 KAA09418 for ; Wed, 17 Mar 1999 10:18:24 +0100 (MET) From: Bertrand.Roessli at psi.ch Received: from CONVERSION-DAEMON by risoe.dk (PMDF V5.1-10 #28173) id <01J8XLYL5D7K90PDTX at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Wed, 17 Mar 1999 10:18:22 +0100 Received: from pss201.psi.ch by risoe.dk (PMDF V5.1-10 #28173) with SMTP id <01J8XLYIZQRY90OTYT at risoe.dk> for lefmann at fys-hp-1.risoe.dk; Wed, 17 Mar 1999 10:18:20 +0100 Received: from psiclc.psi.ch by pss201.psi.ch; Wed, 17 Mar 1999 10:18:18 +0100 Date: Wed, 17 Mar 1999 10:17:47 +0200 Subject: mcdisplay To: KIM.LEFMANN at risoe.dk Message-id: <99031710174759 at psiclc.psi.ch> X-VMS-To: KIM.LEFMANN at RISOE.DK MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_A2OW15Ck0rUPa2an3E5N6w)" Status: RO Content-Length: 504 Dear Dr. Lefmann, we are currently trying to install the mcstas package at PSI. Mcstas works perfectly, but we have a problem with the mcdisplay command. The error which we get when trying to use it is "Segmentation fault (core dumped)". Do you have any idea what the reason could be? Thank You in advance for helping us. with best regards, B. Roessli ------------- End Forwarded Message ------------- From kristian.nielsen at risoe.dk Mon Mar 22 08:49:44 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 22 Mar 1999 08:49:44 +0100 Subject: mcdisplay In-Reply-To: <199903190854.JAA15007@fys-hp-1.risoe.dk> (message from Kim Lefmann on Fri, 19 Mar 1999 09:54:47 +0100 (MET)) Message-ID: > Dear Dr. Lefmann, > > we are currently trying to install the mcstas package at > PSI. Mcstas works perfectly, but we have a problem with the > mcdisplay command. > The error which we get when trying to use it is "Segmentation fault > (core dumped)". Do you have any idea what the reason could be? Well, that is difficult to say without more information. But the most likely cause is a problem with the PGPLOT library and the pgperl interface between this library and Perl. Could you try running the following one-line command: perl -e 'use PGPLOT;pgbeg(0,"/xserv",1,1);pgenv(0,1,0,2,0,"");pgend' and send me the output? This is a small Perl program that uses PGPLOT; if it works it should produce a window with an empty graph in it. Also information on the machine and operating system you were using would be helpful. - Kristian. -- Kristian Nielsen kristian.nielsen at risoe.dk Ris? National Laboratory Condensed Matter Physics and Chemistry Department Tel. +45 4677 5515 Fax +45 4677 4790 From ron at ill.fr Thu Mar 18 09:25:02 1999 From: ron at ill.fr (Ron Ghosh) Date: Thu, 18 Mar 1999 09:25:02 +0100 Subject: McStas pre-release References: <01J8YVIUPD3U90PIZ2@risoe.dk> Message-ID: <36F0B85E.41C6@ill.fr> Dear Kristian Thanks very much for opening up use of your graphics routines. After deleting a few bits of PDL-2.0 I managed to compile, link and run on my own SGI. For the server version I have encountered one or two problems sharing the perl modules across different directory structures; it is clear the authors have never tried to mix and match modules in such a way. Unfortunately the part that breaks is the documentation and help system. I shall probably re-install perl and PDL etc in the same structure next week and also try out some of the OpenGL/GLX implementations too. The problems of not having a 100% binary installable distribution do require some sensitivity when one tries to identify errors from warning messages in compiling such a great volume of source code, especially when some compilers complain more than others. This I suppose, is why common use of gcc is to be preferred. I shall be away for the next few days, but then I shall complete the shared installation with your graphics, and write a summary web page here. The reactor cycle started yesterday, so most scientists have less time to spend on such work. As I suggested, towards the end of the month we'll have a meeting and review internal activities. Ian and I are planning to meet next week and we'll let you know how we see future developments evolving. I greatly stimulated by your visit, and look forward to a fruitful collaboration. Sincerely, Ron -- Ron Ghosh, Institut Laue Langevin, B.P. 156 tel: +33-476207178 38042 Grenoble cedex 9, FRANCE fax: +33-476483906 From Ralph_Gilles at Physik.TU-Muenchen.DE Thu Mar 18 14:09:49 1999 From: Ralph_Gilles at Physik.TU-Muenchen.DE (Ralph Gilles) Date: Thu, 18 Mar 1999 14:09:49 +0100 Subject: order of moving and rotating References: <01J6U2N5SK528X73N4@risoe.dk> Message-ID: <36F0FB1D.F5AABF3F@ph.tum.de> Hello Kristian, I am working together with Georg Artus on the program MCSTAS and I am very satisfied how it works. Congratulation to you and your colleague. I am responsible for the powder diffractometer in munich. Up to now I finished simulations from source over neutron guide, monochromator second neutron guide, soller collimator and to the sample. Now I would like to include the sample of you (Al2O3) , another soller collimator and finally the detector. Two questions: 1.) Is it possible to save the result at the sample and for scanning the Bragg peak only to simulate the part sample to detector with an input file from the sample (to save a lot of computing time), because all calculations up to the sample are equal if I would like to see a Bragg scan ? 2.) Or do you have another idea how to simulate the last part of the diffractometer efficiently to see how Bragg peaks look like ? greetings, Ralph -- !!! New Address!!! Dr. Ralph Gilles Forschungsreaktor M?nchen II Reaktorstation D-85747 Garching phone.: 049-(0)89-289-14665 fax.: 049-(0)89-289-14666 e-mail: rgilles at ph.tum.de From wildes at ill.fr Fri Mar 19 10:39:28 1999 From: wildes at ill.fr (Andrew Wildes) Date: Fri, 19 Mar 1999 10:39:28 +0100 Subject: Tests on IN14 Message-ID: Hi Gents, Just a little e-mail to let you know what we're planning here at the ILL. I was in Risoe the other week and spoke to Kim concerning some tests we're planning on IN14. The question is: is there any benefit in putting a supermirror 'trompet' between monochromator and sample? We've been given some m=2 supermirror by Ian Anderson and Peter Hoghoj, and have made a test piece of equipment to install it. The dimensions of the entrance of the 'trompet' are fixed, but the horizontal distance of the exit may be changed to create a converging guide. The tests will be backed up by Monte-Carlo simulations using both Jan Saroun's RESTRAX code and your McSTAS code. We've been doing a lot of simulations of IN14 recently as we've been considering changing the current nickel guide for a supermirror guide, and consequently the instrument is well characterised from the technical drawings and the current flux of the instrument has been successfully reproduced. This should be an excellent test of the two Monte-Carlo packages, and will hopefully lend confidence in the simulations we've already done. Myself and Jan will be concentrating on the RESTRAX simulations, Emmanuel Fahri will be doing the simulations in McSTAS. The tests are scheduled to begin on Thursday next week. I've attached at the bottom the tests we're hoping to do and the simulations we'll be carrying out. I'll certainly keep you posted as to how things progress here, otherwise, if you have any comments, questions or queries please let me know! All the best, Andrew ------------------------- Hi Gents, First of all, the information for the second collimator in the configuration file should read something like: 2nd collimator (distance,length,hor1,hor2,ver1,ver2,ro[m-1], gh, gv [Ni nat.]): 90. 82.5 5. ?. 5. 5. 0. 2. 2. 1. 1. i.e. it is an m=2 supermirror, the initial horizontal distance is 5 cm, the final can be adjusted between 5cm and 0.245 cm The tests I propose we do are as a function of ki from 1.1 Message-ID: <36F913D5.3EE656E2@ph.tum.de> Hello Kristian, thanks for your last answer. I try to implement the sample POWDER1 for a structure powder diffractometer. Up to the sample everything is o.k. At the detector I received only a few neutrons less than 10. I checked the detector and the soller in front of detector with a monochromator slab as sample. Both (detector and soller) are o.k. I am sure only the sample makes the problem. I increased the struture factor but I am still far away of around 10 the power of six as I expected. I took the (300) reflex at 68.422 ? in 2 Theta for 1.5469 A-1. I put the input file as an attachment (100fms.txt) and marked with !!!! the part of the sample close to the end. In this part I put a few short questions concerning the sample. Do you find an error in this input file ? I am close to the finish of the simulations and looking forward to your answer. greetings , Ralph -- !!! New Address!!! Dr. Ralph Gilles Forschungsreaktor M?nchen II Reaktorstation D-85747 Garching phone.: 049-(0)89-289-14665 fax.: 049-(0)89-289-14666 e-mail: rgilles at ph.tum.de -------------- next part -------------- DEFINE INSTRUMENT SPODI() TRACE COMPONENT a1 = Arm() AT (0,0,0) ABSOLUTE COMPONENT source = Source_flux( radius = 0.050, dist = 2.000, xw = 0.025, yh = 0.100, E0 = 34.186, /* = 1.5469A*/ dE = 0.342, /* =1.5392A - 1.5546A */ flux = 2.103e+13) AT (0,0,0) RELATIVE a1 COMPONENT part1 = Guide2( w1 = 0.025, h1 = 0.100, w2 = 0.025, h2 = 0.100, l = 2.100, 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.025, h1 = 0.100, w2 = 0.025, h2 = 0.150, l = 12.400, R0 = 1.0, Qc = 0.0214, alpha = 5.617, mh = 3, mv = 2, W = 0.0033) AT (0,0,4.1) RELATIVE a1 /* COMPONENT mon1 = Monitor_flux( xmin = -0.0125, xmax = 0.0125, ymin = -0.075, ymax = 0.075, lmin = 1.5392, lmax = 1.5546) AT (0,0,16.97) RELATIVE a1 COMPONENT psdvm1 = PSD_monitor( xmin = -0.0400, xmax = 0.0400, ymin = -0.15, ymax = 0.15, nx = 8, ny = 30, filename = "psdvm1.out") AT (0,0,16.97) RELATIVE a1 COMPONENT divvm1 = Divergence_monitor( xmin = -0.0400, xmax = 0.0400, ymin = -0.15, ymax = 0.15, nh = 10, nv = 20, h_maxdiv = 0.50, v_maxdiv = 1.00, filename = "divvm1.out") AT (0,0,17.0) RELATIVE a1 */ COMPONENT armtheta = Arm () AT (0,0,17.0) RELATIVE a1 ROTATED (0,77.5,0) RELATIVE a1 COMPONENT armttheta = Arm () AT (0,0,17.0) RELATIVE a1 ROTATED (0,155,0) RELATIVE a1 COMPONENT mono1 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) AT (0,0,0) RELATIVE armtheta COMPONENT mono2 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) AT (0,0.013,0) RELATIVE armtheta ROTATED (0,0,-0.088) RELATIVE armtheta COMPONENT mono3 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) AT (0,-0.013,0) RELATIVE armtheta ROTATED (0,0,0.088) RELATIVE armtheta COMPONENT mono4 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) AT (0,0.026,0) RELATIVE armtheta ROTATED (0,0,-0.188) RELATIVE armtheta COMPONENT mono5 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) AT (0,-0.026,0) RELATIVE armtheta ROTATED (0,0,0.188) RELATIVE armtheta COMPONENT mono6 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) AT (0,0.039,0) RELATIVE armtheta ROTATED (0,0,-0.251) RELATIVE armtheta COMPONENT mono7 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) At (0,-0.039,0) RELATIVE armtheta ROTATED (0,0,0.251) RELATIVE armtheta COMPONENT mono8 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) At (0,0.052,0) RELATIVE armtheta ROTATED (0,0,-0.340) RELATIVE armtheta COMPONENT mono9 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) At (0,-0.052,0) RELATIVE armtheta ROTATED (0,0,0.340) RELATIVE armtheta COMPONENT mono10 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) At (0,0.065,0) RELATIVE armtheta ROTATED (0,0,-0.470) RELATIVE armtheta COMPONENT mono11 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) At (0,-0.065,0) RELATIVE armtheta ROTATED (0,0,0.470) RELATIVE armtheta COMPONENT mono12 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) At (0,0.078,0) RELATIVE armtheta ROTATED (0,0,-0.548) RELATIVE armtheta COMPONENT mono13 = Monochromator( ymin = -0.006, ymax = 0.006, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 0.5, Q = 7.9313) At (0,-0.078,0) RELATIVE armtheta ROTATED (0,0,0.548) RELATIVE armtheta COMPONENT part3 = Guide2( w1 = 0.025, h1 = 0.152, w2 = 0.025, h2 = 0.050, l = 4.000, R0 = 1.0, Qc = 0.0214, alpha = 5.617, mh = 3, mv = 2, W = 0.0033) AT (0,0,0.5) RELATIVE armttheta COMPONENT soller1 = Soller( xmin = -0.0125, xmax = 0.0125, ymin = -0.025, ymax = 0.025, len = 0.30, divergence = 20) AT (0,0,4.5) RELATIVE armttheta COMPONENT mon2 = Monitor_flux( xmin = -0.0125, xmax = 0.0125, ymin = -0.025, ymax = 0.025, lmin = 1.5392, lmax = 1.5546) AT (0,0,4.97) RELATIVE armttheta COMPONENT psdvm2 = PSD_monitor( xmin = -0.0400, xmax = 0.0400, ymin = -0.15, ymax = 0.15, nx = 8, ny = 30, filename = "psdvm2.out") AT (0,0,4.97) RELATIVE armttheta COMPONENT psdvm3 = PSD_monitor( xmin = -0.0125, xmax = 0.0125, ymin = -0.025, ymax = 0.025, nx = 5, ny = 10, filename = "psdvm3.out") AT (0,0,4.97) RELATIVE armttheta COMPONENT psdvm4 = PSD_monitor( xmin = -0.0125, xmax = 0.0125, ymin = -0.025, ymax = 0.025, nx = 25, ny = 50, filename = "psdvm4.out") AT (0,0,4.97) RELATIVE armttheta COMPONENT divnms2 = Divergence_monitor( xmin = -0.0125, xmax = 0.0125, ymin = -0.025, ymax = 0.025, nh = 30, nv = 60, h_maxdiv = 0.5, v_maxdiv = 1.0, filename = "divnms2.out") AT (0,0,4.97) RELATIVE armttheta COMPONENT energ1 = E_monitor( xmin = -0.0125, xmax = 0.0125, ymin = -0.025, ymax = 0.025, Emin = 33.848, Emax = 34.529, nchan = 100, filename = "energ1.out") AT (0,0,4.97) RELATIVE armttheta !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # up to here everything is o.k. I received intensity of 107 # COMPONENT powder1 = Powder1( d_phi0 = 4, # which angle is this exactly ? # radius = 0.0125, h = 0.05, pack = 1, Vc = 85.0054, sigma_a = 0.463, # for 2200 m/s ? is mentioned in your example of TAS1. I assume velocity of selector. So no big change should be for wavelength of 1.54 A-1 ? # q = 4.5713, # q = 4pi sin (() / ( of bragg reflection # j = 6, F2 = 10000, DW = 1, target_x = 0, # I do not understand the meaning of these 3 parameters for target? # target_y = 0, target_z = 1000) AT (0,0,5.0) Relative armttheta !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! /* COMPONENT mono100 = Monochromator( ymin = -0.025, ymax = 0.025, zmin = -0.025, zmax = 0.025, mosaich = 20, mosaicv = 10, r0 = 1.0, Q = 4.5713) AT (0,0,5.0) RELATIVE armttheta ROTATED (0,-34.244,0) RELATIVE armttheta */ Component braggttheta = Arm () AT (0,0,5.0) RELATIVE armttheta ROTATED (0,-68.488,0) RELATIVE armttheta Component soller2 = Soller( xmin = -0.025, xmax = 0.025, ymin = -0.025, ymax = 0.025, len = 0.30, divergence = 10) AT (0,0,0.6) RELATIVE braggttheta COMPONENT psdp5 = PSD_monitor( xmin = -0.125, xmax = 0.125, ymin = -0.125, ymax = 0.125, nx = 25, ny = 50, filename = "psdp5.out") AT (0,0,0.91) RELATIVE braggttheta END From kristian.nielsen at risoe.dk Thu Mar 25 10:38:12 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 25 Mar 1999 10:38:12 +0100 Subject: Error in Calculation of absolute Flux (Source_flux) ??? In-Reply-To: <36F913D5.3EE656E2@ph.tum.de> (message from Ralph Gilles on Wed, 24 Mar 1999 17:33:25 +0100) Message-ID: > Hello Kristian, > > thanks for your last answer. I try to implement the sample POWDER1 for a > structure powder diffractometer. > > Up to the sample everything is o.k. At the detector I received only a few > neutrons less than 10. I checked the detector and the soller in front of > detector with a monochromator slab as sample. Both (detector and soller) are > o.k. I am sure only the sample makes the problem. I increased the struture > factor but I am still far away of around 10 the power of six as I expected. > I took the (300) reflex at 68.422 =B0 in 2 Theta for 1.5469 A-1. Dear Ralph, It was nice to see your simulation, it seems that a lot is happening with McStas in Germany related to the new Munich reactor. I believe that I found the cause of your problems. As you may have suspected, it is related to the meaning of the d_phi0 and target_* parameters for the Powder1 component that you found confusing. That is admittedly tricky, so I will try a quick explanation. See the web page http://elu-alf-2.risoe.dk/~elu-krni/mcstas/components/Powder1/ for a figure that may be helpful. The real powder sample scatters neutrons in the full Debye-Scherrer cone. However that would be wasteful in the simulation since only a small part of the cone represents directions that may hit the detector. Thus the Powder1 component permits to select a part of the Debye-Scherrer cone outside which no neutrons are simulated. The part of the cone is selected by giving the center position and the angular width. The width is specified in d_phi0 i degrees, between 0 and 360. This must be sufficiently large to cover the whole of the detector. The center position is defined by the intersection between the cone and a plane containing the point of scattering, the position of the detector (= the target), and the axis of the cone. In effect, this plane is the scattering plane for the particular sample scattering event. It is not actually necessary to give the precise position of the target, any point in the scattering plane will do. That is the reason for the (1000,0,1000) values you saw in the TAS1 example. I am aware of the difficulties of this aspect and am working on improving the documentation and the implementation. Suggestions are welcome, of course! Anyway, I fixed the sample focusing in your instrument, and get the following detector output: Detector: mon2_I=1.10012e+08 mon2_ERR=1.5974e+06 mon2_N=15226 Detector: psdvm2_I=2.22799e+07 psdvm2_ERR=314281 psdvm2_N=16065 Detector: psdvm3_I=2.11773e+07 psdvm3_ERR=307500 psdvm3_N=15226 Detector: psdvm4_I=2.11773e+07 psdvm4_ERR=307500 psdvm4_N=15226 Detector: divnms2_I=2.0461e+07 divnms2_ERR=302641 divnms2_N=13144 Detector: energ1_I=2.11773e+07 energ1_ERR=307500 energ1_N=15226 Detector: psdp5_I=5614.73 psdp5_ERR=128.712 psdp5_N=6345 which I hope is more reasonable. BTW, I also fixed a potential problem with some components overlapping (especially detectors). This is dangerous, as small rounding errors may cause neutrons to be absorbed, though that appears not to be a problem in your particular case. I am working on a solution to this problem also. You may find the fixed instrument definition at URL http://neutron.risoe.dk/mcstas/support/gilles/spodi.instr Hope this helps, - Kristian. From kristian.nielsen at risoe.dk Sat Mar 27 08:04:21 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 27 Mar 1999 08:04:21 +0100 Subject: order of moving and rotating In-Reply-To: <36FBCAA2.36DF7234@ill.fr> (message from Farhi on Fri, 26 Mar 1999 18:58:12 +0100) Message-ID: > I think this has something to do with the perl version. We have perl5 on SGI's, not on HP's... Ah! You need at least Perl 5. But ths still does not explain the behaviour with double newlines when just running the simulation. I do not have any ideas on this at the moment, but I will think about it. I have not seen that on the HP machine here at Ris?. - Kristian. From farhi at ill.fr Fri Mar 26 18:51:24 1999 From: farhi at ill.fr (Farhi) Date: Fri, 26 Mar 1999 18:51:24 +0100 Subject: newlines References: <01J94V8JLJBW90Q8JY@risoe.dk> Message-ID: <36FBC90A.3325F91C@ill.fr> Hello Kristian We are now performing on IN14/ILL experimental flux test as well as computations for the used configuration with McStas and restrax programs. That should make 3 sets of data to be compared (and one is real !) I'm now using McStas v1.01 beta and there are 2 things that might be fixed perhaps on HP-UX systems : 1- when executing gscan, each '\n' is duplicated, what produces blank lines between each display line in .sim output file : In the following example I get 5 detectors in output 1 -6.95048e+08 9.35462e+06 -5.08249e+08 8.01985e+06 -4.00478e+07 2.2823e+06 -4.00466e+07 2.2823e+06 -2.0727e+07 1.63933e+06 1.2 -1.44675e+09 1.34564e+07 -1.08893e+0 ... instead of 1 -6.95048e+08 9.35462e+06 -5.08249e+08 8.01985e+06 -4.00478e+07 2.2823e+06 -4.00466e+07 2.2823e+06 -2.0727e+07 1.63933e+06 1.2 -1.44675e+09 1.34564e+07 -1.08893e+0 ... 2- This also happens in the direct printf output (on terminal) : running 'in14_4 --ncount=1e8 KI=1 WN=0.03 DM=3.355 MHV=2' Instrument : IN14, v4.00 Flat source, m=2.00 noze, width 0.03 Monochromator : (DM = 3.355) A1 = 69.45, A2 = 138.91 (deg) This doesn't occur on SGI machines, strange. Perhaps this doesn't happen anymore in 1.04a... Cheers. We should have IN14/McStas/Restrax comparison results next week. EF. -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ 6, rue J. Horowitz, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From farhi at ill.fr Fri Mar 26 18:58:12 1999 From: farhi at ill.fr (Farhi) Date: Fri, 26 Mar 1999 18:58:12 +0100 Subject: order of moving and rotating References: <01J94V8JLJBW90Q8JY@risoe.dk> Message-ID: <36FBCAA2.36DF7234@ill.fr> I think this has something to do with the perl version. We have perl5 on SGI's, not on HP's... -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ 6, rue J. Horowitz, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From farhi at ill.fr Fri Mar 26 19:08:07 1999 From: farhi at ill.fr (Farhi) Date: Fri, 26 Mar 1999 19:08:07 +0100 Subject: still searching References: <01J94V8JLJBW90Q8JY@risoe.dk> Message-ID: <36FBCCF4.D7843F37@ill.fr> I think now that with perl on HP's, $firsttime is set for each detector, and that causes an additional \n Note that a direct simulation execution (not with gscan) for 1 parameter set is displayed correctly. I don't really know perl, but it doesn't seem to be very complicated, except for the 'if' syntax that appears quite strange -- -------------------------------------------- Emmanuel FARHI, http://www.ldv.univ-montp2.fr:7082/~manuf \|/ ____ \|/ TAS-Group, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ 6, rue J. Horowitz, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 83. Fax (33/0) 4 76 48 39 06 \__U_/ La Grande Arche, Chateau d'Uriage, 38410 Saint Martin d'Uriage 04 76 59 73 94 From Fabrizio.Semadeni at psi.ch Wed Mar 31 16:55:06 1999 From: Fabrizio.Semadeni at psi.ch (Fabrizio Semadeni) Date: Wed, 31 Mar 1999 15:55:06 +0100 Subject: MCSTAS at PSI Message-ID: Dear Dr. Nielsen, I was told by Dr. Bertrand Roessli, that there are some problems by using the command 'mcdisplay' on our machines. You wanted to know what we have as OS and so on. We work on DEC ALPHA machines with Digital UNIX V4.0D operating system. Our wersion of PGPLOT is the 5.2.0 . We also try the command perl -e ' bla bla ' , it works. Have you got now enough information to see where the problem should be ?? Best Regards Fabrizio Semadeni Fabrizio Semadeni Lab. for Neutron Scattering ETHZ & PSI Bldg. WHGA/131 CH-5232 Villigen PSI Phone: (+41) 56 310.20.91 Fax: 56 310.29.39 E-Mail: Fabrizio.Semadeni at psi.ch __________________________________________________________ Private: 056 442.40.55 Aarauerstr. 16 / 5200 Brugg __________________________________________________________ http://www1.psi.ch/www_lns_hn/lns/adr/fabrizio/framepage.html __________________________________________________________ From kristian.nielsen at risoe.dk Wed Mar 31 16:35:00 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 31 Mar 1999 16:35:00 +0200 Subject: MCSTAS at PSI In-Reply-To: (message from Fabrizio Semadeni on Wed, 31 Mar 1999 15:55:06 +0100) Message-ID: > Dear Dr. Nielsen, > > I was told by Dr. Bertrand Roessli, that there are some problems by using > the command 'mcdisplay' on our machines. You wanted to know what we have as > OS and so on. > > > We work on DEC ALPHA machines with Digital UNIX V4.0D operating system. > Our wersion of PGPLOT is the 5.2.0 . > We also try the command perl -e ' bla bla ' , it works. > > Have you got now enough information to see where the problem should be ?? Unfortunately not; all I know is that running mcdisplay produces a "segmentation fault". I thought that perhaps the Perl<->PGPLOT interface had not been installed properly, but since the command I suggested worked, that is apparently not the reason. Hm. I vaguely remember that some of the drivers in PGPLOT has some problems on 64-bit machines. Since the Alphas are 64-bit, perhaps this could be the reason? I think there is some readme-file in the PGPLOt distribution for the Alpha architecture that mentions this problem. However, since my example command worked I am not sure if this is the the problem. Is there anything else you could tell me, eg. any output on the terminal before the segmentation fault? The output of "perl -V" might also be useful. And running mcdisplay in the Perl debugger: perl -d /usr/local/bin/mcdisplay ... Otherwise, I will try to run mcdisplay on our local Alpha machines and see what turns up. Also, if it is possible for you to give me a temporary account on the machine, I could log in remotely and see if I can solve the problem. I will be on vacation for the next two weeks, but afterwards I will look into the problem. - Kristian. From kristian.nielsen at risoe.dk Wed Mar 31 17:15:14 1999 From: kristian.nielsen at risoe.dk (Kristian Nielsen) Date: 31 Mar 1999 17:15:14 +0200 Subject: Thanks! In-Reply-To: (message from Philipp Bernhardt on Wed, 24 Mar 1999 11:43:02 +0100 (MET)) Message-ID: Hi Philipp, Thank you very much for the manual entries, it was easy to integrate the choppers into the library and manual. (There was a funny thing though: every 512 characters in the postscript figures there was an extra newline ?!?). Thanks also for the bug report on Powder1. - Kristian. From Peter_Link at physik.tu-muenchen.de Wed Mar 10 17:37:23 1999 From: Peter_Link at physik.tu-muenchen.de (Peter Link) Date: Wed, 10 Mar 1999 17:37:23 +0100 Subject: double-bent monochromator component Message-ID: <36E69FC3.72FF21F4@physik.tu-muenchen.de> Dear Kristian, on the basis of the standard monochromator component I tried to develop a realistic double-bent monochromator. I need this for my future triple axis machine and I know of such monochromators for example at focus (PSI). The monochromator is made of n rows and m columns of equally sized slabs. Due to the mechanics there is a small spacing between adjacent slabs. The focussing is done by tilting the individual slabs around their horizontal axe and turning the columns around the column vertical axe. In my component I determine first the slab hit by the neutron, then calculate the tilt horizontal and vertical from row and column number with the focussing radius ( horizontal and vertical focussing is independent) In order to use the same asumptions as in the normal monochromator component I then introduce a coordinate transformation into the rotated coords. At the end I transform back to the ccords of the hole component given by the central slab. I performed some tests with my instrument definition and I think it works, but may be I got some bug which I've overseen and therefore I send it to you. May be there is someone else interested to test it further. I know the for very small focussing radii ( compared to the size ) this can never work and also the small angle approximation may be violated, but i.g. radii are of the dimension of meters compared to sizes of tenth of cm. Hoping that I've produce no nonsense, best regards Peter -- ****************************************** Dr. P. Link IPC Uni G?ttingen Au?enstelle Garching Neue Forschungs- Neutronenquelle Garching ZBE- FRM II- Bau 85747 Garching Tel. 089 2891 4622 Fax. 089 2895 4622 mailto: plink at physik.tu-muenchen.de ****************************************** -------------- next part -------------- /******************************************************************************* * * McStas, version 1.0, released October 26, 1998 * Maintained by Kristian Nielsen and Kim Lefmann, * Risoe National Laboratory, Roskilde, Denmark * * Component: Mon_2foc * * Written by: KL, HMR June 16, 1997 * Rewritten by: KL Oct. 16, 1997 * Added double bent feature by: Peter Link Feb. 12,1999 * * Double bent monochromator which uses a small-mosaicity approximation as well as * the approximation vy^2 << vz^2 + vx^2. * Second order scattering is neglected. * For an unrotated monochromator component, the crystal plane lies in the y-z * plane (ie. parallel to the beam). * * INPUT PARAMETERS: * * zwidth: (horizontal) width of an individual slab * ywidth: (vertical) heigth of an individual slab * gap : typical gap between adjacent slabs * NH : number of slabs horizontal ( columns ) * NV : number of slabs vertical ( rows ) * mosaich: Horisontal mosaic (FWHM) (arc minutes) * mosaicv: Vertical mosaic (FWHM) (arc minutes) * R0: Maximum reflectivity (1) * Q: Scattering vector (AA-1) * RV : radius of vertical focussing (m) * RH : radius of horizontal focussing (m) * *******************************************************************************/ DEFINE COMPONENT Mon_2foc DEFINITION PARAMETERS (zwidth, ywidth, gap, NH, NV, mosaich, mosaicv, r0, Q, RV, RH) SETTING PARAMETERS () STATE PARAMETERS (x,y,z,vx,vy,vz,t,s1,s2,p) DECLARE %{ #define DIV_CUTOFF 2 /* ~ 10^-5 cutoff. */ %} TRACE %{ double dphi,tmp1,tmp2,tmp3,vratio,phi,theta0,theta,v,cs,sn; double zmin,zmax,ymin,ymax,zp,yp,row,col; double tilth,tiltv; /* used to calculate tilt angle of slab */ double sna,snb,csa,csb; double old_x = x, old_y = y, old_z = z, old_t = t; double dt; if(vx != 0.0 && (dt = -x/vx) >= 0.0) { zmax = ((NH*(zwidth+gap))-gap)/2; zmin = -1*zmax; ymax = ((NV*(ywidth+gap))-gap)/2; ymin = -1*ymax; y += vy*dt; z += vz*dt; t += dt; x = 0.0; zp = fmod ( (z-zmin),(zwidth+gap) ); yp = fmod ( (y-ymin),(ywidth+gap) ); /* hit a slab or a gap ? */ if (z>zmin && zymin && y DIV_CUTOFF) { x = old_x; y = old_y; z = old_z; t = old_t; } else { p *= r0*exp(-tmp3*tmp3*4*log(2)); /* Use mosaics */ tmp1 = 2*theta; cs = cos(tmp1); sn = sin(tmp1); tmp2 = cs*vx - sn*vz; vy = vy; vz = cs*vz + sn*vx; vx = tmp2; /* Second: scatering out of plane. Approximation is that Debye-Scherrer cone is a plane */ phi = atan2(vy,vz); /* out-of plane angle */ dphi = (MIN2RAD*mosaicv)/(2*sqrt(2*log(2)))*randnorm(); /* MC choice: */ /* Vertical angle of the crystallite */ vy = vz*tan(phi+2*dphi*sin(theta)); vratio = v/sqrt(vx*vx+vy*vy+vz*vz); vz = vz*vratio; vy = vy*vratio; /* Renormalize v */ vx = vx*vratio; } /* rotate v coords back */ vx = vx*csb*csa-vy*snb*csa+vz*sna; vy = vx*snb+vy*csb; vz = -vx*csb*sna+vy*snb*sna+vz*csa; } else { x = old_x; y = old_y; z = old_z; t = old_t; } } %} END From Peter_Link at physik.tu-muenchen.de Tue Mar 23 09:24:49 1999 From: Peter_Link at physik.tu-muenchen.de (Peter Link) Date: Tue, 23 Mar 1999 09:24:49 +0100 Subject: velocity selector Message-ID: <36F74FD1.796AEE72@physik.tu-muenchen.de> Hi Kristian, here is another component for the McStas comunity. Although I'm aware that in principle one can simulate the function of a mechanical velocity selector with some filter component I tried to create a selector component that is rather close to reality. I tested it with a configuration where I have analytic calculation to compare to and to me it seems O.K. The principle is quite correctly explained in H. Friedrich et al.; Physica B 156&157 (1989) 547 May be some SANS people are interested in this comp too. Have fun, best regards Peter. -- ****************************************** Dr. P. Link IPC Uni G?ttingen Au?enstelle Garching Neue Forschungs- Neutronenquelle Garching ZBE- FRM II- Bau 85747 Garching Tel. 089 2891 4622 Fax. 089 2895 4622 mailto: plink at physik.tu-muenchen.de ****************************************** -------------- next part -------------- /******************************************************************************* * * McStas component for version 1.0, released October 26, 1998 * Peter Link, IPC University of G?ttingen * * Component: Selector * * Written by: Peter Link MARCH 1999 * * velocity selector (helical lamella type) * * * * INPUT PARAMETERS: * * xmin: Lower x bound (m) * xmax: Upper x bound (m) * ymin: Lower y bound (m) * ymax: Upper y bound (m) * len: rotor length (m) * num: number of spokes/lamella (1) * width: width of spokes at beam-center (m) * radius: radius of beam-center (m) * alfa: angle of torsion (deg) * feq: frequency of rotation(1/s) * *******************************************************************************/ DEFINE COMPONENT Selector DEFINITION PARAMETERS (xmin, xmax, ymin, ymax, len, num,width,radius,alfa,feq) SETTING PARAMETERS () STATE PARAMETERS (x,y,z,vx,vy,vz,t,s1,s2,p) TRACE %{ double E; double dt; double open_angle,closed_angle,n_angle_in,n_angle_out; double sel_phase; PROP_Z0; E=VS2E*(vx*vx+vy*vy+vz*vz); if (xxmax || yymax) ABSORB; /* because outside frame */ dt = len/vz; /* get phase angle of selector rotor as MonteCarlo choice only the free space between two neighboring spokes is taken p is adjusted to transmission for parallel beam */ n_angle_in = atan2( x,y+radius)*RAD2DEG; closed_angle = width/radius*RAD2DEG; open_angle = 360/num-closed_angle; sel_phase = open_angle*rand01(); p *= (open_angle/(closed_angle+open_angle)); PROP_DT(dt); if (xxmax || yymax) ABSORB; /* because outside frame */ /* now let's look whether the neutron is still between the same two spokes or absorbed meanwhile */ n_angle_out = atan2(x,y+radius)*RAD2DEG; /* neutron beam might be divergent */ sel_phase = sel_phase + feq*dt*360 - alfa; /* rotor turned, but spokes are torsaded */ if (n_angle_out<(n_angle_in-sel_phase) || n_angle_out>(n_angle_in-sel_phase+open_angle) ) ABSORB; /* because must have passed absorber */ %} END From bernhard at amos.krist.uni-erlangen.de Wed Mar 24 11:43:02 1999 From: bernhard at amos.krist.uni-erlangen.de (Philipp Bernhardt) Date: Wed, 24 Mar 1999 11:43:02 +0100 (MET) Subject: Thanks! In-Reply-To: <01J94V8JLJBW90Q8JY@risoe.dk> Message-ID: Hello Kristian, Thank you very much for the nice visit in Risoe, I have learned a lot of Mcstas and Risoe! Here is the name of the homepage of "Neutron Scattering WWW pages" http://www.neutron.anl.gov/ I have added the components (they have changed a little bit) Chopper.comp First_Chopper.comp together with manuel entries (TEX-format) Chopper.tex, (together with pictures tracho.eps, Chopper.eps) First_chopper.tex So if you like and have enough time till 31 March, you can integrate them to the Mcstas library, but don't hesitate to change the components or manuels to make them conform to the library. I think that there is a small bug in the component Powder1. If you use neutrons, where the reflexion angle theta is bigger than 90 degrees (slow neutrons), theta can't be calculated in the line theta = asin(q_v/(2.0*v)); Best wishes - Philipp -------------- next part -------------- /********************************************************************************************** * * Component: Chopper * * Written by: Philipp Bernhardt, Januar 22 1999 * * Models a disc chopper with n identical slits, which are symmetrically disposed on the disc. * * INPUT PARAMETERS: * * w: (m) Width of the slits at the bottom side * R: (m) Radius of the disc * f: (rad/s) angular frequency of the Chopper (algebraic sign defines the direction * of rotation * n: (1) Number of slits * pha: (s) Phase * * Example values: w=0.05 R=0.5 f=2500 n=3 pha=0 ************************************************************************************************/ DEFINE COMPONENT Chopper DEFINITION PARAMETERS (w, R, f, n, pha) SETTING PARAMETERS () OUTPUT PARAMETERS () STATE PARAMETERS (x, y, z, vx, vy, vz, t, s1, s2, p) DECLARE %{ double Tg,To; %} INITIALIZE %{ /* time between two pulses */ Tg=2*PI/fabs(f)/n; /* how long can neutrons pass the Chopper at a single point */ To=2*atan(w/R/2.0)/fabs(f); %} TRACE %{ double toff; PROP_Z0; toff=fabs(t-atan2(x,y+R)/f-pha)+To/2.0; /* does neutron hit the slit? */ if (fmod(toff,Tg)>To) ABSORB; %} END -------------- next part -------------- /********************************************************************************************** * * Component: First_Chopper * * Written by: Philipp Bernhardt, Januar 22 1999 * * Models a disc chopper at the first place. * * INPUT PARAMETERS: * * w: (m) Width of the slits * R: (m) Radius of the Chopper * f: (rad/s) angular frequency of the Chopper * n: (1) Number of slits * pha: (s) Phase * a: (1) Number of pulses * * Example values: w=0.05 R=0.5 f=2500 n=3 pha=0 a=2 ************************************************************************************************/ DEFINE COMPONENT First_Chopper DEFINITION PARAMETERS (w, R, f, n, pha, a) SETTING PARAMETERS () OUTPUT PARAMETERS () STATE PARAMETERS (x, y, z, vx, vy, vz, t, s1, s2, p) DECLARE %{ double Tg,To; %} INITIALIZE %{ /* time between two pulses */ Tg=2.0*PI/fabs(f)/n; /* how long can neutrons pass the Chopper at a single position? */ To=2.0*atan(w/R/2.0)/fabs(f); %} TRACE %{ PROP_Z0; t=atan2(x,y+R)/f+To*(rand01()-0.5)+pha+floor(a*rand01())*Tg; %} END -------------- next part -------------- \documentclass{article} \usepackage{english,latexsym} \usepackage{epsfig} \begin{document} \section{Disc Chopper} To cut a continuous neutron beam into short pulses, you can use a disc chopper (figure 1). This is a fast rotating disc with the rotating axe parallel to the neutron beam. The disk consists of neutron absorbing materials. To form the pulses there are slits, where the neutrons can pass. \begin{figure}[h] \includegraphics[width=1.0\linewidth]{Chopper.eps} \caption{disc chopper} \end{figure} This component simulates choppers with more than one slit. The slits are symmetrically disposed on the disc. You can set the direction of rotation, which allows to simulate double choppers. You can also define the phase by setting the time, at which one slit is heading to the top. The sides of the slits are heading to the center of the disc. The thickness of the disc is neglected. There is no parameter for the height of the slits, so if you like to limit the neutrons in the y-direction, just use a slit-component in front of the chopper. If you use a rectangular shaped beam and the beam has nearly the same size as the slit, you will get almost a triangular shape of the transmission curve (figure 2). \begin{figure}[h] \includegraphics[width=1.0\linewidth]{tracho.eps} \caption{example for a transmission curve for the disc chopper} \end{figure} The input parameters for this component are the width w of the slit at the radius R of the disc, the phase pha, the number of slits n and the angular frequency f. The sign of f defines the direction of rotation, as can be seen in figure 1. \end{document} -------------- next part -------------- \documentclass{article} \usepackage{english,latexsym} \usepackage{epsfig} \begin{document} \section{First Disc Chopper} The disadvantage of the component 'Chopper' is the bad statistic, because most of the neutrons of a continuous beam are absorbed. Furthermore TOF-instruments define the starting time of the neutrons at the position of the first chopper and not at the source. Therefore this component is useful. This `first disc chopper` has the same geometrical and physical attributes as the normal disc chopper before. But it doesn't investigate, if the neutron could pass the disc chopper, it gives the neutron a time, at which it is possible to pass. There isn't any absorption in this component, all neutrons will be used. Because the value t of the incoming neutron will be overwritten, this chopper can only be used as a first chopper. The input parameters are, again, the width w of the slit at the radius R of the disc, the phase pha of the chopper, the number of slits n and the angular frequency f (sign defines direction of rotation). With the additional parameter a you can set the number of pulses. This is useful, if you want to investigate frame overlaps. \end{document} -------------- next part -------------- A non-text attachment was scrubbed... Name: tracho.eps Type: application/postscript Size: 6209 bytes Desc: URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Chopper.eps Type: application/postscript Size: 8243 bytes Desc: URL: