From wildgrubercu at ornl.gov  Mon Apr 27 23:07:11 2020
From: wildgrubercu at ornl.gov (Wildgruber, Christoph U.)
Date: Mon, 27 Apr 2020 21:07:11 +0000
Subject: [mcstas-users] SANSCurve type component for I(qx,
	qy) instead of I(q)?
Message-ID: <0603F868-C6DE-4E73-8E0E-311D2B7C5F39@ornl.gov>

Hi all,


I might not be looking hard enough but I don?t think there is a SANS
sample component similar to SANSCurve (which uses I(q) as an input file)
that can handle I(qx, qy).

If anybody can point me in the right direction or has a component like that
to share it would be greatly appreciated! 

Thanks so much,

Uli


From pkwi at fysik.dtu.dk  Tue Apr 28 09:24:53 2020
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Tue, 28 Apr 2020 07:24:53 +0000
Subject: [mcstas-users] SANSCurve type component for I(qx,
 qy) instead of I(q)?
In-Reply-To: <0603F868-C6DE-4E73-8E0E-311D2B7C5F39@ornl.gov>
References: <0603F868-C6DE-4E73-8E0E-311D2B7C5F39@ornl.gov>
Message-ID: <B74F461B-9243-4106-992E-8FA318D0B0FE@fysik.dtu.dk>

Hi Uli,


On 27 Apr 2020, at 23.07, Wildgruber, Christoph U. <wildgrubercu at ornl.gov<mailto:wildgrubercu at ornl.gov>> wrote:

I might not be looking hard enough but I don?t think there is a SANS
sample component similar to SANSCurve (which uses I(q) as an input file)
that can handle I(qx, qy).

If anybody can point me in the right direction or has a component like that
to share it would be greatly appreciated!

For that sort of functionality I would be looking in the direction of the SASview (SASmodels really) sample http://www.mcstas.org/download/components/samples/SasView_model.html which does include models that are 2D in q. (It may also be that one of Henrich Frielinghaus? contributed sample components has a similar feature?)

The limitations of the SasView_model sample are that
a) I am not entirely sure the absolute normalisation is completely correct
b) One needs to recompile when shifting between models

Should you decide to implement one yourself instead, such a model would of course always be welcome as a contribution. ;-)


Best

Peter


Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics


[cid:b6339554-7f28-441d-9f31-5944f811397c at win.dtu.dk]


Technical University of Denmark


[cid:e108e480-fcab-46e2-9531-b38165079572 at win.dtu.dk]



Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/33e96c9b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 58 bytes
Desc: image001.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/33e96c9b/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1055 bytes
Desc: image002.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/33e96c9b/attachment-0003.gif>

From pkwi at fysik.dtu.dk  Tue Apr 28 10:43:15 2020
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Tue, 28 Apr 2020 08:43:15 +0000
Subject: [mcstas-users] McStas 2.6 on Ubuntu 20.04 (and 2.6.1 in the
	works...)
Message-ID: <0BB53A6F-BB0F-4B86-BC63-4DD93F8C5CC5@fysik.dtu.dk>

Dear all,


I have tried out the McStas 2.6 release on the fresh Ubuntu 20.04 release<https://releases.ubuntu.com/20.04/>, and my findings are these:

  *   Generally, the release works as expected - all of the python tools seem to function well.
  *   For the legacy perl tools we have the issue that the OS-provided PDL no longer comes with a PGPLOT plotting-bridge, which affects mcplot.pl and mcgui.pl:

mcstas at mcstas-virtual-machine:~$ mcgui.pl
Can't locate PDL/Graphics/PGPLOT.pm in @INC (you may need to install the PDL::Graphics::PGPLOT module)
(@INC contains: /usr/share/mcstas/2.6/tools/Perl/perl/modules /usr/share/mcstas/2.6/tools/Perl/perl /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/mcstas/2.6/tools/Perl/perl/mcplotlib.pl line 23,  line 207.
BEGIN failed--compilation aborted at /usr/share/mcstas/2.6/tools/Perl/perl/mcplotlib.pl line 23,  line 207.
Compilation failed in require at /usr/bin/mcgui.pl line 2181,  line 207.


  *   Of course the recommendation is to simply move to the Python tools, but if you insist to stay with perl, please do a local CPAN-based PDL installation like this:

sudo cpan install PDL


  *   Since a few releases, the default PGPLOT implementation on Ubuntu changed to Giza. Giza seems to now be getting better, see the April 30th 2018<http://www.mcstas.org/news/2018.html> hint if you want the legacy PGPLOT instead.

A new minor release 2.6.1 is on the way, implementing a few bugfixes, see our GitHub issue tracker<https://github.com/McStasMcXtrace/McCode/issues?q=is%3Aissue+label%3A%22McStas+2.6%22+>  for more information.


Best regards,
Peter Willendrup

Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics


[cid:b6339554-7f28-441d-9f31-5944f811397c at win.dtu.dk]


Technical University of Denmark


[cid:e108e480-fcab-46e2-9531-b38165079572 at win.dtu.dk]



Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/ea4f9d8f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 58 bytes
Desc: image001.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/ea4f9d8f/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1055 bytes
Desc: image002.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/ea4f9d8f/attachment-0003.gif>

From wildgrubercu at ornl.gov  Tue Apr 28 14:17:39 2020
From: wildgrubercu at ornl.gov (Wildgruber, Christoph U.)
Date: Tue, 28 Apr 2020 12:17:39 +0000
Subject: [mcstas-users] [EXTERNAL] Re: SANSCurve type component for I(qx,
 qy) instead of I(q)?
In-Reply-To: <B74F461B-9243-4106-992E-8FA318D0B0FE@fysik.dtu.dk>
References: <0603F868-C6DE-4E73-8E0E-311D2B7C5F39@ornl.gov>
 <B74F461B-9243-4106-992E-8FA318D0B0FE@fysik.dtu.dk>
Message-ID: <370E0C72-0AD0-4B4E-A06A-0E3145C53AAA@ornl.gov>

Hi Peter,

I?ll definitely look again more carefully :-)

Besides that my strategy is to get a younger person here excited
to learn how to write a McStas component?

Thanks so much,

Uli

On 28 Apr 2020, at 03:24, Peter Kj?r Willendrup <pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>> wrote:

Hi Uli,


On 27 Apr 2020, at 23.07, Wildgruber, Christoph U. <wildgrubercu at ornl.gov<mailto:wildgrubercu at ornl.gov>> wrote:

I might not be looking hard enough but I don?t think there is a SANS
sample component similar to SANSCurve (which uses I(q) as an input file)
that can handle I(qx, qy).

If anybody can point me in the right direction or has a component like that
to share it would be greatly appreciated!

For that sort of functionality I would be looking in the direction of the SASview (SASmodels really) sample http://www.mcstas.org/download/components/samples/SasView_model.html which does include models that are 2D in q. (It may also be that one of Henrich Frielinghaus? contributed sample components has a similar feature?)

The limitations of the SasView_model sample are that
a) I am not entirely sure the absolute normalisation is completely correct
b) One needs to recompile when shifting between models

Should you decide to implement one yourself instead, such a model would of course always be welcome as a contribution. ;-)


Best

Peter


Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics


<image001.gif>


Technical University of Denmark


<image002.gif>



Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/318a6655/attachment-0001.html>

From robert.dalgliesh at stfc.ac.uk  Tue Apr 28 14:33:34 2020
From: robert.dalgliesh at stfc.ac.uk (Robert Dalgliesh - UKRI STFC)
Date: Tue, 28 Apr 2020 12:33:34 +0000
Subject: [mcstas-users] [EXTERNAL] Re: SANSCurve type component for I(qx,
 qy) instead of I(q)?
In-Reply-To: <370E0C72-0AD0-4B4E-A06A-0E3145C53AAA@ornl.gov>
References: <0603F868-C6DE-4E73-8E0E-311D2B7C5F39@ornl.gov>
 <B74F461B-9243-4106-992E-8FA318D0B0FE@fysik.dtu.dk>
 <370E0C72-0AD0-4B4E-A06A-0E3145C53AAA@ornl.gov>
Message-ID: <4e2b482d22e547179051a5a04b0070d7@stfc.ac.uk>

Uli,
I think there are quite a few people who might be interested in this.
It is something that has come up in discussion quite frequently.
As Peter says the problem is usually how to get the absolute scattering intensity correct. Ideally it would also be great to think about how to get a transmission calculation correct for a time-of-flight instrument.
If you are interested in further discussion then I think it would be good to invite others into working on something together.

Best regards

Rob

===================================
Dr. Robert Dalgliesh
ISIS Neutron and Muon Source
STFC Rutherford Appleton Laboratory
R3 1.29
Harwell Oxford
Didcot
OX11 0QX
Office Tel: +44 (0) 1235 445687
Internal Mobile Extension: 1176

From: mcstas-users <mcstas-users-bounces at mcstas.org> On Behalf Of Wildgruber, Christoph U.
Sent: 28 April 2020 13:18
To: Peter Kj?r Willendrup <pkwi at fysik.dtu.dk>
Cc: McStas <mcstas-users at mcstas.org>; Qian, Shuo <qians at ornl.gov>
Subject: Re: [mcstas-users] [EXTERNAL] Re: SANSCurve type component for I(qx, qy) instead of I(q)?

Hi Peter,

I?ll definitely look again more carefully :-)

Besides that my strategy is to get a younger person here excited
to learn how to write a McStas component?

Thanks so much,

Uli

On 28 Apr 2020, at 03:24, Peter Kj?r Willendrup <pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>> wrote:

Hi Uli,


On 27 Apr 2020, at 23.07, Wildgruber, Christoph U. <wildgrubercu at ornl.gov<mailto:wildgrubercu at ornl.gov>> wrote:

I might not be looking hard enough but I don?t think there is a SANS
sample component similar to SANSCurve (which uses I(q) as an input file)
that can handle I(qx, qy).

If anybody can point me in the right direction or has a component like that
to share it would be greatly appreciated!

For that sort of functionality I would be looking in the direction of the SASview (SASmodels really) sample http://www.mcstas.org/download/components/samples/SasView_model.html which does include models that are 2D in q. (It may also be that one of Henrich Frielinghaus? contributed sample components has a similar feature?)

The limitations of the SasView_model sample are that
a) I am not entirely sure the absolute normalisation is completely correct
b) One needs to recompile when shifting between models

Should you decide to implement one yourself instead, such a model would of course always be welcome as a contribution. ;-)


Best

Peter


Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics

<image001.gif>


Technical University of Denmark


<image002.gif>



Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/1e1ba4bf/attachment.html>

From wildgrubercu at ornl.gov  Tue Apr 28 14:52:26 2020
From: wildgrubercu at ornl.gov (Wildgruber, Christoph U.)
Date: Tue, 28 Apr 2020 12:52:26 +0000
Subject: [mcstas-users] [EXTERNAL] Re: SANSCurve type component for I(qx,
 qy) instead of I(q)?
In-Reply-To: <4e2b482d22e547179051a5a04b0070d7@stfc.ac.uk>
References: <0603F868-C6DE-4E73-8E0E-311D2B7C5F39@ornl.gov>
 <B74F461B-9243-4106-992E-8FA318D0B0FE@fysik.dtu.dk>
 <370E0C72-0AD0-4B4E-A06A-0E3145C53AAA@ornl.gov>
 <4e2b482d22e547179051a5a04b0070d7@stfc.ac.uk>
Message-ID: <F1DE79A6-91BC-441A-BD3E-689B0B6B4D79@ornl.gov>

Hi Robert,

it?s good to know, that we are not the only ones who have some interest in that type of a component?
I agree with you guys what the main problem is. Absolute intensities  (within reasonable limits) is what we
really need. I guess we are mostly talking about multiple scattering and inelastic processes which
is a lot of fun if you have a broad energy spectrum in the primary beam :-)

We?ll be talking about this here to see if we can get a little core group together.
You?ll hear from me?

Best wishes,

Uli



On 28 Apr 2020, at 08:33, Robert Dalgliesh - UKRI STFC <robert.dalgliesh at stfc.ac.uk<mailto:robert.dalgliesh at stfc.ac.uk>> wrote:

Uli,
I think there are quite a few people who might be interested in this.
It is something that has come up in discussion quite frequently.
As Peter says the problem is usually how to get the absolute scattering intensity correct. Ideally it would also be great to think about how to get a transmission calculation correct for a time-of-flight instrument.
If you are interested in further discussion then I think it would be good to invite others into working on something together.

Best regards

Rob

===================================
Dr. Robert Dalgliesh
ISIS Neutron and Muon Source
STFC Rutherford Appleton Laboratory
R3 1.29
Harwell Oxford
Didcot
OX11 0QX
Office Tel: +44 (0) 1235 445687
Internal Mobile Extension: 1176

From: mcstas-users <mcstas-users-bounces at mcstas.org<mailto:mcstas-users-bounces at mcstas.org>> On Behalf Of Wildgruber, Christoph U.
Sent: 28 April 2020 13:18
To: Peter Kj?r Willendrup <pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>>
Cc: McStas <mcstas-users at mcstas.org<mailto:mcstas-users at mcstas.org>>; Qian, Shuo <qians at ornl.gov<mailto:qians at ornl.gov>>
Subject: Re: [mcstas-users] [EXTERNAL] Re: SANSCurve type component for I(qx, qy) instead of I(q)?

Hi Peter,

I?ll definitely look again more carefully :-)

Besides that my strategy is to get a younger person here excited
to learn how to write a McStas component?

Thanks so much,

Uli

On 28 Apr 2020, at 03:24, Peter Kj?r Willendrup <pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>> wrote:

Hi Uli,


On 27 Apr 2020, at 23.07, Wildgruber, Christoph U. <wildgrubercu at ornl.gov<mailto:wildgrubercu at ornl.gov>> wrote:

I might not be looking hard enough but I don?t think there is a SANS
sample component similar to SANSCurve (which uses I(q) as an input file)
that can handle I(qx, qy).

If anybody can point me in the right direction or has a component like that
to share it would be greatly appreciated!

For that sort of functionality I would be looking in the direction of the SASview (SASmodels really) sample http://www.mcstas.org/download/components/samples/SasView_model.html which does include models that are 2D in q. (It may also be that one of Henrich Frielinghaus? contributed sample components has a similar feature?)

The limitations of the SasView_model sample are that
a) I am not entirely sure the absolute normalisation is completely correct
b) One needs to recompile when shifting between models

Should you decide to implement one yourself instead, such a model would of course always be welcome as a contribution. ;-)


Best

Peter


Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics

<image001.gif>


Technical University of Denmark


<image002.gif>



Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200428/b75eb91e/attachment-0001.html>

From pkwi at fysik.dtu.dk  Mon May  4 12:22:45 2020
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Mon, 4 May 2020 10:22:45 +0000
Subject: [mcstas-users] McStas 2.6.1 update-release
Message-ID: <ED1E3E78-9821-43AD-A2C9-27EF2515D338@fysik.dtu.dk>

Dear all,


A new minor-release of McStas, v. 2.6.1 has been built and is ready for download!

Download and installation instructions are available via our GitHub download pages<https://github.com/McStasMcXtrace/McCode/tree/mcstas-2.6.1-release/INSTALL-McStas>.

The release adresses a few bugs found in the 2.6 release, see the related issue list at GitHub<https://github.com/McStasMcXtrace/McCode/issues?q=is%3Aissue++label%3A%22McStas+2.6%22+>, but is in terms of features and functionality almost identical to 2.6.


Best
Peter Willendrup

Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics


[cid:b6339554-7f28-441d-9f31-5944f811397c at win.dtu.dk]


Technical University of Denmark


[cid:e108e480-fcab-46e2-9531-b38165079572 at win.dtu.dk]



Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200504/541418da/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 58 bytes
Desc: image001.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200504/541418da/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1055 bytes
Desc: image002.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200504/541418da/attachment-0003.gif>

From pkwi at fysik.dtu.dk  Wed May 13 16:23:39 2020
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Wed, 13 May 2020 14:23:39 +0000
Subject: [mcstas-users] components Source_simple and Source_gen : parameter
	"flux"
Message-ID: <99D3E977-0155-45FE-A82E-DE297126688C@fysik.dtu.dk>

(Sent by Peter Willendrup on behalf of Thierry Bigault, ILL who originally sent the mail to the now defunct mcstas-support at mcstas.org<mailto:mcstas-support at mcstas.org> address)


Dear McStas programmers,

As I try to get advantage of these special conditions to try and use McStas, I have a beginner's question:

One of my aims is to be sure to have correct orders of magnitude for absolute flux.

I started to use the components Source_simple and Source_gen.
I assume that for the simplest case, the parameters "flux" in Source_simple and "I1" in Source_gen play the same role.
My expectation is that the flux measured by a monitor at a certain distance from the source follows Equation 3.1 in the "McStas 2.6 Component Manual of 24/01/2020", which links the source brilliance with source area, solid angle and wavelength interval.

This is the case with both sources if I set the parameter to 1: with 1 Ang bins, I get a flux on my monitor which scales according to this equation.
Following the component help, this behaviour should be observed by setting the parameter to 0. This in not the case, with 0 as input the calculation gives different flux values, which I am not able to link to anything physical.
The documentation is a bit misleading, because it recommends to put the value to 0 and the default is 1.

in Source_simple:
name:    flux
unit:    1/(s*cm**2*st*energy unit)
description:    flux per energy unit, Angs or meV if flux=0, the source emits 1 in 4*PI whole space.
default:    1

in Source_gen:
name:    I1
unit:    1/(cm**2*sr)
descrption:    Source flux per solid angle, area and Angstrom if I1=0, the source emits 1 in 4*PI whole space.
default:    1

My feeling is that:
- the unit should be in both case as in Source_simple,
- the same sentences would work with "flux=1" and "I1=1", which would be consistent with the default values. I have no idea if the 0 value is useful for some case.

But maybe I completely missed something...
I attached the very simple instrument file which I used.

Thierry






Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics


[cid:6b49ff07-bbc6-4db3-820c-5307f51551b2 at win.dtu.dk]



Technical University of Denmark


[cid:0cea8b1e-d480-46b2-bcd4-98dec8674d3c at win.dtu.dk]




Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f3889404/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 58 bytes
Desc: image001.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f3889404/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1055 bytes
Desc: image002.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f3889404/attachment-0003.gif>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MonInstrumentToutPourri.instr
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f3889404/attachment-0001.ksh>

From pkwi at fysik.dtu.dk  Wed May 13 17:02:20 2020
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Wed, 13 May 2020 15:02:20 +0000
Subject: [mcstas-users] components Source_simple and Source_gen :
 parameter	"flux"
In-Reply-To: <99D3E977-0155-45FE-A82E-DE297126688C@fysik.dtu.dk>
References: <99D3E977-0155-45FE-A82E-DE297126688C@fysik.dtu.dk>
Message-ID: <112F989A-763D-4483-B8E0-47F6274DEADD@fysik.dtu.dk>

Dear Thierry,


Comments and answers follow in-line below.

On 13 May 2020, at 16.23, Peter Kj?r Willendrup <pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>> wrote:

As I try to get advantage of these special conditions to try and use McStas, I have a beginner's question:

One of my aims is to be sure to have correct orders of magnitude for absolute flux.

I started to use the components Source_simple and Source_gen.
I assume that for the simplest case, the parameters "flux" in Source_simple and "I1" in Source_gen play the same role.
My expectation is that the flux measured by a monitor at a certain distance from the source follows Equation 3.1 in the "McStas 2.6 Component Manual of 24/01/2020", which links the source brilliance with source area, solid angle and wavelength interval.

This is the case with both sources if I set the parameter to 1: with 1 Ang bins, I get a flux on my monitor which scales according to this equation.
Following the component help, this behaviour should be observed by setting the parameter to 0. This in not the case, with 0 as input the calculation gives different flux values, which I am not able to link to anything physical.
The documentation is a bit misleading, because it recommends to put the value to 0 and the default is 1.

in Source_simple:
name:    flux
unit:    1/(s*cm**2*st*energy unit)
description:    flux per energy unit, Angs or meV if flux=0, the source emits 1 in 4*PI whole space.
default:    1

in Source_gen:
name:    I1
unit:    1/(cm**2*sr)
descrption:    Source flux per solid angle, area and Angstrom if I1=0, the source emits 1 in 4*PI whole space.
default:    1

My feeling is that:
- the unit should be in both case as in Source_simple,
- the same sentences would work with "flux=1" and "I1=1", which would be consistent with the default values. I have no idea if the 0 value is useful for some case.


I agree, there is clearly a documentation issue here. :-)

Documentation aside, as far as I can see, the two components behave numerically exactly the same using flux and I1 - see attached instrument where once can select the used source and the intensity as input parameters.

I believe the right documentation sentence should be along the lines of

?Source flux per source area (specified by e.g. xwidth x yheight), per solid angle (specified by dist+ focus_wx x focus_yh), per second (McStas ?intensities? always are assumed to be) and per used wavelength/energy interval.?

I think that perhaps the special flux=0 / I1=0 case at least originally was envisioned correspond to setting the flux-unit to unity and ?not apply focusing?, but as the documentation is written and how the components in practice works, that special case seems to make no sense. :-)

I will define a GitHub issue to ensure this is rectified in a future release. :-)


Best and thanks for the input,

Peter


Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics


[cid:8cbfc342-2ffb-4ef7-a279-a75e5c753bb1 at win.dtu.dk]



Technical University of Denmark


[cid:c30418ef-1afd-43fd-9f3a-66457eee65a1 at win.dtu.dk]




Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f36e0248/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 58 bytes
Desc: image001.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f36e0248/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1055 bytes
Desc: image002.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f36e0248/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MonInstrumentToutPourri.instr
Type: application/octet-stream
Size: 1483 bytes
Desc: MonInstrumentToutPourri.instr
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200513/f36e0248/attachment-0001.obj>

From bigault at ill.fr  Wed May 20 12:04:30 2020
From: bigault at ill.fr (Thierry Bigault)
Date: Wed, 20 May 2020 12:04:30 +0200
Subject: [mcstas-users] Supermirror reflectivity calculation
Message-ID: <cd1661f5-a073-fb16-b5bf-031e693e2136@ill.fr>

Dear McStas users,

First, as I am trying to use some basic components, I think that this 
statement from the McStas component manual (2.6), about the use of the 
analytical reflectivity calculation for mirror and guide devices, is wrong:

"It is important to notice that when m < 1, the reflectivity remains 
constant at R = R0 up to q = Qc, and not m.Qc.
This means that m < 1 parameters behave like m = 1 materials."

If you try the attached file instrument, you will that as expected the 
cut-off wavelength of a simple mirror with 1deg incidence angle, for a 
collimated beam, depends on the m-value of the surface:
- 10 Ang for m=1
- 5 Ang for m=2
- 20 Ang for m=0.5
- 30 Ang for m=0.333
The two last results show that when m<1, the reflectivity falls to 0 
after m.Qc, and not after Qc. This is in contradiction with the 
documentation, but in agreement with what the user would expect (at 
least me...).
I tested here with Mirror.comp, but I observed the same behaviour with 
Guide_gravity.comp, and as I understand all guide components use the 
same routine for calculating the reflectivity.
I may have done something wrong, as I am not experienced with McStas.

Second, I think that the analytical empirical formula for supermirror 
reflectivity sometimes behaves in a strange way:
For a given value of m (e.g. m=2), if one changes Qc to something 
different from the default value, the actual supermirror cut-off also 
changes.
This is not what I would expect. The general convention is that the "m" 
value is defined as Qmax(supermirror)/Qc(natural Nickel), therefore it 
should not depend on another parameter than m.
On the other hand, one can imagine having a material different from 
nickel on the supermirror surface, which would have a different Qc (for 
total reflection).
Therefore it may be useful to change Qc and m, but these should be 
completely independent parameters.
For these reasons, I would suggest to replace the formula used in the 
reflectivity calculation by this one:

R= 1/2*R0*(1 - tanh[(Q-m.QcNi)/W]) (1-alpha* (Q - Qc))

It is the same as today, except that the parameter Qc in the tanh 
function is replaced by the constant QcNi(=0.0217). This makes the 
supermirror cutoff independent from the Qc parameter, which determines 
the range of total reflection but nothing else.
As I understand one can always use a file to model the reflectivity of 
guide faces, but I think it it also nice to have simple analytical 
formula with a clear and predictable behaviour.


Thierry Bigault




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200520/83f1c281/attachment.html>
-------------- next part --------------
/*******************************************************************************
* Instrument: <Mirror_cutoff>
*
* %Identification
*
* author: <Thierry Bigault (bigault at ill.fr)>
* date: 18/05/2020
* version: 1.0
* origin: ILL
*
* %Instrument_site: None
* 
* %Description
* 
* Simple test of components: reflection on supermirrors
*
* %Parameters
* 
*
* %Links 
*  <reference/HTML link>
* 
* %End
*
********************************************************************************/
DEFINE INSTRUMENT Mirror_cutoff()

DECLARE
%{
/* Source wavelength range */
  double longuonde=20.0001;
  double dlonguonde=20;
  
  /* source parameters*/
  double DistSourceGuide = 100;  /* Distance from the source to the mirror */
%}

INITIALIZE
%{
%}

TRACE

COMPONENT origin = Progress_bar()
AT (0, 0, 0) RELATIVE ABSOLUTE

/* Source simple, with a long focusing distance producing a highly collimated beam */
COMPONENT MaSource = Source_simple(
    yheight=.01, 
    xwidth=0.01, 
    dist=DistSourceGuide, 
    focus_xw=0.02,  
    focus_yh=0.02,  
    lambda0=longuonde, 
    dlambda=dlonguonde)
AT (0, 0, 0) RELATIVE PREVIOUS

/* monitor before mirror */
COMPONENT MoniteurEntreeGuide = Monitor_nD(
    xwidth=0.051, 
    yheight=0.2, 
    options="lambda, limits=[0 40] bins=80")
	AT (0, 0, DistSourceGuide) RELATIVE MaSource

/* Mirror with incidence angle 1deg, catching all neutrons.
* Any neutron is either reflected by the mirror, and catched by MoniteurApresMiroirR, 
* or transmitted and catched by MoniteurApresMiroirT
*/
COMPONENT miroir = Mirror(
    xwidth=3, 
    yheight=0.3, 
    R0=1, 
    m=1,         // determines the wavelength cutoff of the mirror
    Qc=0.021,
    alpha=1, 
    center=1, 
    transmit=1
   )  	AT (0, 0, DistSourceGuide+1.5) RELATIVE MaSource
	ROTATED (0, 90-1, 0) RELATIVE MaSource

/* Monitor for transmitted neutrons */
COMPONENT MoniteurApresMiroirT = Monitor_nD(
    xwidth=0.3, 
    yheight=0.8, 
    options="lambda, limits=[0. 40] bins=80")
	AT (0, 0, 2*DistSourceGuide+4) RELATIVE MaSource

/* Monitor for reflected neutrons */
COMPONENT MoniteurApresMiroirR = Monitor_nD(
    xwidth=0.3, 
    yheight=0.8, 
    options="lambda, limits=[0. 40] bins=80")
	AT (-0.300/2-0.026, 0, 1* DistSourceGuide+3.1) RELATIVE MaSource

FINALLY
%{
%}

END


From pkwi at fysik.dtu.dk  Tue May 26 14:57:19 2020
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Tue, 26 May 2020 12:57:19 +0000
Subject: [mcstas-users] Experimental Docker-solution for McStas 2.6.1 and
	McXtrace 1.5
Message-ID: <F91799AF-C02E-46E4-B53E-5402D0EC4495@fysik.dtu.dk>

Dear all,


The combined McStas and McXtrace team have started experimenting with using Docker's for deployment.

- The advantage is simplified installation and a uniform look and feel / functionality across platforms.

If you feel like giving our experimental docker solution a spin, have a look at

https://github.com/McStasMcXtrace/McCode/blob/master/Docker/README.md


Best,

Peter

Peter Kj?r Willendrup
Forskningsingeni?r, Specialkonsulent
N?stformand for DTU Fysik LSU

DTU Physics


[cid:b6339554-7f28-441d-9f31-5944f811397c at win.dtu.dk]


Technical University of Denmark


[cid:e108e480-fcab-46e2-9531-b38165079572 at win.dtu.dk]



Department of Physics
Fysikvej
Building 307
DK-2800 Kongens Lyngby
Direct +45 2125 4612
Mobil +45 2125 4612
Fax +45 4593 2399
pkwi at fysik.dtu.dk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200526/63ed78f8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 58 bytes
Desc: image001.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200526/63ed78f8/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1055 bytes
Desc: image002.gif
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200526/63ed78f8/attachment-0003.gif>

From robert.dalgliesh at stfc.ac.uk  Fri May 29 16:25:03 2020
From: robert.dalgliesh at stfc.ac.uk (Robert Dalgliesh - UKRI STFC)
Date: Fri, 29 May 2020 14:25:03 +0000
Subject: [mcstas-users] Rotating polarising mirror components
Message-ID: <763b61843b54497aa9635aa2d0bacefc@stfc.ac.uk>

Hi Peter, Erik,
I've been looking in more detail at what happens when I rotate a polarising mirror or v-mirror in mcstas as a result of getting repeated assert errors from the polarisation being greater than 1.
I am having trouble working out if the polarisation vector is rotated correctly if e.g. Pol_mirror is rotated by 90deg to be in a horizontal rather than vertical geometry. The code performs a calculation of probabilities based on the sy component (GetMonoPolRefProb(FN, FM, sy, &refWeight)) but if I have a polarisation in the x-z plane prior to the component I have been unable to determine what is happening.
In order to makes things correct the incoming spin vector would need to be rotated by 90 degrees on entering the pol_mirror component. Is this done in some hidden way or do I need to rewrite the components to deal with this?

Thanks

Rob

===================================
Dr. Robert Dalgliesh
ISIS Neutron and Muon Source
STFC Rutherford Appleton Laboratory
R3 1.29
Harwell Oxford
Didcot
OX11 0QX
Office Tel: +44 (0) 1235 445687
Internal Mobile Extension: 1176


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200529/b8041d8e/attachment.html>

From robert.dalgliesh at stfc.ac.uk  Fri May 29 17:50:20 2020
From: robert.dalgliesh at stfc.ac.uk (Robert Dalgliesh - UKRI STFC)
Date: Fri, 29 May 2020 15:50:20 +0000
Subject: [mcstas-users] Rotating polarising mirror components
In-Reply-To: <763b61843b54497aa9635aa2d0bacefc@stfc.ac.uk>
References: <763b61843b54497aa9635aa2d0bacefc@stfc.ac.uk>
Message-ID: <9816fea7304b4c328c52a34df762bba9@stfc.ac.uk>

Peter, Erik,
I apologise, I've just noticed the note in the component description regarding the hard coding of the polarisation direction.
I will modify my simulations accordingly.

Sorry everyone

Rob

From: mcstas-users <mcstas-users-bounces at mcstas.org> On Behalf Of Robert Dalgliesh - UKRI STFC
Sent: 29 May 2020 15:25
To: McStas <mcstas-users at mcstas.org>
Subject: [mcstas-users] Rotating polarising mirror components

Hi Peter, Erik,
I've been looking in more detail at what happens when I rotate a polarising mirror or v-mirror in mcstas as a result of getting repeated assert errors from the polarisation being greater than 1.
I am having trouble working out if the polarisation vector is rotated correctly if e.g. Pol_mirror is rotated by 90deg to be in a horizontal rather than vertical geometry. The code performs a calculation of probabilities based on the sy component (GetMonoPolRefProb(FN, FM, sy, &refWeight)) but if I have a polarisation in the x-z plane prior to the component I have been unable to determine what is happening.
In order to makes things correct the incoming spin vector would need to be rotated by 90 degrees on entering the pol_mirror component. Is this done in some hidden way or do I need to rewrite the components to deal with this?

Thanks

Rob

===================================
Dr. Robert Dalgliesh
ISIS Neutron and Muon Source
STFC Rutherford Appleton Laboratory
R3 1.29
Harwell Oxford
Didcot
OX11 0QX
Office Tel: +44 (0) 1235 445687
Internal Mobile Extension: 1176


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200529/1dc6d90d/attachment.html>

From bigault at ill.fr  Thu Jun 18 18:59:23 2020
From: bigault at ill.fr (Thierry Bigault)
Date: Thu, 18 Jun 2020 18:59:23 +0200
Subject: [mcstas-users] Inconsistent results using MPI and SPLIT
In-Reply-To: <cd1661f5-a073-fb16-b5bf-031e693e2136@ill.fr>
References: <cd1661f5-a073-fb16-b5bf-031e693e2136@ill.fr>
Message-ID: <aff3fc13-0fee-f838-7394-48ca4d42a55c@ill.fr>

Dear All,

I built the attached instrument file to try and simulate a reflectometer.
When I saw that I needed 10 minutes of calculation to get 3 neutrons on 
my sample, I thought it was time to try and optimize.
After having a look at the manual, I first put some SPLIT keywords 
positioned at 5 different components, which I estimate as strategic. I 
gained a lot in statistics on the sample.
Then I decided to use the MPI feature, as my laptop has 8 cores. It 
nicely reduces the computing time, at first sight it looks really great !
But the results looked strange, so I made some more systematic tests and 
the result is on the attached plots. With all SPLIT commented ("no 
SPLIT") it looks fine, the calculated intensity on the sample is 
consistent within the error-bars, whatever the number of nodes I use. 
When combining all SPLITs active and MPI ("5 SPLIT"), the calculation 
time and error-bars can be strongly reduced but the result depends 
completely on the number of nodes, with differences much larger than the 
error-bar...
Either I did something wrong, or there is a bug somewhere. If someone 
has an idea about this issue, I would be interested.
I use version 2.6.1 (May 04, 2020) on Windows 10.

Thierry





-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPI and SPLIT tests full H15.tif
Type: image/tiff
Size: 1498450 bytes
Desc: not available
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200618/4669a211/attachment-0001.tif>
-------------- next part --------------
/*******************************************************************************
* Instrument: <MonH15_T3_levieux>
*
* %Identification
*
* author: <Thierry Bigault (bigault at ill.fr)>
* date: 07/05-16/06/2020
* version: 1.0
* origin: ILL
*
* %Instrument_site: ILL
* 
* %Description
* 
* Attempt to reconstruct H15 up to T3, as of 12/05/2020
* the notations are those of DPT11 Ind C (March 2017)  
* There was a change of H1-H2 in 2006 (SNAG)
*
* %Parameters
*
*  longmin, longmax [Ang] : min / max wavlengths generated by the source
*  gGap [m]: little gaps between elments all along the guide
*  gAlpha [-]: slope of reflectivity curves after Qc
*  m_AvalVS [-]: m-value of guide coatings after the Safety Valve
*  IN6MonoAngle [deg]: average Bragg angle of IN6 triple monochromator
*
* %Links 
*  <reference/HTML link>
* 
* %End
********************************************************************************/
DEFINE INSTRUMENT MonH15_T3_levieux(
	double longmin = 0.1, double longmax=15.1,
	double gGap = 0.001, double gAlpha = 3, double m_AvalVS = 1,
	double IN6MonoAngle = 49.47)

DECLARE
%{
  /* global parameters*/
//  double longmin=0.1;
 // double longmax=15.1;
  double longuonde; 
  double dlonguonde; 
  
  /* source parameters*/
  double DistSourceGuide = 2.330;   /* Distance from the source to the guide entry */
  
  /* gaps and Al windows parameters */
  double Al_Thickness = 0.002;
//  double gGap		= 0.001; 
  double VS_gap	= 0.148;   /* thickness of VS (="B") */
  double OT1H15_gap	= 0.107;   /* space between guides for OT1H15 shutter (="D") */
  double OT2H15_gap	= 0.113;	// space between guides for OT2H15 shutter (="G")   
  
  /* Guide geometry parameters H15-1, 2, A */
  double LH15_1 =	1.997;
  double LH15_2=	1.289;
  double LH15_A=	0.228;

  /* Guide geometry parameters H15-3*/
  double LH15_3=	5.500;
  double RH15_3=	2850;	/* curvature radius realised (design=2700 m) */
  double LongSegmentH15_3 = 0.5;
  double AngleSegmentH15_3;	/*angle between successive segments */
  double AngleTotalH15_3;		/*angle for the total H15_3 length */

  /* Guide geometry parameters H15-4*/
  double LH15_4=	17.000;
  double RH15_4=	2850;  /* curvature radius realised (design=2700 m) */
  double LongSegmentH15_4 = 1;
  double AngleSegmentH15_4;	/*angle between successive segments */
  double AngleTotalH15_4;		/*angle for the total guide section length */

  /* Guide geometry parameters H15-5*/
  double LH15_5=	4.750;
  double RH15_5=	2850;  /* curvature radius realised (design=2700 m) */
  double NombreSegmentsH15_5= 5;	/* closest possible to 1m-long segments */
  double LongSegmentH15_5;
  double AngleSegmentH15_5;	/*angle between successive segments */
  double AngleTotalH15_5;		/*angle for the total guide section length */	

/* Guide geometry parameters H15-6*/
  double LH15_6=	22.335;
  double RH15_6=	2700;  
  double NombreSegmentsH15_6= 22;	/* closest possible to 1m-long segments */
  double LongSegmentH15_6;
  double AngleSegmentH15_6;	/*angle between successive segments */
  double AngleTotalH15_6;		/*angle for the total guide section length */	

/* IN6 Monochormator */
//  double IN6MonoAngle = 37.66;	// Bragg angle, min = 37.66 (4.1 AA), max = 61.55 (5.9 AA) 
  double IN6Mono_gap = 0.170;	/* gap between guides at the IN6 mono position */
  double IN6_LA = 2.100;	// Distance monok - sample
  double IN6_l = 0.030;	// distance along z between 2 crystals
  double IN6_dtheta = 0;	// Bragg angle difference between 2 crystals

/* Guide geometry parameters H15-7*/
  double LH15_7=	5.415;
  double RH15_7=	2700;  
  double NombreSegmentsH15_7= 5;	/* closest possible to 1m-long segments */
  double LongSegmentH15_7;
  double AngleSegmentH15_7;	/*angle between successive segments */
  double AngleTotalH15_7;		/*angle for the total guide section length */	

/* T3 geometry parameters */
  double T3Mono_gap = 0.060; // measure roughly on SLDASM file
  double T3MonoAngle = 45;
  double T3_MonoD1 = 1.285; 
  double T3_D1D2 = 0.800;
  double T3_D2Sample = 0.270;
  double T3_SampleDet = 0.700; 

  /* Guide geometry parameters H151-14 */
  double LH151_14 =	7.000;

  /* guide coating parameters */
  double gR0          = 1;
  double gQc          = 0.0217;
//  double gAlpha       = 3;	//4.07;    3 corresponds to today's standard at SwN, R>=93% at m=2	
  double gW           = 0.0001;
  double m_AmontVS=	2.1;  /* m of coating upstream the VS (="B") */
//  double m_AvalVS=	1.;  /* m of coating downstream the VS (="B") */
%}

INITIALIZE
%{
  longuonde = (longmax+longmin)/2; 
  dlonguonde = (longmax-longmin)/2; 

  /* rotation angle between each guide segment in H15_3 */
  AngleSegmentH15_3 = (LongSegmentH15_3 / RH15_3) * RAD2DEG;
  AngleTotalH15_3	 = 	(LH15_3 / RH15_3) * RAD2DEG;
  printf("H15_3: angle par segment = %f deg \n", AngleSegmentH15_3);
  printf("H15_3: angle total = %f deg \n", AngleTotalH15_3);

  /* rotation angle between each guide segment in H15_4 */
  AngleSegmentH15_4 = (LongSegmentH15_4 / RH15_4) * RAD2DEG;
  AngleTotalH15_4	 = 	(LH15_4 / RH15_4) * RAD2DEG;
  printf("H15_4: angle per segment = %f deg \n", AngleSegmentH15_4);
  printf("H15_4: total angle = %f deg \n", AngleTotalH15_4);

  /* Segment Length and rotation angle between each guide segment in H15_5 */
  LongSegmentH15_5	= LH15_5 / NombreSegmentsH15_5;   
  AngleSegmentH15_5	= (LongSegmentH15_5 / RH15_5) * RAD2DEG;
  AngleTotalH15_5	= (LH15_5 / RH15_5) * RAD2DEG;
  printf("H15_5: length per segment = %f m \n", LongSegmentH15_5);
  printf("H15_5: angle per segment = %f deg \n", AngleSegmentH15_5);
  printf("H15_5: total angle = %f deg \n", AngleTotalH15_5);

/* Segment Length and rotation angle between each guide segment in H15_6 */
  LongSegmentH15_6	= LH15_6 / NombreSegmentsH15_6;   
  AngleSegmentH15_6	= (LongSegmentH15_6 / RH15_6) * RAD2DEG;
  AngleTotalH15_6	= (LH15_6 / RH15_6) * RAD2DEG;
  printf("H15_6: length per segment = %f m \n", LongSegmentH15_6);
  printf("H15_6: angle per segment = %f deg \n", AngleSegmentH15_6);
  printf("H15_6: total angle = %f deg \n", AngleTotalH15_6);

/* Calculation of Bragg angle difference between IN6 mono crystals */
  double IN6_L = IN6_LA * sin( 2 * IN6MonoAngle * DEG2RAD);   // distance neutron axis - sample
  double IN6_l0 = IN6_LA * cos( 2 * IN6MonoAngle * DEG2RAD);	// 3rd side of triangle IN6_L, IN6_LA
  double IN6_LB = sqrt( pow(IN6_L, 2) + pow(IN6_l + IN6_l0, 2 ) );	// distance crystal B - sample
  IN6_dtheta = 0.5 * RAD2DEG * tan( 2 * IN6MonoAngle * DEG2RAD ) * (IN6_LB - IN6_LA) / IN6_LB;	// Bragg angle difference B -A
//  printf("distance neutron axis - sample = %f  \n", IN6_L);
//  printf("l0 = %f  \n", IN6_l0);
//  printf("LB = %f  \n", IN6_LB);
  printf("Bragg angle difference B -A = %f  deg \n", IN6_dtheta);

/* Segment Length and rotation angle between each guide segment in H15_7 */
  LongSegmentH15_7	= LH15_7 / NombreSegmentsH15_7;   
  AngleSegmentH15_7	= (LongSegmentH15_7 / RH15_7) * RAD2DEG;
  AngleTotalH15_7	= (LH15_7 / RH15_7) * RAD2DEG;
  printf("H15_7: length per segment = %f m \n", LongSegmentH15_7);
  printf("H15_7: angle per segment = %f deg \n", AngleSegmentH15_7);
  printf("H15_7: total angle = %f deg \n", AngleTotalH15_7);

%}

TRACE

COMPONENT origin = Progress_bar()
AT (0, 0, 0) RELATIVE ABSOLUTE

/* Source Froide Verticale (VCS) */
COMPONENT VCS = Source_gen(
  yheight  = 0.22,     xwidth   = 0.14,
  dist     = DistSourceGuide, 
  focus_xw = 0.038,  focus_yh = 0.2,
  Lmin = longmin,   Lmax = longmax,
  T1=216.8, I1=1.24e+13, 	/* VCS parameters for 58 MW */
  T2=33.9, I2=1.02e+13,
  T3=16.7 ,I3=3.0423e+12,
  verbose  = 1)
	AT (0, 0, 0) RELATIVE PREVIOUS

/* 5 Al windows 2mm, like Farhi 2004 or Martin 2020 */
COMPONENT Al_window1 = Al_window(thickness=Al_Thickness)	AT (0,0,0.21) RELATIVE VCS
COMPONENT COPY(Al_window1) = COPY(PREVIOUS)	AT (0,0,0.61) RELATIVE VCS
COMPONENT COPY(Al_window1) = COPY(PREVIOUS)	AT (0,0,0.78) RELATIVE VCS
COMPONENT COPY(Al_window1) = COPY(PREVIOUS)	AT (0,0,0.92) RELATIVE VCS
COMPONENT COPY(Al_window1) = COPY(PREVIOUS)	AT (0,0,2.20) RELATIVE VCS

/* monitor before 1st guide  */
COMPONENT MoniteurEntreeGuide = Monitor_nD(
    xwidth= 0.051, 
    yheight= 0.2,	 
    restore_neutron = 1,
//    options="x y, auto, all bins=40"
    options="auto lambda, bins=50, capture per cm2"
    )		AT (0, 0, DistSourceGuide - Al_Thickness - 2*gGap) RELATIVE VCS

/* guides H15-1 and H15-2: L=3.29 m in 2 elements. no curvature 
*  Carters: Doigt de Gant; Carter Pink  */
COMPONENT H15F1 = Al_window(thickness = Al_Thickness)
	AT (0, 0, DistSourceGuide - Al_Thickness - gGap) RELATIVE VCS

COMPONENT GuideH15_1 = Guide_gravity(
  w1 = 0.051, h1 = 0.2,  w2 = 0.04735, h2=0.2,  l = LH15_1,
  m = m_AmontVS,  R0 = gR0, Qc = gQc, alpha = gAlpha, W = gW)
	AT (0, 0, DistSourceGuide) RELATIVE VCS

COMPONENT GuideLH15_2 = Guide_gravity(
  w1= 0.04735, h1 = 0.2,  w2 = 0.045, h2 = 0.2,  l = LH15_2,
  m = m_AmontVS,  R0 = gR0, Qc = gQc, alpha = gAlpha, W = gW)
	AT (0, 0, LH15_1 + gGap) RELATIVE GuideH15_1

/* guides H15-A, L=0.23 m in 1 element. no curvature 
* Carter: obturateur Plomb  */
COMPONENT GuideH15_A = Guide_gravity(
  w1= 0.045, h1 = 0.2, w2 = 0.045,	h2 = 0.2, l = LH15_A,
  m = m_AmontVS,  R0 = gR0, Qc = gQc, alpha = gAlpha, W = gW)
	AT (0, 0, LH15_2 + gGap) RELATIVE GuideLH15_2

/* Reference for positions (z=0) in DPT11-C "Schematique de la ligne H15" */
COMPONENT H15F2 = Al_window(thickness = Al_Thickness)
	AT (0, 0, LH15_A + gGap) RELATIVE PREVIOUS

/* guide H15-3, L=5.50 m in 2 elements. Curved left with radius = 2850 m 
* This guide gets out of the H1-H2 swimming pool somewhere */
COMPONENT GuideH15_3_1 = Guide_gravity(
  w1= 0.045, h1=0.2, w2 = 0.045, h2 = 0.2,   l = LongSegmentH15_3,
  m = m_AmontVS,  R0 = gR0, Qc = gQc, alpha= gAlpha, W= gW)
	AT (0, 0, LH15_A + Al_Thickness + 2*gGap) RELATIVE GuideH15_A  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_2 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_3 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_4 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_5 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_6 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_7 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_8 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_9 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_10 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_3_11 = COPY(PREVIOUS)
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_3, 0) RELATIVE PREVIOUS

/* Reference position 1 for capture flux measurements (no value in DPT11-IndC)*/
COMPONENT PastilleOr1 = Monitor_nD(
    xwidth=0.045,     yheight=0.2,
    options="auto lambda, bins=50, capture per cm2")
	AT (0, 0, LongSegmentH15_3 + gGap) RELATIVE PREVIOUS

/* VS (=point "B"), which is just a gap of 0.148 m */
COMPONENT BrasVS = Arm()
	AT (0, 0, VS_gap) RELATIVE PREVIOUS
	ROTATED (0, AngleTotalH15_3, 0) RELATIVE GuideH15_A

/* guide H15-4, L=17.0 m in 17 elements (10, then capture flux monitor, then 7). Radius = 2850 m */
/*SPLIT*/ COMPONENT GuideH15_4_1 = Guide_gravity(
  w1= 0.030, h1 = 0.2, w2 = 0.030,	h2 = 0.2, l = LongSegmentH15_4,
  m = m_AvalVS, R0 = gR0, Qc = gQc, alpha = gAlpha, W = gW)
	AT (0, 0, 0) RELATIVE BrasVS	ROTATED (0, AngleSegmentH15_4, 0) RELATIVE BrasVS
COMPONENT GuideH15_4_2 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_3 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_4 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_5 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_6 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_7 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_8 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_9 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_10 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS

/* Reference position 2 for capture flux measurements (no value in DPT11-IndC), within 10 cm in z. */
COMPONENT PastilleOr2 = Monitor_nD(
    xwidth=0.030,     yheight=0.200, 
    options="auto lambda, bins=50, capture per cm2")
	AT (0, 0, LongSegmentH15_4 + gGap/2) RELATIVE PREVIOUS

/* guide H15-4: remaining 7 elements (out of 17) */
COMPONENT GuideH15_4_11 = COPY(GuideH15_4_10)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE GuideH15_4_10  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE GuideH15_4_10
COMPONENT GuideH15_4_12 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_13 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_14 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_15 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_16 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_4_17 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_4 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_4, 0) RELATIVE PREVIOUS

COMPONENT BrasMembraneMince = Arm()
	AT (0, 0, LongSegmentH15_4+gGap) RELATIVE PREVIOUS

/* H15F3 Membrane mince (="C"), before crossing the reactor building enclosure */
COMPONENT H15F3 = Al_window( thickness = Al_Thickness)
	AT (0, 0, 0) RELATIVE PREVIOUS

/* Reference position 3 for capture flux measurements (no value in DPT11-IndC), within ** cm in z. */
COMPONENT PastilleOr3 = Monitor_nD(
    xwidth=0.030, 
    yheight=0.200, 
    options="auto lambda, bins=50, capture per cm2, parallel")
	AT (0, 0, Al_Thickness + gGap) RELATIVE PREVIOUS

/* A  PSD flux monitor */
/*COMPONENT PSD = Monitor_nD(
    xwidth=0.030, 
    yheight=0.200, 
    options="x y, auto, bins=[3, 5], parallel, unactivate"
	)	AT (0, 0, 0) RELATIVE PREVIOUS */

/* guide H15-5: 5 elements of adjusted equal lengths (different from real guide) with R = 2850 */
COMPONENT GuideH15_5_1 = COPY(GuideH15_4_17)
  (l = LongSegmentH15_5)
	AT (0, 0, gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_5, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_5_2 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_5 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_5, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_5_3 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_5 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_5, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_5_4 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_5 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_5, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_5_5 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_5 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_5, 0) RELATIVE PREVIOUS
COMPONENT H15F4 = Al_window( thickness = Al_Thickness)
	AT (0, 0, LongSegmentH15_5 + gGap) RELATIVE PREVIOUS

/* OT1 H15 (= point "D"), with a gap of 0.107 m */
COMPONENT BrasOT1H15 = Arm()
	AT (0, 0, Al_Thickness  + OT1H15_gap) RELATIVE H15F4
	ROTATED (0, AngleTotalH15_5, 0) RELATIVE BrasMembraneMince

/*  guide H15-6: 22 elements of adjusted equal lengths (different from real guide).
*  14 elements, then capture flux monitor, then 8 elements.  Curvature R = 2700 m */
COMPONENT H15F5 = Al_window( thickness = Al_Thickness)	AT (0, 0, 0) RELATIVE BrasOT1H15
COMPONENT GuideH15_6_1 = COPY(GuideH15_5_5)	(l = LongSegmentH15_6)
	AT (0, 0, Al_Thickness + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_2 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_3 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_4 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_5 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_6 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_7 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_8 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_9 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_10 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_11 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_12 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_13 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_14 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS

/* Reference position 7 for capture flux measurements (DPT11-IndC), within 2 cm in z. */
COMPONENT PastilleOr7 = Monitor_nD(
    xwidth=0.030,     yheight=0.200, 
    options="auto lambda, bins=50, capture per cm2")
	AT (0, 0, LongSegmentH15_6 + gGap/2) RELATIVE PREVIOUS

/* guide H15-6: remaining 8 elements (out of 22) */
COMPONENT GuideH15_6_15 = COPY(GuideH15_6_14)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE GuideH15_6_14  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE GuideH15_6_14
COMPONENT GuideH15_6_16 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_17 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_18 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_19 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_20 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_21 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_6_22 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_6, 0) RELATIVE PREVIOUS
COMPONENT H15F6 = Al_window( thickness = Al_Thickness)
	AT (0, 0, LongSegmentH15_6 + gGap) RELATIVE PREVIOUS

/* capture flux measurement  */
COMPONENT CaptureAvantMonoIN6 = Monitor_nD(
    xwidth = 0.030, yheight = 0.200, 
    options="auto lambda, bins=100, capture per cm2, parallel")
	AT (0, 0,  Al_Thickness + gGap) RELATIVE PREVIOUS

/* IN6 Monochomator, with gap of 0.170m between guides */
COMPONENT BrasIN6MonoGap = Arm()
	AT (0, 0, Al_Thickness  + IN6Mono_gap) RELATIVE H15F6
	ROTATED (0, AngleTotalH15_6, 0) RELATIVE BrasOT1H15

/* IN6 Triple vertically focusing HOPG Monochomator */
COMPONENT IN6_MonochromatorFront = Monochromator_curved(
   RV     = 3, NV = 7, NH=1,
   zwidth = 0.054, yheight = 0.029,  // individual crystals sizes
   DM     = 3.355, gap = 0.001,
   mosaic = 40, r0 = 1, t0 = 1  // mosaic in arcmin
 	) AT (0, 0, IN6Mono_gap / 2 - IN6_l) RELATIVE H15F6
	ROTATED (0, IN6MonoAngle - IN6_dtheta, 0) RELATIVE H15F6
COMPONENT IN6_MonochromatorMiddle = COPY(PREVIOUS)
   	AT (0, 0, IN6Mono_gap / 2) RELATIVE H15F6
	ROTATED (0, IN6MonoAngle , 0) RELATIVE H15F6
COMPONENT IN6_MonochromatorBack = COPY(PREVIOUS)
 	AT (0, 0, IN6Mono_gap / 2 + IN6_l) RELATIVE H15F6
	ROTATED (0, IN6MonoAngle + IN6_dtheta, 0) RELATIVE H15F6

/* capture flux measurement  */
COMPONENT CaptureAfterMonoIN6 = Monitor_nD(
    xwidth = 0.030, yheight = 0.200, 
    options="lambda limits=[0.1 10.1], bins=100, capture per cm2, parallel")
	AT (0, 0,  0) RELATIVE BrasIN6MonoGap

/* IN6 Monochromatic beam monitor */
/*
COMPONENT BrasIN6MonoBeam = Arm()
	AT (0, 0, 0) RELATIVE IN6_MonochromatorMiddle
	ROTATED (0, IN6MonoAngle, 0) RELATIVE IN6_MonochromatorMiddle
COMPONENT Beryllium = Filter_gen(
   filename = "Be.trm",
   xwidth = 0.080, yheight = 0.140, thickness = 0.12 / 0.05   // two Be blocks: 8+4 cm
	) AT (0, 0, 1.005) RELATIVE BrasIN6MonoBeam
COMPONENT RealMonochromatic = Monitor_nD(
    xwidth = 0.030, yheight = 0.050,	  	//0.200, 
    options="lambda limits=[0.1 20.1], bins=100, per cm2, parallel")
	AT (0, 0,  IN6_LA) RELATIVE BrasIN6MonoBeam
	ROTATED (0, 0, 0) RELATIVE BrasIN6MonoBeam
*/

/* guide H15-7: 5 elements of adjusted equal lengths (different from real guide). Curvature R = 2700 m */
COMPONENT H15F7 = Al_window( thickness = Al_Thickness)	AT (0, 0, 0) RELATIVE BrasIN6MonoGap
COMPONENT GuideH15_7_1 = COPY(GuideH15_6_1)	(l = LongSegmentH15_7)
	AT (0, 0, Al_Thickness + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_7, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_7_2 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_7 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_7, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_7_3 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_7 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_7, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_7_4 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_7 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_7, 0) RELATIVE PREVIOUS
COMPONENT GuideH15_7_5 = COPY(PREVIOUS)
 	AT (0, 0, LongSegmentH15_7 + gGap) RELATIVE PREVIOUS  ROTATED (0, AngleSegmentH15_7, 0) RELATIVE PREVIOUS
COMPONENT H15F8 = Al_window( thickness = Al_Thickness)
	AT (0, 0, LongSegmentH15_7 + gGap) RELATIVE PREVIOUS

/* Gap for OT2 H15, position "G",  (D7 Mono z position) */
/*COMPONENT SplitOfGuides = Slit(
    xwidth=0.030,     yheight=0.050)
	AT (0, 0, Al_Thickness+ OT2H15_gap - gGap) RELATIVE H15F8
*/
COMPONENT BrasOT2H15 = Arm()
	AT (0, 0.075, Al_Thickness  + OT2H15_gap) RELATIVE H15F8
	ROTATED (0, AngleTotalH15_7, 0) RELATIVE BrasIN6MonoGap

/* guide H151-14: straight guide, 7m long, smaller in height (only upper part of guide). */
COMPONENT H151F1 = Al_window( thickness = Al_Thickness)
	AT (0, 0, 0) RELATIVE BrasOT2H15
/*SPLIT*/ COMPONENT GuideH151_14 = Guide_gravity(
  l = LH151_14,   w1 = 0.030, h1 = 0.050, 
  m = m_AvalVS,  R0 = gR0, Qc = gQc, alpha = gAlpha, W = gW)
	AT (0, 0, Al_Thickness) RELATIVE PREVIOUS
COMPONENT H151F2 = Al_window( thickness = Al_Thickness)
	AT (0, 0, LH151_14 + gGap) RELATIVE PREVIOUS

/* flux measurements at T3 monochromator position */
COMPONENT CaptureFluxT3Mono = Monitor_nD(
    yheight = 0.050, xwidth = 0.030, 
    options="lambda limits=[0.1 30.1], bins=300, capture per cm2, parallel"
	) 	AT (0, 0,  Al_Thickness + gGap) RELATIVE H151F2
COMPONENT RealFluxT3Mono = Monitor_nD(
    yheight = 0.050, xwidth = 0.030, 
    options="lambda limits=[0.1 30.1], bins=300, per cm2, parallel"
	) 	AT (0, 0,  Al_Thickness + 2 * gGap) RELATIVE H151F2

/* T3 Monochomator i-HOPG, at about 0.060m from end of guide  PARAMETERS TO BE CHANGED */
/*SPLIT*/ COMPONENT T3_Monochromator = Monochromator_curved(
   NH = 1, NV = 1, zwidth = 0.040, yheight = 0.020,  // individual crystals sizes
   DM     = 5.35,	// KC8
   mosaic = 4.6*60, r0 = 0.23, t0 = 1  // mosaic in arcmin, 4.6deg bad crystals MIRA 2008, r0=0.23
 	) AT (0, 0, Al_Thickness + T3Mono_gap) RELATIVE H151F2
	ROTATED (0, T3MonoAngle, 0) RELATIVE H151F2

COMPONENT BrasT3MonoBeam = Arm()
	AT (0, 0, 0) RELATIVE T3_Monochromator
	ROTATED (0, T3MonoAngle, 0) RELATIVE T3_Monochromator

/*PSD monitor before diaphragms to check beam size */
COMPONENT PSD_T3_D1x = Monitor_nD(
    yheight = 0.400, xwidth = 0.400, 
    options="x limits=[-0.15 0.15], bins=50 , parallel"
	) 	AT (0, 0, T3_MonoD1 - gGap) RELATIVE BrasT3MonoBeam
COMPONENT PSD_T3_D1y = Monitor_nD(
    yheight = 0.400, xwidth = 0.400, 
    options="y limits=[-0.15 0.15], bins= 50, parallel"
	) 	AT (0, 0, T3_MonoD1 - gGap) RELATIVE BrasT3MonoBeam

/*Two successive T3 Diaphragms */
/*SPLIT*/ COMPONENT Diaphragm_1 = Slit(
    xwidth = 1.2 / 1000,  yheight = 0.100
	) 	AT (0, 0, T3_MonoD1) RELATIVE BrasT3MonoBeam
/*SPLIT*/ COMPONENT Diaphragm_2 = Slit(
    xwidth = 0.3 / 1000,  yheight = 0.080
	) 	AT (0, 0, T3_MonoD1 + T3_D1D2) RELATIVE BrasT3MonoBeam

/* Flux measurements at T3 sample position */
COMPONENT RealFluxT3Sample = Monitor_nD(
    yheight = 0.100, xwidth = 0.00081, 
    options="lambda limits=[7.3 7.8], bins=40, parallel"
	) 	AT (0, 0, T3_MonoD1 + T3_D1D2 + T3_D2Sample) RELATIVE BrasT3MonoBeam

/* PSD monitor at detector position */
COMPONENT PSD_T3_DetectorTube = Monitor_nD(
    yheight = 0.200, xwidth = 0.025,  // Detector tube size 0.158 (v) x 0.025 (w)
    options="x limits=[-0.0125 0.0125], bins=40, y limits=[-0.1 0.1], bins= 40, parallel"
	) 	AT (0, 0,  T3_MonoD1 + T3_D1D2 + T3_D2Sample + T3_SampleDet) RELATIVE BrasT3MonoBeam

FINALLY
%{
%}
END


From pkwi at fysik.dtu.dk  Thu Jun 18 20:03:23 2020
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Thu, 18 Jun 2020 18:03:23 +0000
Subject: [mcstas-users] Inconsistent results using MPI and SPLIT
In-Reply-To: <aff3fc13-0fee-f838-7394-48ca4d42a55c@ill.fr>
References: <cd1661f5-a073-fb16-b5bf-031e693e2136@ill.fr>,
 <aff3fc13-0fee-f838-7394-48ca4d42a55c@ill.fr>
Message-ID: <DM6PR10MB3628B16F39E2D24AB9A483DCAD9B0@DM6PR10MB3628.namprd10.prod.outlook.com>

Dear Thierry,

Just a quick response for now, will have a closer look later.

One has to be quite careful with SPLIT, it is bossing, and if the statistics is not ?big enough? it will most certainly lead to bogus and unstable results. What big enough means is hard to quantify, but generally speaking one typically needs on the order of 1e5-1e6 events at the point of split at the given ncount.

I didn?t check your instrument file, but one very important detail is that SPLITS must be inserted right before components that apply Monte Carlo / random numbers, otherwise one event will simply become 10 identical and thus drive the errorbars to unphysically low values. And 5 splits (each 10) is 10^5 and sounds like a quite aggressive splitting. ?

I am sure we will find a good way to fix this, but I don?t have time this side of the weekend.

Best

Peter

Hent Outlook til iOS<https://aka.ms/o0ukef>
________________________________
Fra: mcstas-users <mcstas-users-bounces at mcstas.org> p? vegne af Thierry Bigault <bigault at ill.fr>
Sendt: torsdag, juni 18, 2020 7:03 PM
Til: McStas
Emne: [mcstas-users] Inconsistent results using MPI and SPLIT

Dear All,

I built the attached instrument file to try and simulate a reflectometer.
When I saw that I needed 10 minutes of calculation to get 3 neutrons on
my sample, I thought it was time to try and optimize.
After having a look at the manual, I first put some SPLIT keywords
positioned at 5 different components, which I estimate as strategic. I
gained a lot in statistics on the sample.
Then I decided to use the MPI feature, as my laptop has 8 cores. It
nicely reduces the computing time, at first sight it looks really great !
But the results looked strange, so I made some more systematic tests and
the result is on the attached plots. With all SPLIT commented ("no
SPLIT") it looks fine, the calculated intensity on the sample is
consistent within the error-bars, whatever the number of nodes I use.
When combining all SPLITs active and MPI ("5 SPLIT"), the calculation
time and error-bars can be strongly reduced but the result depends
completely on the number of nodes, with differences much larger than the
error-bar...
Either I did something wrong, or there is a bug somewhere. If someone
has an idea about this issue, I would be interested.
I use version 2.6.1 (May 04, 2020) on Windows 10.

Thierry





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200618/8ace731d/attachment.html>

From granrothge at ornl.gov  Thu Jun 18 20:42:34 2020
From: granrothge at ornl.gov (Granroth, Garrett)
Date: Thu, 18 Jun 2020 18:42:34 +0000
Subject: [mcstas-users] [EXTERNAL] Re: Inconsistent results using MPI
 and SPLIT
Message-ID: <8D054371-F567-4320-AF48-5A3B76742B2B@ornl.gov>

Hi Thierry,
     I took a quick look through your simulation and the wavelength range at the start is quite large especially since you are feeding it though a filter and onto a monochromator. One way to speed things up is to only feed the instrument the wavelengths you need to go through the Monochromator. I have often tied the wavelength band to be some window around the wavelength set for the Monochromator.  Then this window can be adjusted to tradeoff simulation speed for how far from the center wavelength you want to go.
If you need to check lambda/n,  specific different simulations will give you better results.  However if you need all the wavelengths at once you probably need to be running 10^8  neutrons for this wide bandwidth range.
As you discovered, the MPI feature is the only way to run lots of neutrons.  It scales well.  So if you can find 32 or 64 cores or better yet 100s or 1000s, that is the best way to go.

If you use split I would recommend using it once. Probably right after the monochromator.  However, as Peter said, you have to get enough neutrons to the split to help you.  So this may still need 10^8 at the beginning.

Best of Luck!

Garrett


Garrett E. Granroth
Instrument Scientist
Neutron Scattering Division
Oak Ridge National Laboratory
P.O. Box 2008 MS 6475
Oak Ridge TN 37831
Tel: 865-241-8241
Fax: 865-574-6080
email:granrothge at ornl.gov<mailto:granrothge at ornl.gov>



From: mcstas-users <mcstas-users-bounces at mcstas.org> on behalf of Peter Kj?r Willendrup <pkwi at fysik.dtu.dk>
Date: Thursday, June 18, 2020 at 2:08 PM
To: Thierry Bigault <bigault at ill.fr>, McStas <mcstas-users at mcstas.org>
Subject: [EXTERNAL] Re: [mcstas-users] Inconsistent results using MPI and SPLIT

Dear Thierry,

Just a quick response for now, will have a closer look later.

One has to be quite careful with SPLIT, it is bossing, and if the statistics is not ?big enough? it will most certainly lead to bogus and unstable results. What big enough means is hard to quantify, but generally speaking one typically needs on the order of 1e5-1e6 events at the point of split at the given ncount.

I didn?t check your instrument file, but one very important detail is that SPLITS must be inserted right before components that apply Monte Carlo / random numbers, otherwise one event will simply become 10 identical and thus drive the errorbars to unphysically low values. And 5 splits (each 10) is 10^5 and sounds like a quite aggressive splitting. ?

I am sure we will find a good way to fix this, but I don?t have time this side of the weekend.

Best

Peter

Hent Outlook til iOS<https://aka.ms/o0ukef>
________________________________
Fra: mcstas-users <mcstas-users-bounces at mcstas.org> p? vegne af Thierry Bigault <bigault at ill.fr>
Sendt: torsdag, juni 18, 2020 7:03 PM
Til: McStas
Emne: [mcstas-users] Inconsistent results using MPI and SPLIT

Dear All,

I built the attached instrument file to try and simulate a reflectometer.
When I saw that I needed 10 minutes of calculation to get 3 neutrons on
my sample, I thought it was time to try and optimize.
After having a look at the manual, I first put some SPLIT keywords
positioned at 5 different components, which I estimate as strategic. I
gained a lot in statistics on the sample.
Then I decided to use the MPI feature, as my laptop has 8 cores. It
nicely reduces the computing time, at first sight it looks really great !
But the results looked strange, so I made some more systematic tests and
the result is on the attached plots. With all SPLIT commented ("no
SPLIT") it looks fine, the calculated intensity on the sample is
consistent within the error-bars, whatever the number of nodes I use.
When combining all SPLITs active and MPI ("5 SPLIT"), the calculation
time and error-bars can be strongly reduced but the result depends
completely on the number of nodes, with differences much larger than the
error-bar...
Either I did something wrong, or there is a bug somewhere. If someone
has an idea about this issue, I would be interested.
I use version 2.6.1 (May 04, 2020) on Windows 10.

Thierry




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20200618/1f718935/attachment-0001.html>