From peter.willendrup at risoe.dk Tue Oct 1 15:00:08 2002 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Tue, 01 Oct 2002 15:00:08 +0200 (CEST) Subject: [neutron-mc] McStas survey - results Message-ID: Hello everyone! As you may have noticed, the McStas users survey ended on September 23rd. I have now put together a summary web page on the survey results, which can be found at http://mcstas.risoe.dk/survey The results are very much in line with what has been decided for the TODO list for next release of McStas, which is very satisfying. Thanks for helping us out, Peter Willendrup -- ------------------------------------- Peter Kjaer Willendrup, Cand. Scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- From M.J.Gutmann at rl.ac.uk Tue Oct 1 16:27:20 2002 From: M.J.Gutmann at rl.ac.uk (Gutmann, MJ (Matthias) ) Date: Tue, 01 Oct 2002 15:27:20 +0100 Subject: [neutron-mc] Bragg's law for single crystals Message-ID: <37CAC51AC5C1D211966100A0C9ED000A02AEEAA2@exchange07.rl.ac.uk> Hi, when using a single crystal sample, it seems that Bragg's law has been incorporated as lambda = 2 * d * sin(2*theta) instead of lambda = 2 * d * sin(theta) Maybe worth checking whether this is the case. Matthias From farhi at ill.fr Tue Oct 1 16:57:39 2002 From: farhi at ill.fr (Emmanuel Farhi) Date: Tue, 01 Oct 2002 16:57:39 +0200 Subject: [neutron-mc] Bragg's law for single crystals References: <37CAC51AC5C1D211966100A0C9ED000A02AEEAA2@exchange07.rl.ac.uk> Message-ID: <3D99B7E3.61B0D65E@ill.fr> I'll have a look at that as soon as I can (probably next week) Thanks for reporting ! What can easely be done is to check also the Filter_Powder component, that was designed as a filter but acts as a general powder sample that scatters everywhere. Then (using for instance the sample files *.dat given in the version 1.6-ill) you can check the existence of powder lines at expected angles. That would also be a good opportunity to look at the intensity scattered by this compoennt. If you have some diffractometer data for simple powders (the best would be to have one of these *.dat files), could you compare the intensity of the simulated lines vs the measured one ? Any volunteer ? Emmanuel. "Gutmann, MJ (Matthias)" wrote: > Hi, > > when using a single crystal sample, it seems that Bragg's law has > been incorporated > as > > lambda = 2 * d * sin(2*theta) > > instead of > > lambda = 2 * d * sin(theta) > > Maybe worth checking whether this is the case. > > Matthias > > _______________________________________________ > neutron-mc mailing list > neutron-mc at neutron.risoe.dk > http://neutron.risoe.dk/mailman/listinfo/neutron-mc -- What's up Doc ? -------------------------------------------- Emmanuel FARHI, http://www.ill.fr/tas/people/Farhi.html \|/ ____ \|/ CS-Group ILL4/156, 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 35. Fax (33/0) 4 76 20 76 48 \__U_/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.J.Gutmann at rl.ac.uk Tue Oct 1 16:53:46 2002 From: M.J.Gutmann at rl.ac.uk (Gutmann, MJ (Matthias) ) Date: Tue, 01 Oct 2002 15:53:46 +0100 Subject: [neutron-mc] No peak Message-ID: <37CAC51AC5C1D211966100A0C9ED000A02AEEAA3@exchange07.rl.ac.uk> Hi, I am trying to simulate a TOF Laue single-crystal diffractometer. There is a peak showing up for a 4Pi Laue monitor when using a single-crystal sample. However, placing a TOF monitor at that position not a single neutron seems to arrive there. The peak should show up at approximately 80000 usecs. What am doing wrong? Attached are the input files used in the simulations. I am using McSTAS 1.6-ILL on Linux i386. Many thanks in advance, Matthias <> <> -------------- next part -------------- A non-text attachment was scrubbed... Name: hrsxdringrot.instr Type: application/octet-stream Size: 6092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: YBaCuO4.dat Type: application/octet-stream Size: 35 bytes Desc: not available URL: From farhi at ill.fr Tue Oct 1 17:28:15 2002 From: farhi at ill.fr (Emmanuel Farhi) Date: Tue, 01 Oct 2002 17:28:15 +0200 Subject: [neutron-mc] No peak References: <37CAC51AC5C1D211966100A0C9ED000A02AEEAA3@exchange07.rl.ac.uk> Message-ID: <3D99BF0F.D29DE88F@ill.fr> I think your tof monitor is not placed/oriented as it should. Put an Arm at the same place as the sample, rotated by GamD, and then place your monitor at the required distance on Z axis. I'm afraid your neutrons just do not go presently on the Tof monitor. Emmanuel. "Gutmann, MJ (Matthias)" wrote: > Hi, > > I am trying to simulate a TOF Laue single-crystal diffractometer. > There is > a peak showing up for a 4Pi Laue monitor when using a single-crystal sample. > However, > placing a TOF monitor at that position not a single neutron seems to arrive > there. > > The peak should show up at approximately 80000 usecs. > > What am doing wrong? Attached are the input files used in the simulations. > I am using McSTAS 1.6-ILL on Linux i386. > > Many thanks in advance, > > Matthias > > <> <> > > ------------------------------------------------------------------------ > Name: hrsxdringrot.instr > hrsxdringrot.instr Type: unspecified type (application/octet-stream) > Encoding: QUOTED-PRINTABLE > > Name: YBaCuO4.dat > YBaCuO4.dat Type: unspecified type (application/octet-stream) > Encoding: BASE64 -- What's up Doc ? -------------------------------------------- Emmanuel FARHI, http://www.ill.fr/tas/people/Farhi.html \|/ ____ \|/ CS-Group ILL4/156, 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 35. Fax (33/0) 4 76 20 76 48 \__U_/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.J.Gutmann at rl.ac.uk Tue Oct 1 17:51:01 2002 From: M.J.Gutmann at rl.ac.uk (Gutmann, MJ (Matthias) ) Date: Tue, 01 Oct 2002 16:51:01 +0100 Subject: [neutron-mc] No peak Message-ID: <37CAC51AC5C1D211966100A0C9ED000A02AEEAA5@exchange07.rl.ac.uk> Emmanuel, that worked! Many thanks, Matthias -----Original Message----- From: Emmanuel Farhi [mailto:farhi at ill.fr] Sent: Tuesday, October 01, 2002 4:28 PM To: neutron-mc at risoe.dk Subject: Re: [neutron-mc] No peak I think your tof monitor is not placed/oriented as it should. Put an Arm at the same place as the sample, rotated by GamD, and then place your monitor at the required distance on Z axis. I'm afraid your neutrons just do not go presently on the Tof monitor. Emmanuel. "Gutmann, MJ (Matthias)" wrote: Hi, I am trying to simulate a TOF Laue single-crystal diffractometer. There is a peak showing up for a 4Pi Laue monitor when using a single-crystal sample. However, placing a TOF monitor at that position not a single neutron seems to arrive there. The peak should show up at approximately 80000 usecs. What am doing wrong? Attached are the input files used in the simulations. I am using McSTAS 1.6-ILL on Linux i386. Many thanks in advance, Matthias <> <> ------------------------------------------------------------------------ Name: hrsxdringrot.instr hrsxdringrot.instr Type: unspecified type (application/octet-stream) Encoding: QUOTED-PRINTABLE Name: YBaCuO4.dat YBaCuO4.dat Type: unspecified type (application/octet-stream) Encoding: BASE64 -- What's up Doc ? -------------------------------------------- Emmanuel FARHI, http://www.ill.fr/tas/people/Farhi.html \|/ ____ \|/ CS-Group ILL4/156, 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 35. Fax (33/0) 4 76 20 76 48 \__U_/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.J.Gutmann at rl.ac.uk Wed Oct 2 09:53:17 2002 From: M.J.Gutmann at rl.ac.uk (Gutmann, MJ (Matthias) ) Date: Wed, 02 Oct 2002 08:53:17 +0100 Subject: [neutron-mc] Problems with single crystal Message-ID: <37CAC51AC5C1D211966100A0C9ED000A02AEEAA9@exchange07.rl.ac.uk> Hi, some more questions about the single crystal component: 1) I understand that the ax, ay, az, bx, by, bz, cx, cy, cz components describe the orientation of the crystal axes with respect to the local coordinate system in real space. Using the YBa2Cu3O7 sample from the Laue tutorial with ax = 3.8186, ay = 0, az = 0, bx = 0, by = 3.8843, bz = 0, cx = 0, cy = 0, cz = 11.6777 how come that the 002 reflection can be seen at -90 degrees in the PSD_monitor_4PI_log component? This should not be possible. How should this be interpreted? 2) Placing a TOF_monitor at that position gives now neutrons thanks to your advice. However, nothing that looks like a peak. It would be really nice to use the single crystal as a sample to simulate various aspects of a TOF Laue single crystal diffractometer. Best wishes, Matthias From M.J.Gutmann at rl.ac.uk Wed Oct 2 16:25:44 2002 From: M.J.Gutmann at rl.ac.uk (Gutmann, MJ (Matthias) ) Date: Wed, 02 Oct 2002 15:25:44 +0100 Subject: [neutron-mc] No peak Message-ID: <37CAC51AC5C1D211966100A0C9ED000A02AEEAB0@exchange07.rl.ac.uk> Hi, following the previous messages about problems with a single crystal sample, it seems that everything is working fine now. Apparently, seeing a peak in the TOF monitor corresponds to seeing that peak in the center of the 4PI monitor. So, to summarize, I think everything is fine with the single crystal sample in McSTAS - just a bit confusing in the beginning. Matthias -----Original Message----- From: Emmanuel Farhi [mailto:farhi at ill.fr] Sent: Tuesday, October 01, 2002 4:28 PM To: neutron-mc at risoe.dk Subject: Re: [neutron-mc] No peak I think your tof monitor is not placed/oriented as it should. Put an Arm at the same place as the sample, rotated by GamD, and then place your monitor at the required distance on Z axis. I'm afraid your neutrons just do not go presently on the Tof monitor. Emmanuel. "Gutmann, MJ (Matthias)" wrote: Hi, I am trying to simulate a TOF Laue single-crystal diffractometer. There is a peak showing up for a 4Pi Laue monitor when using a single-crystal sample. However, placing a TOF monitor at that position not a single neutron seems to arrive there. The peak should show up at approximately 80000 usecs. What am doing wrong? Attached are the input files used in the simulations. I am using McSTAS 1.6-ILL on Linux i386. Many thanks in advance, Matthias <> <> ------------------------------------------------------------------------ Name: hrsxdringrot.instr hrsxdringrot.instr Type: unspecified type (application/octet-stream) Encoding: QUOTED-PRINTABLE Name: YBaCuO4.dat YBaCuO4.dat Type: unspecified type (application/octet-stream) Encoding: BASE64 -- What's up Doc ? -------------------------------------------- Emmanuel FARHI, http://www.ill.fr/tas/people/Farhi.html \|/ ____ \|/ CS-Group ILL4/156, 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 35. Fax (33/0) 4 76 20 76 48 \__U_/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.willendrup at risoe.dk Thu Oct 10 14:27:22 2002 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Thu, 10 Oct 2002 14:27:22 +0200 (CEST) Subject: [neutron-mc] Various news + a question Message-ID: Hello everyone! I have just updated the McStas website slightly, a few more indicators in http://mcstas.risoe.dk/developments/status are now green, indicating that the next release is a little closer. Emmanuel Farhi, Kim Lefmann and I attended a meeting in the SCANS network last friday, the slides of the talk given by Emmanuel and I is available from http://mcstas.risoe.dk/workshop Last, but not least, one of the people who (anonymously) completed the McStas survey gave the following information in a comment field: "I've upgraded Debian since, and the only part of mcstas that stopped working was mcdisplay. I now have a versitile matlab set of routines that makes mcdisplay unneeded." I would very much like to make contact with this user. The reason for this is that we are about to rewrite the GUI/plotting facilities for McStas in a matlab-like environment. Possibly some of the user's code could be reused in this process. Regards, Peter Willendrup -- ------------------------------------- Peter Kjaer Willendrup, Cand. Scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- From peter.willendrup at risoe.dk Thu Oct 17 23:39:04 2002 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Thu, 17 Oct 2002 23:39:04 +0200 (CEST) Subject: [neutron-mc] mcplot problems solved? Message-ID: Hello everyone! I the resent past, several users have reported problems running mcplot on newer setups of perl etc. I am very happy to announce that I have probably found a cure for these problems. It seems that PDL versions >= 2.1 have a slightly changed, syntax so that the functions pgopen() and pgclos() (for opening and closing of PGPLOT windows) have been replaced by modernized versions, called dev() and close_window(). I have verified that given this slight change to mcplotlib.pl, mcplot now functions properly on the platforms Debian GNU/Linux 3.0 (woody) RedHat 7.1 (seawolf) Cygwin/XFree86 (1.3.13-2), tested on windows 2000. I have attached modified versions of mcplotlib.pl for mcstas-1.5 and mcstas-1.6.1-ill. I would very much like users to report back to neutron-mc, if they are successful / unsuccessful in using this patch. Note: If mcplot works properly on your current setup, you should not replace your current mcplotlib.pl Hope this helps, Peter Willendrup -- ------------------------------------- Peter Kjaer Willendrup, Cand. Scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- -------------- next part -------------- use PDL; use PDL::Graphics::PGPLOT; use PGPLOT; require "mcfrontlib.pl"; sub plot_array_2d { my ($info,$m,$n) = @_; my $data = get_detector_data_2D($info); my ($x0,$x1,$y0,$y1) = @{$info->{'Limits'}}; my ($dx,$dy) = (($x1 - $x0)/$m, ($y1 - $y0)/$n); my $tr = pdl [ $x0 + $dx/2, $dx, 0, $y0 + $dy/2, 0, $dy ]; my ($min, $max) = (min($data), max($data)); if ($min == $max) { if($min == 0) { $max = 1; } else { $min = 0.9*$min; $max = 0.9*$max; } } my $numcol = 64; my $ramp = pdl [[ 0, 1/8, 3/8, 5/8, 7/8, 8/8], [ 0, 0, 0, 1, 1, .5], [ 0, 0, 1, 1, 0, 0], [.5, 1, 1, 0, 0, 0]]; pgpage; pgbbuf; pgsci(1); hold; pgvstd; pgswin @{$info->{'Limits'}}; pgbox("BCNSTI", 0.0, 0.0, "BCNSTI", 0.0, 0.0); pgscir(16,16+$numcol-1); ctab $ramp; # If using the black&white postscript driver, swap foreground and # background when doing the image to get more printer-friendly # output. my ($buf, $len); my ($r0, $g0, $b0, $r1, $g1, $b1); pgqinf("TYPE", $buf, $len); if($buf =~ /^V?PS$/i) { pgqcr(0, $r0, $g0, $b0); pgqcr(1, $r1, $g1, $b1); pgscr(0, $r1, $g1, $b1); pgscr(1, $r0, $g0, $b0); } imag $data, $min, $max, $tr; pgwedg("RI", 0.5, 3.0, $min, $max, ' '); if($buf =~ /^V?PS$/i) { pgscr(0, $r0, $g0, $b0); pgscr(1, $r1, $g1, $b1); } pglab($info->{'Xlabel'}, $info->{'Ylabel'}, ""); pgmtxt("T", 2.5, 0.5, 0.5, "$info->{'Title'} $info->{'Component'}"); pgmtxt("T", 1.0, 0.5, 0.5, "[$info->{'Filename'}]"); pgebuf; release; } sub plot_array_1d { my ($info,$npt) = @_; my $r = get_detector_data_1D($info); my $x = $r->{$info->{'Xvar'}[0]}; my $I = $r->{$info->{'Yvar'}[0]}; my ($x0,$x1) = @{$info->{'Limits'}}; my ($min, $max, $err); if($info->{'Yerr'} && $info->{'Yerr'}[0]) { $err = $r->{$info->{'Yerr'}[0]}; ($min, $max) = (min($I - 2*$err), max($I + 2*$err)); } else { ($min, $max) = (min($I), max($I)); } if($min == $max) { if($min == 0) { ($min, $max) = (0, 1); } else { ($min, $max) = (0, $max); } } # Include zero point of Y axis if minimum is close to zero. $min = 0 if($min > 0 && $min/$max < 0.2); pgpage; pgbbuf; hold; pgvstd; pgswin($x0,$x1,$min,$max); line($x, $I); errb($x, $I, $err) if defined($err); pgbox("BCNST", 0.0, 0.0, "BCNST", 0.0, 0.0); pglab($info->{'Xlabel'}, $info->{'Ylabel'}, ""); pgmtxt("T", 2.5, 0.5, 0.5, "$info->{'Title'} $info->{'Component'}"); pgmtxt("T", 1.0, 0.5, 0.5, "[$info->{'Filename'}]"); pgebuf; release; } # This function computes a 'good' panel size (X x Y) to fit a given # number of plots. sub calc_panel_size { my ($num) = @_; my @panels = ( [1,1], [2,1], [2,2], [3,2], [3,3], [4,3], [5,3], [4,4], [5,4], [6,4], [5,5], [6,5], [7,5], [6,6], [8,5], [7,6], [9,5], [8,6], [7,7], [9,6], [8,7], [9,7], [8,8], [10,7], [9,8], [11,7], [9,9], [11,8], [10,9], [12,8], [11,9], [10,10] ); my ($nx,$ny, $fit); # Default size about sqrt($num) x sqrt($num). $ny = int(sqrt($num)); $nx = int($num/$ny); $nx++ if $nx*$ny < $num; $fit = $nx*$ny - $num; for $panel (@panels) { my $d = $panel->[0]*$panel->[1] - $num; ($fit,$nx,$ny) = ($d, $panel->[0], $panel->[1]) if($d >=0 && $d <= $fit); } return ($nx,$ny); } sub plot_dat_info { my ($info) = @_; my $type = $info->{'Type'}; if($type =~ /^\s*array_2d\s*\(\s*([0-9]+)\s*,\s*([0-9]+)\s*\)\s*$/i) { plot_array_2d($info, $1, $2); }elsif($type =~ /^\s*array_1d\s*\(\s*([0-9]+)\s*\)\s*$/i) { plot_array_1d($info, $1); } else { die "Unimplemented plot type '$type'"; } } sub overview_plot { my ($devspec, $datalist, $interactive) = @_; return unless @$datalist; my ($nx, $ny) = calc_panel_size(int(@$datalist)); my $dev = dev("$devspec"); die "DEV failed!" unless $dev > 0; pgsubp ($nx,$ny); my $info; for $info (@$datalist) { plot_dat_info($info); } if($interactive) { # Wait for user to select a plot. pgpanl(1,1); pgsvp(0,1,0,1); pgswin(0,1,1,0); my ($ax,$ay,$cx,$cy,$cc) = (0,0,0,0,""); pgband(0, 0, $ax, $ay, $cx, $cy, $cc); my ($i, $j) = (int($cx), int($cy)); $i = 0 if $i < 0; $j = 0 if $j < 0; $i = $nx - 1 if $i >= $nx; $j = $ny - 1 if $j >= $ny; my $idx = $i + $nx*$j; $idx = int(@$datalist) - 1 if $idx >= int(@$datalist); close_window; return ($cc,$idx); } else { close_window; return (); } } sub single_plot { my ($devspec, $info, $interactive) = @_; my $dev = dev("$devspec"); die "DEV failed!" unless $dev > 0; plot_dat_info($info); if($interactive) { # Wait for user to press a key. my ($ax,$ay,$cx,$cy,$cc) = (0,0,0,0,""); pgband(0, 0, $ax, $ay, $cx, $cy, $cc); close_window; return ($cc, $cx, $cy); } else { close_window; return (); } } # Make sure that the PGPLOT X11 window server is started, by opening # and immediately closing a window. sub ensure_pgplot_xserv_started { my $olddev; pgqid($olddev); my $newdev = dev("/xserv"); close_window(); pgslct($olddev); } 1; -------------- next part -------------- use PDL; use PDL::Graphics::PGPLOT; use PGPLOT; require "mcfrontlib.pl"; sub plot_array_2d { my ($info,$m,$n) = @_; my $data = get_detector_data_2D($info); my ($x0,$x1,$y0,$y1) = @{$info->{'Limits'}}; my ($dx,$dy) = (($x1 - $x0)/$m, ($y1 - $y0)/$n); my $tr = pdl [ $x0 + $dx/2, $dx, 0, $y0 + $dy/2, 0, $dy ]; my ($min, $max) = (min($data), max($data)); if ($min == $max) { if($min == 0) { $max = 1; } else { $min = 0.9*$min; $max = 0.9*$max; } } my $numcol = 64; my $ramp = pdl [[ 0, 1/8, 3/8, 5/8, 7/8, 8/8], [ 0, 0, 0, 1, 1, .5], [ 0, 0, 1, 1, 0, 0], [.5, 1, 1, 0, 0, 0]]; pgpage; pgbbuf; pgsci(1); hold; pgvstd; pgswin @{$info->{'Limits'}}; pgbox("BCNSTI", 0.0, 0.0, "BCNSTI", 0.0, 0.0); pgscir(16,16+$numcol-1); ctab $ramp; # If using the black&white postscript driver, swap foreground and # background when doing the image to get more printer-friendly # output. my ($buf, $len); my ($r0, $g0, $b0, $r1, $g1, $b1); pgqinf("TYPE", $buf, $len); if($buf =~ /^V?PS$/i) { pgqcr(0, $r0, $g0, $b0); pgqcr(1, $r1, $g1, $b1); pgscr(0, $r1, $g1, $b1); pgscr(1, $r0, $g0, $b0); } imag $data, $min, $max, $tr; pgwedg("RI", 0.5, 3.0, $min, $max, ' '); if($buf =~ /^V?PS$/i) { pgscr(0, $r0, $g0, $b0); pgscr(1, $r1, $g1, $b1); } pglab("$info->{'Xlabel'} $info->{'Stats'}", $info->{'Ylabel'}, ""); pgmtxt("T", 2.5, 0.5, 0.5, "$info->{'Title'} $info->{'Component'}"); pgmtxt("T", 1.0, 0.5, 0.5, "[$info->{'Filename'}] "); pgebuf; release; } sub plot_array_1d { my ($info,$npt) = @_; my $r = get_detector_data_1D($info); my $x = $r->{$info->{'Xvar'}[0]}; my $I = $r->{$info->{'Yvar'}[0]}; my ($x0,$x1) = @{$info->{'Limits'}}; my ($min, $max, $err); if($info->{'Yerr'} && $info->{'Yerr'}[0]) { $err = $r->{$info->{'Yerr'}[0]}; ($min, $max) = (min($I - 2*$err), max($I + 2*$err)); } else { ($min, $max) = (min($I), max($I)); } if($min == $max) { if($min == 0) { ($min, $max) = (0, 1); } else { ($min, $max) = (0, $max); } } # Include zero point of Y axis if minimum is close to zero. $min = 0 if($min > 0 && $min/$max < 0.2); pgpage; pgbbuf; hold; pgvstd; pgswin($x0,$x1,$min,$max); line($x, $I); errb($x, $I, $err) if defined($err); pgbox("BCNST", 0.0, 0.0, "BCNST", 0.0, 0.0); pglab($info->{'Xlabel'}, $info->{'Ylabel'}, ""); pgmtxt("T", 2.5, 0.5, 0.5, "$info->{'Title'} $info->{'Component'}"); pgmtxt("T", 1, 0.5, 0.5, "[$info->{'Filename'}] $info->{'Stats'}"); pgebuf; release; } # This function computes a 'good' panel size (X x Y) to fit a given # number of plots. sub calc_panel_size { my ($num) = @_; my @panels = ( [1,1], [2,1], [2,2], [3,2], [3,3], [4,3], [5,3], [4,4], [5,4], [6,4], [5,5], [6,5], [7,5], [6,6], [8,5], [7,6], [9,5], [8,6], [7,7], [9,6], [8,7], [9,7], [8,8], [10,7], [9,8], [11,7], [9,9], [11,8], [10,9], [12,8], [11,9], [10,10] ); my ($nx,$ny, $fit); # Default size about sqrt($num) x sqrt($num). $ny = int(sqrt($num)); $nx = int($num/$ny); $nx++ if $nx*$ny < $num; $fit = $nx*$ny - $num; for $panel (@panels) { my $d = $panel->[0]*$panel->[1] - $num; ($fit,$nx,$ny) = ($d, $panel->[0], $panel->[1]) if($d >=0 && $d <= $fit); } return ($nx,$ny); } sub plot_dat_info { my ($info) = @_; my $type = $info->{'Type'}; if($type =~ /^\s*array_2d\s*\(\s*([0-9]+)\s*,\s*([0-9]+)\s*\)\s*$/i) { plot_array_2d($info, $1, $2); }elsif($type =~ /^\s*array_1d\s*\(\s*([0-9]+)\s*\)\s*$/i) { plot_array_1d($info, $1); } else { die "Unimplemented plot type '$type'"; } } sub overview_plot { my ($devspec, $datalist, $interactive) = @_; return unless @$datalist; my ($nx, $ny) = calc_panel_size(int(@$datalist)); my $dev = dev("$devspec"); die "DEV failed!" unless $dev > 0; pgsubp ($nx,$ny); my $info; for $info (@$datalist) { plot_dat_info($info); } if($interactive) { # Wait for user to select a plot. pgpanl(1,1); pgsvp(0,1,0,1); pgswin(0,1,1,0); my ($ax,$ay,$cx,$cy,$cc) = (0,0,0,0,""); pgband(0, 0, $ax, $ay, $cx, $cy, $cc); my ($i, $j) = (int($cx), int($cy)); $i = 0 if $i < 0; $j = 0 if $j < 0; $i = $nx - 1 if $i >= $nx; $j = $ny - 1 if $j >= $ny; my $idx = $i + $nx*$j; $idx = int(@$datalist) - 1 if $idx >= int(@$datalist); close_window; return ($cc,$idx); } else { close_window; return (); } } sub single_plot { my ($devspec, $info, $interactive) = @_; my $dev = dev("$devspec"); die "DEV failed!" unless $dev > 0; plot_dat_info($info); if($interactive) { # Wait for user to press a key. my ($ax,$ay,$cx,$cy,$cc) = (0,0,0,0,""); pgband(0, 0, $ax, $ay, $cx, $cy, $cc); close_window; return ($cc, $cx, $cy); } else { close_window; return (); } } # Make sure that the PGPLOT X11 window server is started, by opening # and immediately closing a window. sub ensure_pgplot_xserv_started { my $olddev; pgqid($olddev); my $newdev = dev("/xserv"); close_window(); pgslct($olddev); } 1; From tillier at ill.fr Thu Nov 14 14:19:21 2002 From: tillier at ill.fr (Odile Tillier) Date: Thu, 14 Nov 2002 14:19:21 +0100 Subject: [neutron-mc] McStas not working on SuSE linux 8.0 Message-ID: <3DD3A2D9.3030607@ill.fr> It's seems McStas is not released for SUSE Linux 8.0 Error when running mcplot: mcplot Can't load '/usr/lib/perl5/site_perl/5.6.1/i586-linux/auto/PGPLOT/PGPLOT.so' for module PGPLOT: /usr/lib/perl5/site_perl/5.6.1/i586-linux/auto/PGPLOT/PGPLOT.so: undefined symbol: cpgdraw at /usr/lib/perl5/5.6.1/i586-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i586-linux/PDL/Graphics/PGPLOT/Window.pm line 1677 Compilation failed in require at /usr/lib/perl5/site_perl/5.6.1/i586-linux/PDL/Graphics/PGPLOT/Window.pm line 1677. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/i586-linux/PDL/Graphics/PGPLOT/Window.pm line 1677. Compilation failed in require at /usr/lib/perl5/site_perl/5.6.1/i586-linux/PDL/Graphics/PGPLOT.pm line 145. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/i586-linux/PDL/Graphics/PGPLOT.pm line 145. Compilation failed in require at /usr/local/bin/mcplot line 5. BEGIN failed--compilation aborted at /usr/local/bin/mcplot line 5. Therefore all required package are installed: bison flex all Perl module on SuSE CD , pgplot 5.2, Perl-PGPLOT PDL PerlTk See rpm commands following . Any idea ??? toflin:/usr/local/src # rpm -qa|grep bison bison-1.33-31 toflin:/usr/local/src # rpm -qa|grep flex flex-2.5.4-524 toflin:/usr/local/src # rpm -qa|grep perl perl-5.6.1-159 perl-Digest-MD5-2.16-51 perl-HTML-Parser-3.25-126 perl-HTML-Tagset-3.03-194 perl-MIME-Base64-2.12-194 perl-Storable-1.0.13-88 perl-Tk-800.023-162 perl-URI-1.18-55 perl-gettext-1.01-219 perl-libnet-1.0901-50 perl-libwww-perl-5.63-54 eperl-2.2.14-408 perlref-5.004.1-107 mod_perl-1.26-269 perl-Parse-RecDescent-1.78-222 perl-Apache-ASP-2.29-142 perl-Apache-Filter-1.019-132 perl-Apache-SSI-2.17-86 perl-Archive-Tar-0.22-124 perl-Archive-Zip-0.11-188 perl-Bit-Vector-6.1-46 perl-Carp-Assert-0.17-58 perl-Class-Accessor-0.17-41 perl-Compress-Zlib-1.16-50 perl-DBI-1.20-47 perl-Data-ShowTable-3.3-224 perl-Date-Calc-5.0-47 perl-DateManip-5.40-141 perl-Devel-Symdump-2.01-216 perl-Digest-1.00-132 perl-Digest-HMAC-1.01-135 perl-Digest-SHA1-2.01-52 perl-Expect-1.12-86 perl-ExtUtils-F77-1.14-53 perl-Gtk-Perl-0.7008-273 perl-HTML-Clean-0.8-286 perl-HTML-FillInForm-0.23-50 perl-HTML-SimpleParse-0.10-217 perl-IO-Stty-.02-207 perl-IO-Tty-0.05-83 perl-IO-stringy-2.108-51 perl-Inline-0.43-138 perl-Log-Dispatch-1.80-89 perl-MIME-tools-5.411a-56 perl-MLDBM-2.00-218 perl-MLDBM-Sync-0.25-63 perl-MailTools-1.42-54 perl-Net-Telnet-3.02-126 perl-PDL-2.3.2-102 perl-Tie-Cache-0.15-188 perl-Tie-IxHash-1.21-224 perl-Time-HiRes-01.20-180 perl-XML-DOM-1.36-53 perl-XML-Parser-2.30-132 perl-XML-RegExp-0.03-126 perl-XML-XSLT-0.32-207 perl-GnuPG-0.07-217 perl-PGPLOT-2.18-2 toflin:/usr/local/src # rpm -qa|grep pgplot pgplot-5.2.0-2 toflin:/usr/local/src # rpm -qa|grep PDL perl-PDL-2.3.2-102 toflin:/usr/local/src # rpm -qa|grep Tk perl-Tk-800.023-162 -- --------------------------------------------------------------------------- _/ _/ _/ O.Tillier _/ _/ _/ Institut Laue Langevin _/ _/ _/ Service Informatique _/ _/_/_/ _/_/_/ B.P. 156 F-38042 Grenoble Cedex 9, France Email: tillier at ill.fr Tel: (33) 4 76.20.73.89; Fax: (33) 4 76.48.39.06; From peter.willendrup at risoe.dk Thu Nov 14 14:59:02 2002 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Thu, 14 Nov 2002 14:59:02 +0100 (CET) Subject: [neutron-mc] McStas not working on SuSE linux 8.0 In-Reply-To: <3DD3A2D9.3030607@ill.fr> Message-ID: Hi Odile, On Thu, 14 Nov 2002, Odile Tillier wrote: > mcplot > Can't load > '/usr/lib/perl5/site_perl/5.6.1/i586-linux/auto/PGPLOT/PGPLOT.so' for > module PGPLOT: > /usr/lib/perl5/site_perl/5.6.1/i586-linux/auto/PGPLOT/PGPLOT.so: > undefined symbol: cpgdraw at > /usr/lib/perl5/5.6.1/i586-linux/DynaLoader.pm line 206. It seems to me that your installed pgplot package _may_ not include the c library interface, as explained in Emmanuel's FAQ at http://www.ill.fr/tas/mcstas/FAQ.html (at "Something seems to be missing in my pgplot. What's wrong with it ?") This will likely require you to recompile pgplot and perl-PGPLOT packages. > Therefore all required package are installed: bison flex > all Perl module on SuSE CD , pgplot 5.2, Perl-PGPLOT PDL PerlTk > See rpm commands following . You are right, it seems that all needed packages are there. Try removing the pgplot and perl-PGPLOT packages and recompile from sources. Let us know if you have success or not. Do not hesitate to contact me for further help in this process. Regards, Peter Willendrup -- ------------------------------------- Peter Kjaer Willendrup, Cand. Scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- From frick at onyx.ill.fr Mon Nov 18 13:15:13 2002 From: frick at onyx.ill.fr (Bernhard Frick) Date: Mon, 18 Nov 2002 13:15:13 +0100 (added by postmaster@wanadoo.fr) Subject: [neutron-mc] depannage manip - a typical case Message-ID: <3DD3B25600210E33@mel-rta7.wanadoo.fr> 8/3/99 Bernhard Frick -> Jose Dianoux cc: T. Heidemann, A. Leadbetter, P. Leconte In the following I will shortly summarize a loss of 16 hours experimental time with a dilution fridge on IN16 which happend yesterday , April.7th,1999. In my opinion it is a typical case, which shows, that the solutions for instrument break-downs out of working hours as proposed in the DS/DPT meeting - at which I have assisted by chance - do not work. ( as well for security questions). Monday: about 17:15 Chopper 1 on IN16 is stopped as usual I try to restart, but becomes soon clear that this does not work about 17:30 I phone F. Descamps ( as was told in the meeting: phone the chefs)- the secretary tells me he is on travel phone C. Gomez (mechanique chopper)- but he is no longer at ILL; same for J.J.Vernier (responsable REFU) and T. Mary I call the instrument technician O. Losserand who is still here and we try to find out why the REFU does not want to reset we check all securities, cables etc some time later: phone at ILL the chef in the hierarchy above (T. Heidemann; sorry Tony, only to annoy you) get some private phone number from the reactor ( one of the numbers turns out to be a hotel phone) try to contact P. Thomas at home( on travel as well), The dilution fridge is at 200mK and we want really not loose all night of such an expensive experiment. we open the REFU - note that we pass the limits of what we are allowed to do from security reasons The secretary of the electronics group finds one person from electronics. He passes but he is no expert in REFU and Choppers We decide to check two fuses on the low tension part of the REFU - note severe security problem !! we change a broken fuse but it breaks immediately again At this point we decide that we have to wait for the next day. We try to run the experiment without background chopper, but the data are very bad. Thus we lost 16 hours of beam time - or about 40 - 50kF. How expensive would be an 'astreinte' ? The first thing on next morning was of course that we were critisised by one of the experts, that we should not open the REFU. With some right he asks the question what would happen if somebody had an accident during this intervention. The REFU problem was solved on next morning within an hour. Bernhard Frick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SRDsept02.doc.scr URL: From jurg.schefer at psi.ch Tue Nov 19 07:45:33 2002 From: jurg.schefer at psi.ch (Jurg Schefer, ETHZ&PSI) Date: Tue, 19 Nov 2002 07:45:33 +0100 Subject: [neutron-mc] depannage manip - a typical case In-Reply-To: <3DD3B25600210E33@mel-rta7.wanadoo.fr> Message-ID: To whom I may concern: Please delete me from your private mailing list. Juerg Juerg Schefer Laboratory for Neutron Scattering ETHZ&PSI WHGA-146 CH-5233 Villigen PSI, Switzerland +41.79.692.5617 office/mobile (1st) +41.56.310.4347 office/fixnet +41.56.310.2939 FAX Jurg.Schefer at psi.ch http://num.web.psi.ch -----Original Message----- From: neutron-mc-admin at risoe.dk [mailto:neutron-mc-admin at risoe.dk]On Behalf Of Bernhard Frick Sent: Montag, 18. November 2002 13:15 To: kristian.nielsen at risoe.dk; neutron-mc at risoe.dk Subject: [neutron-mc] depannage manip - a typical case 8/3/99 Bernhard Frick -> Jose Dianoux cc: T. Heidemann, A. Leadbetter, P. Leconte In the following I will shortly summarize a loss of 16 hours experimental time with a dilution fridge on IN16 which happend yesterday , April.7th,1999. In my opinion it is a typical case, which shows, that the solutions for instrument break-downs out of working hours as proposed in the DS/DPT meeting - at which I have assisted by chance - do not work. ( as well for security questions). Monday: about 17:15 Chopper 1 on IN16 is stopped as usual I try to restart, but becomes soon clear that this does not work about 17:30 I phone F. Descamps ( as was told in the meeting: phone the chefs)- the secretary tells me he is on travel phone C. Gomez (mechanique chopper)- but he is no longer at ILL; same for J.J.Vernier (responsable REFU) and T. Mary I call the instrument technician O. Losserand who is still here and we try to find out why the REFU does not want to reset we check all securities, cables etc some time later: phone at ILL the chef in the hierarchy above (T. Heidemann; sorry Tony, only to annoy you) get some private phone number from the reactor ( one of the numbers turns out to be a hotel phone) try to contact P. Thomas at home( on travel as well), The dilution fridge is at 200mK and we want really not loose all night of such an expensive experiment. we open the REFU - note that we pass the limits of what we are allowed to do from security reasons The secretary of the electronics group finds one person from electronics. He passes but he is no expert in REFU and Choppers We decide to check two fuses on the low tension part of the REFU - note severe security problem !! we change a broken fuse but it breaks immediately again At this point we decide that we have to wait for the next day. We try to run the experiment without background chopper, but the data are very bad. Thus we lost 16 hours of beam time - or about 40 - 50kF. How expensive would be an 'astreinte' ? The first thing on next morning was of course that we were critisised by one of the experts, that we should not open the REFU. With some right he asks the question what would happen if somebody had an accident during this intervention. The REFU problem was solved on next morning within an hour. Bernhard Frick -------------- next part -------------- A non-text attachment was scrubbed... Name: Schefer-Jurg.vcf Type: text/x-vcard Size: 910 bytes Desc: not available URL: From peter.willendrup at risoe.dk Tue Nov 19 09:56:11 2002 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Tue, 19 Nov 2002 09:56:11 +0100 (CET) Subject: [neutron-mc] depannage manip - a typical case In-Reply-To: <3DD3B25600210E33@mel-rta7.wanadoo.fr> Message-ID: Hello everyone, The message below is a result of someones machine beeing infected with the so called BugBear A virus. Do not be alarmed, the message sent to you was disinfected in the RIS? mail system before beeing resent to you. The adress of the machine sending the infected message is 193.249.42.236 -> mix-grenoble-105-3-236.abo.wanadoo.fr I have recieved also another infected message from the same host. The machine in question may be owned by an ILL employee, since 1) Belonging to the Grenoble part of the wanadoo network 2) Having ILL / neutron related content in the sent mails Would someone at ILL please circulate this information? Regards, Peter Willendrup -- ------------------------------------- Peter Kjaer Willendrup, cand. scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- On Mon, 18 Nov 2002, Bernhard Frick wrote: > 8/3/99 > > Bernhard Frick -> Jose Dianoux > cc: T. Heidemann, A. Leadbetter, P. Leconte > > In the following I will shortly summarize a loss of 16 hours > experimental time with a dilution fridge on IN16 which happend yesterday > , April.7th,1999. > In my opinion it is a typical case, which shows, that the solutions for > instrument break-downs out of working hours as proposed in the DS/DPT > meeting - at which I have assisted by chance - do not work. ( as well > for security questions). > > Monday: about 17:15 Chopper 1 on IN16 is stopped > as usual I try to restart, but > becomes soon clear that this does not work > about 17:30 > I phone F. Descamps ( as was > told in the meeting: phone the chefs)- the secretary tells me he is on > travel > phone C. Gomez (mechanique > chopper)- but he is no longer at ILL; > same for J.J.Vernier > (responsable REFU) and T. Mary > I call the instrument technician > O. Losserand who is still here and we try to find out why the REFU > does not want to reset > we check all securities, cables > etc > some time later: > phone at ILL the chef in the > hierarchy above (T. Heidemann; sorry Tony, only to annoy you) > get some private phone number > from the reactor ( one of the numbers turns out to be a hotel phone) > try to contact P. Thomas at > home( on travel as well), > > The dilution fridge is at 200mK > and we want really not loose all night of such an expensive experiment. > > we open the REFU - note that we > pass the limits of what we are allowed to do from security reasons > The secretary of the electronics > group finds one person from electronics. > He passes but he is no expert in > REFU and Choppers > We decide to check two fuses on > the low tension part of the REFU - note severe security problem !! > we change a broken fuse but it > breaks immediately again > > At this point we decide that we have to wait for the next day. > > We try to run the experiment > without background chopper, but the data are very bad. > > Thus we lost 16 hours of beam time - or about 40 - 50kF. How expensive > would be an 'astreinte' ? > > The first thing on next morning was of course that we were critisised by > one of the experts, that we should not open the REFU. With some right he > asks the question what would happen if somebody had an accident during > this intervention. > > The REFU problem was solved on next morning within an hour. > > > Bernhard Frick > From peter.willendrup at risoe.dk Mon Dec 30 14:35:00 2002 From: peter.willendrup at risoe.dk (Peter Willendrup) Date: Mon, 30 Dec 2002 14:35:00 +0100 (CET) Subject: [neutron-mc] McStas status Message-ID: Hello everyone As some of you may have noticed, the developer team originally aimed at releasing a new McStas release before the end of 2002. To make the next McStas release a complete success, we have decided to postpone release until all the needed work has been done. This will most likely take a couple of months. Until then, you may have a sneak preview of one of the new features, that is 3D instrument rendering for mcdisplay. A set of gif images for you to look at have been attached to this message in a tar.gz archive. Happy New Year The McStas developer team Peter Willendrup Emmanuel Farhi Kim Lefmann -- ------------------------------------- Peter Kjaer Willendrup, cand. scient Phone: (+45) 46 77 58 62 email: peter.willendrup at risoe.dk ------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: pics_final.tar.gz Type: application/octet-stream Size: 321634 bytes Desc: URL: