From federicobertalot at cnea.gov.ar  Mon Apr 10 15:54:39 2017
From: federicobertalot at cnea.gov.ar (Federico M. Bertalot)
Date: Mon, 10 Apr 2017 10:54:39 -0300
Subject: [mcstas-users] Source Parallelization
Message-ID: <1541111d-a7e1-eaa8-5484-6978759bab5a@cnea.gov.ar>

Hello,

i have written my own source component, and in order to normalize the 
results i defined the weight of each neutron as:

p=1.0/mcget_ncount()

it works fine for one processor, but for more processors mcget_ncount() 
seems to return the number of neutron histories running on each 
processor, instead of the total number of neutron histories. Then, the 
normalization of the results changes with the number of processors. 
Which is the best solution to this problem?


Thank you very much,

Federico.



From pkwi at fysik.dtu.dk  Tue Apr 11 09:04:40 2017
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Tue, 11 Apr 2017 07:04:40 +0000
Subject: [mcstas-users] Source Parallelization
In-Reply-To: <1541111d-a7e1-eaa8-5484-6978759bab5a@cnea.gov.ar>
References: <1541111d-a7e1-eaa8-5484-6978759bab5a@cnea.gov.ar>
Message-ID: <9F64D887-D3E8-4A9F-82A7-FD175206583C@fysik.dtu.dk>

Dear Federico,


If I remember correctly, until after the scope of INITIALIZE, mcget_ncount() will return the total number of neutron histories.

So what we typically do in INITIALIZE is to assign some normalisation constants, including 1.0/mcget_ncount(). For an example, look at the ESS_butterfly.comp.

Alternatively, you may also simply

#ifdef USE_MPI
      /* We always repeat by the number of nodes in an MPI run */
      p /= mpi_node_count;
#endif

- example taken from Virtual_input.comp.


Best and hope this helps,

Peter


Peter Kj?r Willendrup
Senior Research Engineer, Special Advisor

DTU Physics

[cid:image001.gif at 01CCCAF1.5E6331F0]

Technical University of Denmark



[cid:image002.gif at 01CCCAF1.5E6331F0]


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>

On 10 Apr 2017, at 15:54 , Federico M. Bertalot <federicobertalot at cnea.gov.ar<mailto:federicobertalot at cnea.gov.ar>> wrote:

Hello,

i have written my own source component, and in order to normalize the results i defined the weight of each neutron as:

p=1.0/mcget_ncount()

it works fine for one processor, but for more processors mcget_ncount() seems to return the number of neutron histories running on each processor, instead of the total number of neutron histories. Then, the normalization of the results changes with the number of processors. Which is the best solution to this problem?


Thank you very much,

Federico.

_______________________________________________
mcstas-users mailing list
mcstas-users at mcstas.org<mailto:mcstas-users at mcstas.org>
http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170411/21147639/attachment.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/20170411/21147639/attachment.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/20170411/21147639/attachment-0001.gif>

From sgomez at cab.cnea.gov.ar  Fri May 12 18:31:21 2017
From: sgomez at cab.cnea.gov.ar (=?UTF-8?Q?Santiago_G=C3=B3mez?=)
Date: Fri, 12 May 2017 13:31:21 -0300
Subject: [mcstas-users] split neutron into component
Message-ID: <dde36dcc80c70bc1693fcbc8742acd5b@cab.cnea.gov.ar>

Hello

I would like to split a neutron inside component.

As far I see it is possible to split a neutron that reaches a specific 
component using the SPLIT macro before the component declaration in the 
instrument file, but it cannot be used inside de component.

I would prefer to split the neutron inside my component because if I do 
the SPLIT outside, a series of calculations already done be my 
components will be redundant (I would say more than 50% of all the 
calculation of the component).

The idea of the split is to do a variance reduction which optimizes the 
time, so for my component will be much more better to do that inside the 
component code.

Is it possible to performs it? I think that a similar issue is the 
possibility to have more than one source component in a single 
instrument file.

Best regards

-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la inteligencia al servicio del amor." Antoine de Saint-Exupery


From lefmann at nbi.ku.dk  Fri May 12 18:53:44 2017
From: lefmann at nbi.ku.dk (Kim Lefmann)
Date: Fri, 12 May 2017 18:53:44 +0200
Subject: [mcstas-users] split neutron into component
In-Reply-To: <dde36dcc80c70bc1693fcbc8742acd5b@cab.cnea.gov.ar>
References: <dde36dcc80c70bc1693fcbc8742acd5b@cab.cnea.gov.ar>
Message-ID: <5915E898.8000309@nbi.ku.dk>

Hi Santiago,

The short answer is that SPLIT is meant to function at the instrument 
level, e.g. for users that will not need to worry about programming 
components themselves.

To make a SPLIT inside a component, much more bookkeeping is needed, in 
particular for the fractional rays that would emerge in the middle of a 
component, and this has only been imagined and never implemented (Peter 
may correct me here if some test fragments exist?).

However, most of the computational work done by the simulation at 
(almost) any given point in the instrument lies in all the rays that 
were lost earlier in the simulation, e.g. in the guide system, the 
slits, the monochromator, and so on. Therefore, in most cases not much 
actual running time would be gained by an in-component SPLIT compared to 
the existing instrument-level SPLIT. This analysis is roughly what lies 
behind the fact that the in-component SPLIT has never been implemented.

best, Kim


On 05/12/2017 06:31 PM, Santiago G?mez wrote:
> Hello
>
> I would like to split a neutron inside component.
>
> As far I see it is possible to split a neutron that reaches a specific 
> component using the SPLIT macro before the component declaration in 
> the instrument file, but it cannot be used inside de component.
>
> I would prefer to split the neutron inside my component because if I 
> do the SPLIT outside, a series of calculations already done be my 
> components will be redundant (I would say more than 50% of all the 
> calculation of the component).
>
> The idea of the split is to do a variance reduction which optimizes 
> the time, so for my component will be much more better to do that 
> inside the component code.
>
> Is it possible to performs it? I think that a similar issue is the 
> possibility to have more than one source component in a single 
> instrument file.
>
> Best regards
>



From santiago.miguel.gomez at gmail.com  Fri May 12 19:37:27 2017
From: santiago.miguel.gomez at gmail.com (=?UTF-8?Q?Santiago_Miguel_G=C3=B3mez?=)
Date: Fri, 12 May 2017 14:37:27 -0300
Subject: [mcstas-users] split neutron into component
In-Reply-To: <5915E898.8000309@nbi.ku.dk>
References: <dde36dcc80c70bc1693fcbc8742acd5b@cab.cnea.gov.ar>
 <5915E898.8000309@nbi.ku.dk>
Message-ID: <CAMwZGHvfwWtnYcGiSyxmaQhfFoO=q7MaHUDu5deOgJkwJK=XUA@mail.gmail.com>

On Fri, May 12, 2017 at 1:53 PM, Kim Lefmann <lefmann at nbi.ku.dk> wrote:

> Hi Santiago,
>
> The short answer is that SPLIT is meant to function at the instrument
> level, e.g. for users that will not need to worry about programming
> components themselves.
>
> To make a SPLIT inside a component, much more bookkeeping is needed, in
> particular for the fractional rays that would emerge in the middle of a
> component, and this has only been imagined and never implemented (Peter may
> correct me here if some test fragments exist?).
>
> However, most of the computational work done by the simulation at (almost)
> any given point in the instrument lies in all the rays that were lost
> earlier in the simulation, e.g. in the guide system, the slits, the
> monochromator, and so on. Therefore, in most cases not much actual running
> time would be gained by an in-component SPLIT compared to the existing
> instrument-level SPLIT. This analysis is roughly what lies behind the fact
> that the in-component SPLIT has never been implemented.
>
> best, Kim
>
>
> On 05/12/2017 06:31 PM, Santiago G?mez wrote:
>
>> Hello
>>
>> I would like to split a neutron inside component.
>>
>> As far I see it is possible to split a neutron that reaches a specific
>> component using the SPLIT macro before the component declaration in the
>> instrument file, but it cannot be used inside de component.
>>
>> I would prefer to split the neutron inside my component because if I do
>> the SPLIT outside, a series of calculations already done be my components
>> will be redundant (I would say more than 50% of all the calculation of the
>> component).
>>
>> The idea of the split is to do a variance reduction which optimizes the
>> time, so for my component will be much more better to do that inside the
>> component code.
>>
>> Is it possible to performs it? I think that a similar issue is the
>> possibility to have more than one source component in a single instrument
>> file.
>>
>> Best regards
>>
>>
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users
>



-- 
Santiago Miguel G?mez

Si queremos un mundo de paz y de justicia hay que poner decididamente
la inteligencia
al servicio del amor. Antoine de Saint-Exupery
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170512/ece03e1e/attachment.html>

From sgomez at cab.cnea.gov.ar  Fri May 12 20:56:46 2017
From: sgomez at cab.cnea.gov.ar (=?UTF-8?Q?Santiago_G=C3=B3mez?=)
Date: Fri, 12 May 2017 15:56:46 -0300
Subject: [mcstas-users] Fwd:  split neutron into component
In-Reply-To: <CAMwZGHtCa59hirvGWVFQO2YaCpqFA=yUcSBCuO2YP-xRKXG-oA@mail.gmail.com>
References: <dde36dcc80c70bc1693fcbc8742acd5b@cab.cnea.gov.ar>
 <5915E898.8000309@nbi.ku.dk>
 <CAMwZGHvfwWtnYcGiSyxmaQhfFoO=q7MaHUDu5deOgJkwJK=XUA@mail.gmail.com>
 <CAMwZGHtCa59hirvGWVFQO2YaCpqFA=yUcSBCuO2YP-xRKXG-oA@mail.gmail.com>
Message-ID: <78345a75cb745bf2e0152278bb9aca65@cab.cnea.gov.ar>

Hello Kim, thank you for the answer.

Yes, in the case of a complex instrument with several components, an 
important source of statistical error is the lost of neutron into the 
relevant monitors.

In the case of my component, its a monochromator and there are two kind 
of statistical errors. One is related to the effective neutron which are 
impacting on the component (similar of that you mention). Other one is 
the necessary correlation between the direction and the energy inside 
the thickness of the monochromator for the Bragg diffraction.

For a given incoming direction, my component can link the source 
component to implement a variance reduction in energy, so it selects 
only the suitable energy range where bragg diffraction is possible 
(satisfying the energy-direction correlation), so I think an split in 
that point of the coding will be very effective, there are a lot of 
calculation to know the energies intervals for one incoming direction, 
and if I can do an split there, it is not necessary to do this part 
again.

Surely, an special care must be taken to split the neutron with the 
correct weights, but may be it can be done automatically by some macro 
function.. but I don't know how difficult will be to implement it if 
it's not already coded.

Regards
Santiago



> On Fri, May 12, 2017 at 1:53 PM, Kim Lefmann <lefmann at nbi.ku.dk> wrote:
> Hi Santiago,
> 
> The short answer is that SPLIT is meant to function at the instrument 
> level, e.g. for users that will not need to worry about programming 
> components themselves.
> 
> To make a SPLIT inside a component, much more bookkeeping is needed, in 
> particular for the fractional rays that would emerge in the middle of a 
> component, and this has only been imagined and never implemented (Peter 
> may correct me here if some test fragments exist?).
> 
> However, most of the computational work done by the simulation at 
> (almost) any given point in the instrument lies in all the rays that 
> were lost earlier in the simulation, e.g. in the guide system, the 
> slits, the monochromator, and so on. Therefore, in most cases not much 
> actual running time would be gained by an in-component SPLIT compared 
> to the existing instrument-level SPLIT. This analysis is roughly what 
> lies behind the fact that the in-component SPLIT has never been 
> implemented.
> 
> best, Kim
> 
> On 05/12/2017 06:31 PM, Santiago G?mez wrote:
> Hello
> 
> I would like to split a neutron inside component.
> 
> As far I see it is possible to split a neutron that reaches a specific 
> component using the SPLIT macro before the component declaration in the 
> instrument file, but it cannot be used inside de component.
> 
> I would prefer to split the neutron inside my component because if I do 
> the SPLIT outside, a series of calculations already done be my 
> components will be redundant (I would say more than 50% of all the 
> calculation of the component).
> 
> The idea of the split is to do a variance reduction which optimizes the 
> time, so for my component will be much more better to do that inside 
> the component code.
> 
> Is it possible to performs it? I think that a similar issue is the 
> possibility to have more than one source component in a single 
> instrument file.
> 
> Best regards
> 
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users [1]

--

Santiago Miguel G?mez

Si queremos un mundo de paz y de justicia hay que poner decididamente la 
inteligencia al servicio del amor. Antoine de Saint-Exupery

-- 

Santiago Miguel G?mez

Si queremos un mundo de paz y de justicia hay que poner decididamente la 
inteligencia al servicio del amor. Antoine de Saint-Exupery

-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la inteligencia al servicio del amor." Antoine de Saint-Exupery


Links:
------
[1] http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users


From erkn at fysik.dtu.dk  Sun May 14 23:48:07 2017
From: erkn at fysik.dtu.dk (Erik B Knudsen)
Date: Sun, 14 May 2017 23:48:07 +0200
Subject: [mcstas-users] Fwd: split neutron into component
In-Reply-To: <78345a75cb745bf2e0152278bb9aca65@cab.cnea.gov.ar>
References: <dde36dcc80c70bc1693fcbc8742acd5b@cab.cnea.gov.ar>
 <5915E898.8000309@nbi.ku.dk>
 <CAMwZGHvfwWtnYcGiSyxmaQhfFoO=q7MaHUDu5deOgJkwJK=XUA@mail.gmail.com>
 <CAMwZGHtCa59hirvGWVFQO2YaCpqFA=yUcSBCuO2YP-xRKXG-oA@mail.gmail.com>
 <78345a75cb745bf2e0152278bb9aca65@cab.cnea.gov.ar>
Message-ID: <171e5721-0d81-1291-4bbe-45e89818f49f@fysik.dtu.dk>

Dear Santiago,

My suggestion for accomplishing something along the lines of this is to
use the same concept as is being done for both PowderN and
Single_crystal components. (As these components are quite complex it
might not be completely obvious that this is what is going on...)

The idea is simple enough though.

1. Upon entry into the TRACE of you component you store the incoming
neutron state in some static memory location (as delcared in DECLARE for
instance)
 or at least the relevant bits of it.
2. For the first neutron entering you just do the full calculation as
you would normally, but make sure you store the relevant intermediate
results. In the case of Single_crystal this is the shortlist of
possible/probable Bragg reflections, their scattering vectors etc.
3. For each subsequent neutron you check if it is identical to the
stored one. If it is you can simply recall the earlier results and reuse
it. If it is _not_ identical recompute the results and store them. Also
store the new neutron state.

If you now put a SPLIT NN in your instrument in front of the component,
the component TRACE will see a series of identical neutrons and reuse
the intermediate results NN times.

This is more or less what you wanted - right? It is not an internal
split but in effect the same, without coding up a new complicated
infrastructure.

If anything is unclear - please to hesitate to ask.

cheers
Erik

On 12/05/17 20:56, Santiago G?mez wrote:
> Hello Kim, thank you for the answer.
> 
> Yes, in the case of a complex instrument with several components, an
> important source of statistical error is the lost of neutron into the
> relevant monitors.
> 
> In the case of my component, its a monochromator and there are two kind
> of statistical errors. One is related to the effective neutron which are
> impacting on the component (similar of that you mention). Other one is
> the necessary correlation between the direction and the energy inside
> the thickness of the monochromator for the Bragg diffraction.
> 
> For a given incoming direction, my component can link the source
> component to implement a variance reduction in energy, so it selects
> only the suitable energy range where bragg diffraction is possible
> (satisfying the energy-direction correlation), so I think an split in
> that point of the coding will be very effective, there are a lot of
> calculation to know the energies intervals for one incoming direction,
> and if I can do an split there, it is not necessary to do this part again.
> 
> Surely, an special care must be taken to split the neutron with the
> correct weights, but may be it can be done automatically by some macro
> function.. but I don't know how difficult will be to implement it if
> it's not already coded.
> 
> Regards
> Santiago
> 
> 
> 
>> On Fri, May 12, 2017 at 1:53 PM, Kim Lefmann <lefmann at nbi.ku.dk> wrote:
>> Hi Santiago,
>>
>> The short answer is that SPLIT is meant to function at the instrument
>> level, e.g. for users that will not need to worry about programming
>> components themselves.
>>
>> To make a SPLIT inside a component, much more bookkeeping is needed,
>> in particular for the fractional rays that would emerge in the middle
>> of a component, and this has only been imagined and never implemented
>> (Peter may correct me here if some test fragments exist?).
>>
>> However, most of the computational work done by the simulation at
>> (almost) any given point in the instrument lies in all the rays that
>> were lost earlier in the simulation, e.g. in the guide system, the
>> slits, the monochromator, and so on. Therefore, in most cases not much
>> actual running time would be gained by an in-component SPLIT compared
>> to the existing instrument-level SPLIT. This analysis is roughly what
>> lies behind the fact that the in-component SPLIT has never been
>> implemented.
>>
>> best, Kim
>>
>> On 05/12/2017 06:31 PM, Santiago G?mez wrote:
>> Hello
>>
>> I would like to split a neutron inside component.
>>
>> As far I see it is possible to split a neutron that reaches a specific
>> component using the SPLIT macro before the component declaration in
>> the instrument file, but it cannot be used inside de component.
>>
>> I would prefer to split the neutron inside my component because if I
>> do the SPLIT outside, a series of calculations already done be my
>> components will be redundant (I would say more than 50% of all the
>> calculation of the component).
>>
>> The idea of the split is to do a variance reduction which optimizes
>> the time, so for my component will be much more better to do that
>> inside the component code.
>>
>> Is it possible to performs it? I think that a similar issue is the
>> possibility to have more than one source component in a single
>> instrument file.
>>
>> Best regards
>>
>> _______________________________________________
>> mcstas-users mailing list
>> mcstas-users at mcstas.org
>> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users [1]
> 
> -- 
> 
> Santiago Miguel G?mez
> 
> Si queremos un mundo de paz y de justicia hay que poner decididamente la
> inteligencia al servicio del amor. Antoine de Saint-Exupery
> 

-- 
Erik Bergb?ck Knudsen, Research Engineer         | DTU | morituri
NEXMAP, DTU Fysik, DK-2800 Kgs. Lyngby, Denmark  |<>-<>|    te
phone: (+45) 2132 6655                           |<>-<>| salutant


From sgomez at cab.cnea.gov.ar  Mon May 15 19:38:20 2017
From: sgomez at cab.cnea.gov.ar (=?UTF-8?Q?Santiago_G=C3=B3mez?=)
Date: Mon, 15 May 2017 14:38:20 -0300
Subject: [mcstas-users] Fwd:  Fwd: split neutron into component
In-Reply-To: <CAMwZGHsSds5oVPyWvsLW2j4NMY83mMvXUFAAXH01TWtNNTGS0Q@mail.gmail.com>
References: <dde36dcc80c70bc1693fcbc8742acd5b@cab.cnea.gov.ar>
 <5915E898.8000309@nbi.ku.dk>
 <CAMwZGHvfwWtnYcGiSyxmaQhfFoO=q7MaHUDu5deOgJkwJK=XUA@mail.gmail.com>
 <CAMwZGHtCa59hirvGWVFQO2YaCpqFA=yUcSBCuO2YP-xRKXG-oA@mail.gmail.com>
 <78345a75cb745bf2e0152278bb9aca65@cab.cnea.gov.ar>
 <171e5721-0d81-1291-4bbe-45e89818f49f@fysik.dtu.dk>
 <CAMwZGHsSds5oVPyWvsLW2j4NMY83mMvXUFAAXH01TWtNNTGS0Q@mail.gmail.com>
Message-ID: <c231a5a5291cfc0892ce76dd7621bbc2@cab.cnea.gov.ar>

Dear Erik,

thank you for your reply, this is exactly what i needed. As far as I can 
see its a very good solution and it can be all implemented into the 
TRACE section of the component, working together with the SPLIT NN 
defined at instrument and without additional functions.

I will try to implement it now in the component and I'll tell you how is 
it working when it is ready.

Best regards
Santiago


> From: ERIK B KNUDSEN <erkn at fysik.dtu.dk>
> Date: Sun, May 14, 2017 at 6:48 PM
> Subject: Re: [mcstas-users] Fwd: split neutron into component
> To: mcstas-users at mcstas.org
> 
> Dear Santiago,
> 
> My suggestion for accomplishing something along the lines of this is to
> use the same concept as is being done for both PowderN and
> Single_crystal components. (As these components are quite complex it
> might not be completely obvious that this is what is going on...)
> 
> The idea is simple enough though.
> 
> 1. Upon entry into the TRACE of you component you store the incoming
> neutron state in some static memory location (as delcared in DECLARE 
> for
> instance)
> or at least the relevant bits of it.
> 2. For the first neutron entering you just do the full calculation as
> you would normally, but make sure you store the relevant intermediate
> results. In the case of Single_crystal this is the shortlist of
> possible/probable Bragg reflections, their scattering vectors etc.
> 3. For each subsequent neutron you check if it is identical to the
> stored one. If it is you can simply recall the earlier results and 
> reuse
> it. If it is _not_ identical recompute the results and store them. Also
> store the new neutron state.
> 
> If you now put a SPLIT NN in your instrument in front of the component,
> the component TRACE will see a series of identical neutrons and reuse
> the intermediate results NN times.
> 
> This is more or less what you wanted - right? It is not an internal
> split but in effect the same, without coding up a new complicated
> infrastructure.
> 
> If anything is unclear - please to hesitate to ask.
> 
> cheers
> Erik
> 
> On 12/05/17 20:56, Santiago G?mez wrote:
> Hello Kim, thank you for the answer.
> 
> Yes, in the case of a complex instrument with several components, an
> important source of statistical error is the lost of neutron into the
> relevant monitors.
> 
> In the case of my component, its a monochromator and there are two kind
> of statistical errors. One is related to the effective neutron which 
> are
> impacting on the component (similar of that you mention). Other one is
> the necessary correlation between the direction and the energy inside
> the thickness of the monochromator for the Bragg diffraction.
> 
> For a given incoming direction, my component can link the source
> component to implement a variance reduction in energy, so it selects
> only the suitable energy range where bragg diffraction is possible
> (satisfying the energy-direction correlation), so I think an split in
> that point of the coding will be very effective, there are a lot of
> calculation to know the energies intervals for one incoming direction,
> and if I can do an split there, it is not necessary to do this part 
> again.
> 
> Surely, an special care must be taken to split the neutron with the
> correct weights, but may be it can be done automatically by some macro
> function.. but I don't know how difficult will be to implement it if
> it's not already coded.
> 
> Regards
> Santiago
> 
> 
> 
> On Fri, May 12, 2017 at 1:53 PM, Kim Lefmann <lefmann at nbi.ku.dk> wrote:
> Hi Santiago,
> 
> The short answer is that SPLIT is meant to function at the instrument
> level, e.g. for users that will not need to worry about programming
> components themselves.
> 
> To make a SPLIT inside a component, much more bookkeeping is needed,
> in particular for the fractional rays that would emerge in the middle
> of a component, and this has only been imagined and never implemented
> (Peter may correct me here if some test fragments exist?).
> 
> However, most of the computational work done by the simulation at
> (almost) any given point in the instrument lies in all the rays that
> were lost earlier in the simulation, e.g. in the guide system, the
> slits, the monochromator, and so on. Therefore, in most cases not much
> actual running time would be gained by an in-component SPLIT compared
> to the existing instrument-level SPLIT. This analysis is roughly what
> lies behind the fact that the in-component SPLIT has never been
> implemented.
> 
> best, Kim
> 
> On 05/12/2017 06:31 PM, Santiago G?mez wrote:
> Hello
> 
> I would like to split a neutron inside component.
> 
> As far I see it is possible to split a neutron that reaches a specific
> component using the SPLIT macro before the component declaration in
> the instrument file, but it cannot be used inside de component.
> 
> I would prefer to split the neutron inside my component because if I
> do the SPLIT outside, a series of calculations already done be my
> components will be redundant (I would say more than 50% of all the
> calculation of the component).
> 
> The idea of the split is to do a variance reduction which optimizes
> the time, so for my component will be much more better to do that
> inside the component code.
> 
> Is it possible to performs it? I think that a similar issue is the
> possibility to have more than one source component in a single
> instrument file.
> 
> Best regards
> 
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users [1] [1]
> 
> --
> 
> Santiago Miguel G?mez
> 
> Si queremos un mundo de paz y de justicia hay que poner decididamente 
> la
> inteligencia al servicio del amor. Antoine de Saint-Exupery
> 
> 
> -- Erik Bergb?ck Knudsen, Research Engineer | DTU | morituri
> NEXMAP, DTU Fysik, DK-2800 Kgs. Lyngby, Denmark |<>-<>| te
> phone: (+45) 2132 6655 [2] |<>-<>| salutant
> 
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users [1]
> 
> --
> 
> Santiago Miguel G?mez
> 
> Si queremos un mundo de paz y de justicia hay que poner decididamente 
> la inteligencia al servicio del amor. Antoine de Saint-Exupery

-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la inteligencia al servicio del amor." Antoine de Saint-Exupery


Links:
------
[1] http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users
[2] tel:%28%2B45%29%202132%206655


From sgomez at cab.cnea.gov.ar  Mon May 15 22:12:18 2017
From: sgomez at cab.cnea.gov.ar (=?UTF-8?Q?Santiago_G=C3=B3mez?=)
Date: Mon, 15 May 2017 17:12:18 -0300
Subject: [mcstas-users] Fwd: Re:  Fwd:  Fwd: split neutron into component
Message-ID: <b42f38a0d6dce59643d66fb4af163477@cab.cnea.gov.ar>

Dear Erik,

I have implemented your suggestion and it is working really good.

I did one test using always 1E6 total histories (-n 1e6) with SPLIT 10 
before my component. I have compared my old component with the new one 
with the technic you have explained, and I had an speed up from 126 sec 
to 88sec for total time consumption (about 30% less time), and same 
results.

Thank you for the suggestion.

Best Regards
Santiago



-------- Original Message --------
Asunto: Re: [mcstas-users] Fwd:  Fwd: split neutron into component
Fecha: 2017-05-15 14:38
Remitente: Santiago G?mez <sgomez at cab.cnea.gov.ar>
Destinatario: mcstas-users at mcstas.org

Dear Erik,

thank you for your reply, this is exactly what i needed. As far as I can 
see its a very good solution and it can be all implemented into the 
TRACE section of the component, working together with the SPLIT NN 
defined at instrument and without additional functions.

I will try to implement it now in the component and I'll tell you how is 
it working when it is ready.

Best regards
Santiago


> From: ERIK B KNUDSEN <erkn at fysik.dtu.dk>
> Date: Sun, May 14, 2017 at 6:48 PM
> Subject: Re: [mcstas-users] Fwd: split neutron into component
> To: mcstas-users at mcstas.org
> 
> Dear Santiago,
> 
> My suggestion for accomplishing something along the lines of this is to
> use the same concept as is being done for both PowderN and
> Single_crystal components. (As these components are quite complex it
> might not be completely obvious that this is what is going on...)
> 
> The idea is simple enough though.
> 
> 1. Upon entry into the TRACE of you component you store the incoming
> neutron state in some static memory location (as delcared in DECLARE 
> for
> instance)
> or at least the relevant bits of it.
> 2. For the first neutron entering you just do the full calculation as
> you would normally, but make sure you store the relevant intermediate
> results. In the case of Single_crystal this is the shortlist of
> possible/probable Bragg reflections, their scattering vectors etc.
> 3. For each subsequent neutron you check if it is identical to the
> stored one. If it is you can simply recall the earlier results and 
> reuse
> it. If it is _not_ identical recompute the results and store them. Also
> store the new neutron state.
> 
> If you now put a SPLIT NN in your instrument in front of the component,
> the component TRACE will see a series of identical neutrons and reuse
> the intermediate results NN times.
> 
> This is more or less what you wanted - right? It is not an internal
> split but in effect the same, without coding up a new complicated
> infrastructure.
> 
> If anything is unclear - please to hesitate to ask.
> 
> cheers
> Erik
> 
> On 12/05/17 20:56, Santiago G?mez wrote:
> Hello Kim, thank you for the answer.
> 
> Yes, in the case of a complex instrument with several components, an
> important source of statistical error is the lost of neutron into the
> relevant monitors.
> 
> In the case of my component, its a monochromator and there are two kind
> of statistical errors. One is related to the effective neutron which 
> are
> impacting on the component (similar of that you mention). Other one is
> the necessary correlation between the direction and the energy inside
> the thickness of the monochromator for the Bragg diffraction.
> 
> For a given incoming direction, my component can link the source
> component to implement a variance reduction in energy, so it selects
> only the suitable energy range where bragg diffraction is possible
> (satisfying the energy-direction correlation), so I think an split in
> that point of the coding will be very effective, there are a lot of
> calculation to know the energies intervals for one incoming direction,
> and if I can do an split there, it is not necessary to do this part 
> again.
> 
> Surely, an special care must be taken to split the neutron with the
> correct weights, but may be it can be done automatically by some macro
> function.. but I don't know how difficult will be to implement it if
> it's not already coded.
> 
> Regards
> Santiago
> 
> 
> 
> On Fri, May 12, 2017 at 1:53 PM, Kim Lefmann <lefmann at nbi.ku.dk> wrote:
> Hi Santiago,
> 
> The short answer is that SPLIT is meant to function at the instrument
> level, e.g. for users that will not need to worry about programming
> components themselves.
> 
> To make a SPLIT inside a component, much more bookkeeping is needed,
> in particular for the fractional rays that would emerge in the middle
> of a component, and this has only been imagined and never implemented
> (Peter may correct me here if some test fragments exist?).
> 
> However, most of the computational work done by the simulation at
> (almost) any given point in the instrument lies in all the rays that
> were lost earlier in the simulation, e.g. in the guide system, the
> slits, the monochromator, and so on. Therefore, in most cases not much
> actual running time would be gained by an in-component SPLIT compared
> to the existing instrument-level SPLIT. This analysis is roughly what
> lies behind the fact that the in-component SPLIT has never been
> implemented.
> 
> best, Kim
> 
> On 05/12/2017 06:31 PM, Santiago G?mez wrote:
> Hello
> 
> I would like to split a neutron inside component.
> 
> As far I see it is possible to split a neutron that reaches a specific
> component using the SPLIT macro before the component declaration in
> the instrument file, but it cannot be used inside de component.
> 
> I would prefer to split the neutron inside my component because if I
> do the SPLIT outside, a series of calculations already done be my
> components will be redundant (I would say more than 50% of all the
> calculation of the component).
> 
> The idea of the split is to do a variance reduction which optimizes
> the time, so for my component will be much more better to do that
> inside the component code.
> 
> Is it possible to performs it? I think that a similar issue is the
> possibility to have more than one source component in a single
> instrument file.
> 
> Best regards
> 
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users [1] [1]
> 
> --
> 
> Santiago Miguel G?mez
> 
> Si queremos un mundo de paz y de justicia hay que poner decididamente 
> la
> inteligencia al servicio del amor. Antoine de Saint-Exupery
> 
> 
> -- Erik Bergb?ck Knudsen, Research Engineer | DTU | morituri
> NEXMAP, DTU Fysik, DK-2800 Kgs. Lyngby, Denmark |<>-<>| te
> phone: (+45) 2132 6655 [2] |<>-<>| salutant
> 
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users [1]
> 
> --
> 
> Santiago Miguel G?mez
> 
> Si queremos un mundo de paz y de justicia hay que poner decididamente 
> la inteligencia al servicio del amor. Antoine de Saint-Exupery

-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la inteligencia al servicio del amor." Antoine de Saint-Exupery


Links:
------
[1] http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users
[2] tel:%28%2B45%29%202132%206655
_______________________________________________
mcstas-users mailing list
mcstas-users at mcstas.org
http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users

-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la
inteligencia al servicio del amor." Antoine de Saint-Exupery


From pkwi at fysik.dtu.dk  Wed May 17 16:38:47 2017
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Wed, 17 May 2017 14:38:47 +0000
Subject: [mcstas-users] McStas 2.4 released!
Message-ID: <6A31D6E8-46D5-42D9-826E-3EB94E07730E@fysik.dtu.dk>

Dear all,


McStas 2.4 has been released and is ready for download via http://downloads.mcstas.org/mcstas-2.4

Highligts from the release are listed below. The full list of changes is also available at http://mcstas.org/CHANGES_McStas.


Greetings from the McStas team - hope you will enjoy this new release! :-)

Peter Willendrup


___________________

Changes in McStas v.2.4, May 17th, 2017

McStas 2.4 is the fifth release in the 2.x series and fixes various issues with McStas 2.3, plus provides important new developments.

Note that we only provide 64 bit packages now, with the exception of Debian and the Windows platform! (32bit packages for a given platform can be made available on request)

  *   Tools:
     *   From 2.4 we will default to use our new set of Python tools, developed by Jakob Garde, DTU.
        *   See the Wiki doc page<https://github.com/McStasMcXtrace/McCode/wiki/User-documentation-for-the-2017--Python-tool-set> for usage
     *   A mcgui editor with rich syntax highlighting
     *   A mcrun utility script, with a few new features wrt. the legacy perl solution.
     *   A newly developed mcplot-pyqtgraph, optically similar to the legacy mcplot solution, but with new features.
     *   A newly developed mcdisplay-webgl
        *   Fully 3D and interactive, uses your HTML5-capable browser with javascript controls
        *   Pause or resume visualisation of the neutron rays in the instrument
        *   Allows to keep already rendered rays to illustrate the full beam
        *   Visualises rays with color, scaled with particle velocity (ideal for illustrating e.g. monochromatisation)
     *   A newly developed mcdisplay-pyqtgraph, modeled after the legacy mcdisplay tool, but with various improvements
     *   The cif2hkl software from iFit (http://ifit.mccode.org<http://ifit.mccode.org/>) is provided with McStas for easy generation of reflection lists for the Single_crystal and PowderN components
  *   Components and instruments:
     *   A new set of components referred to as "Union"components, contribution by Mads Bertelsen Uni Copenhagen.
        *   Allows very rich simulation of samples and sample environment
        *   Several instrument files included to illustrate the capabilities and use
        *   See his video presentation<http://media.mcstas.org/ESS_DMSC_20161117/DMSC_talk_MBertelsen_McStas_Union.mp4>
     *   Component and Instrument documentation headers have been uniformised in preparation for a Python mcdoc.
     *   MCPL library updated to v. 1.1
     *   ESS_butterfly.comp provides a time-focusing mode ala what was available in ESS_moderator_long.
     *   ESS_butterfly_MCPL.instr implements the use of MCPL files in the ESS butterfly geometry
     *   PowderN can "flip" the d_phi focusing to "zoom" on a range of angles.
     *   New PSD_monitor_TOF that outputs a TOF signal pr. PSD pixel (single files). Used in templateNMX_TOF.instr
     *   A version of Isotropic_Sqw from the McStas 2.0 release has been imported under the name of Isotropic_Sqw_legacy, since some users reported that release being in better agreement with experiments.
     *   By the help of a Japanse user, we have identified issues with the performance of the supermirror coating option in FermiChopper.comp. We will investigate further and adress the issue over the course of 2017. Note that the component works as expected when not implementing supermirror slits.
     *   Various bugfixes and improvements across the example instruments and component library
  *   Platforms:
     *   Our macOS application bundle provides a 'miniconda' Python, including gcc, openmpi etc.
     *   Our Linux packages for RPM systems provide a 'miniconda' Python for all Python tool dependencies.
     *   Our Windows installer provides a 'miniconda' Python, including gcc.



Peter Kj?r Willendrup
Senior Research Engineer, Special Advisor

DTU Physics

[cid:image001.gif at 01CCCAF1.5E6331F0]

Technical University of Denmark



[cid:image002.gif at 01CCCAF1.5E6331F0]


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/20170517/460eb803/attachment.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/20170517/460eb803/attachment.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/20170517/460eb803/attachment-0001.gif>

From pkwi at fysik.dtu.dk  Fri May 19 09:23:46 2017
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Fri, 19 May 2017 07:23:46 +0000
Subject: [mcstas-users] McStas 2.4 released!
In-Reply-To: <6A31D6E8-46D5-42D9-826E-3EB94E07730E@fysik.dtu.dk>
References: <6A31D6E8-46D5-42D9-826E-3EB94E07730E@fysik.dtu.dk>
Message-ID: <20BC8AFC-FCA8-4D05-B7AA-AE85A672D659@fysik.dtu.dk>

Dear all,


 Three minor bugs/annoyances with 2.4 have been found, and now have fixes / workarounds:

* If you experience that your Python mcgui File->Preferences dialogue crashes (https://github.com/McStasMcXtrace/McCode/issues/470), please:
- Linux deb/rpm: Reinstall the package mcstas-tools-python-mccodelib-2.4
- MacOS / Windows: Manually replace the mccode_config.py file as described in the issue link ^

* The MCPL_output component was shipped with a silly off-by-one error that may prevent you from merging the output. (https://github.com/McStasMcXtrace/McCode/issues/475)
- Solution: Cherry-pick MCPL_output.comp via https://raw.githubusercontent.com/McStasMcXtrace/McCode/master/mcstas-comps/misc/MCPL_output.comp

* On older Ubuntu?s (14.04 tested), the dependency python3-pyqtgraph is not available (https://github.com/McStasMcXtrace/McCode/issues/471)
- Solution: Install a newer version from the 16.04 repos as described in the issue link ^


We envisage that new issues can occur over the next weeks, and aim to fix these by a minor update release.

Please report any bug found to our GitHub issue system: https://github.com/McStasMcXtrace/McCode/issues?utf8=?&q=is%3Aissue%20label%3A%22McStas%202.4%22%20


Best and happy simulating! :-)

Peter




Peter Kj?r Willendrup
Senior Research Engineer, Special Advisor

DTU Physics

[cid:image001.gif at 01CCCAF1.5E6331F0]

Technical University of Denmark



[cid:image002.gif at 01CCCAF1.5E6331F0]


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>

On 17 May 2017, at 16:38 , Peter Kj?r Willendrup <pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk>> wrote:

Dear all,


McStas 2.4 has been released and is ready for download via http://downloads.mcstas.org/mcstas-2.4

Highligts from the release are listed below. The full list of changes is also available at http://mcstas.org/CHANGES_McStas.


Greetings from the McStas team - hope you will enjoy this new release! :-)

Peter Willendrup


___________________

Changes in McStas v.2.4, May 17th, 2017

McStas 2.4 is the fifth release in the 2.x series and fixes various issues with McStas 2.3, plus provides important new developments.

Note that we only provide 64 bit packages now, with the exception of Debian and the Windows platform! (32bit packages for a given platform can be made available on request)

  *   Tools:
     *   From 2.4 we will default to use our new set of Python tools, developed by Jakob Garde, DTU.
        *   See the Wiki doc page<https://github.com/McStasMcXtrace/McCode/wiki/User-documentation-for-the-2017--Python-tool-set> for usage
     *   A mcgui editor with rich syntax highlighting
     *   A mcrun utility script, with a few new features wrt. the legacy perl solution.
     *   A newly developed mcplot-pyqtgraph, optically similar to the legacy mcplot solution, but with new features.
     *   A newly developed mcdisplay-webgl
        *   Fully 3D and interactive, uses your HTML5-capable browser with javascript controls
        *   Pause or resume visualisation of the neutron rays in the instrument
        *   Allows to keep already rendered rays to illustrate the full beam
        *   Visualises rays with color, scaled with particle velocity (ideal for illustrating e.g. monochromatisation)
     *   A newly developed mcdisplay-pyqtgraph, modeled after the legacy mcdisplay tool, but with various improvements
     *   The cif2hkl software from iFit (http://ifit.mccode.org<http://ifit.mccode.org/>) is provided with McStas for easy generation of reflection lists for the Single_crystal and PowderN components
  *   Components and instruments:
     *   A new set of components referred to as "Union"components, contribution by Mads Bertelsen Uni Copenhagen.
        *   Allows very rich simulation of samples and sample environment
        *   Several instrument files included to illustrate the capabilities and use
        *   See his video presentation<http://media.mcstas.org/ESS_DMSC_20161117/DMSC_talk_MBertelsen_McStas_Union.mp4>
     *   Component and Instrument documentation headers have been uniformised in preparation for a Python mcdoc.
     *   MCPL library updated to v. 1.1
     *   ESS_butterfly.comp provides a time-focusing mode ala what was available in ESS_moderator_long.
     *   ESS_butterfly_MCPL.instr implements the use of MCPL files in the ESS butterfly geometry
     *   PowderN can "flip" the d_phi focusing to "zoom" on a range of angles.
     *   New PSD_monitor_TOF that outputs a TOF signal pr. PSD pixel (single files). Used in templateNMX_TOF.instr
     *   A version of Isotropic_Sqw from the McStas 2.0 release has been imported under the name of Isotropic_Sqw_legacy, since some users reported that release being in better agreement with experiments.
     *   By the help of a Japanse user, we have identified issues with the performance of the supermirror coating option in FermiChopper.comp. We will investigate further and adress the issue over the course of 2017. Note that the component works as expected when not implementing supermirror slits.
     *   Various bugfixes and improvements across the example instruments and component library
  *   Platforms:
     *   Our macOS application bundle provides a 'miniconda' Python, including gcc, openmpi etc.
     *   Our Linux packages for RPM systems provide a 'miniconda' Python for all Python tool dependencies.
     *   Our Windows installer provides a 'miniconda' Python, including gcc.



Peter Kj?r Willendrup
Senior Research Engineer, Special Advisor

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/20170519/d985323c/attachment.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/20170519/d985323c/attachment.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/20170519/d985323c/attachment-0001.gif>

From iherranzupm at gmail.com  Tue May 23 12:46:15 2017
From: iherranzupm at gmail.com (=?UTF-8?Q?I=C3=B1igo_Herranz?=)
Date: Tue, 23 May 2017 12:46:15 +0200
Subject: [mcstas-users] Best way to simulate a non-symmetric guide
Message-ID: <CA+vjdxot+oD_y2WQm_ByhBtkgF+Gy4P_3fUzik44OO2CD=Djxw@mail.gmail.com>

Dear all. I am I?igo Herranz, working for the instrument MIRACLES.
We have to simulate a guide that is non-symetrically in the vertical plane,
as figure below shows.
Could anyone suggest us the best way to do it?. We are not sure whether
there is a component to do that, or you have to define a group of mirrors,
or with rotations...
We look forward to hearing from you.
In behalf of the MIRACLES team,
thank you very much.


[image: Im?genes integradas 2]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170523/26bf05db/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nonsymetricalguide.png
Type: image/png
Size: 11364 bytes
Desc: not available
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170523/26bf05db/attachment.png>

From Peter.Link at frm2.tum.de  Tue May 23 13:21:07 2017
From: Peter.Link at frm2.tum.de (Peter Link)
Date: Tue, 23 May 2017 13:21:07 +0200
Subject: [mcstas-users] Best way to simulate a non-symmetric guide
In-Reply-To: <CA+vjdxot+oD_y2WQm_ByhBtkgF+Gy4P_3fUzik44OO2CD=Djxw@mail.gmail.com>
References: <CA+vjdxot+oD_y2WQm_ByhBtkgF+Gy4P_3fUzik44OO2CD=Djxw@mail.gmail.com>
Message-ID: <4b94b6c4-fe17-920a-b138-74a040435b3e@frm2.tum.de>

Hi Inigo,

as the geometry is still rather simple, I would use the guide_anyshape 
component. You have to define a .off geometry file to describe your 
guide shape. I guess the m-values of your different mirrors aren't 
identical? The original component doesn't provide that - I have done a 
workaround, not fully tested and no warranty that it work in all cases...

Best regards,

Peter



Am 23.05.2017 um 12:46 schrieb I?igo Herranz:
>
> Dear all. I am I?igo Herranz, working for the instrument MIRACLES.
> We have to simulate a guide that is non-symetrically in the vertical 
> plane, as figure below shows.
> Could anyone suggest us the best way to do it?. We are not sure 
> whether there is a component to do that, or you have to define a group 
> of mirrors, or with rotations...
> We look forward to hearing from you.
> In behalf of the MIRACLES team,
> thank you very much.
>
>
> Im?genes integradas 2
>
>
>
>
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users

-- 
Dr. Peter Link
Leiter Neutronenoptik
Technische Universit?t M?nchen
Heinz Maier-Leibnitz Zentrum (MLZ)

Lichtenbergstr. 1
85747 Garching

Tel.: +49 (0)89 289 14622
Fax: +49 (0) 89 289 11694

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170523/42919118/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nonsymetricalguide.png
Type: image/png
Size: 11364 bytes
Desc: not available
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170523/42919118/attachment.png>
-------------- next part --------------
/*******************************************************************************
*
* McStas, neutron ray-tracing package
*         Copyright (C) 1997-2010, All rights reserved
*         Risoe National Laboratory, Roskilde, Denmark
*         Institut Laue Langevin, Grenoble, France
*
* Component: Guide
*
* %I
* Written by: Emmanuel Farhi
* Date: August 4th 2010
* Version: $Revision: 1.0$
* Origin: ILL
* Release: McStas 1.12b
*
* Reflecting surface (guide and mirror) with any shape, defined from an OFF file.
*
* %D
*
* This is a reflecting object component. Its shape is defined from an OFF file, 
* given with its file name. The object size is set as given from the file, where
* dimensions should be in meters. The bounding box may be re-scaled by specifying
* xwidth,yheight,zdepth parameters. The object may optionally be centered when
* using 'center=1'.
*
* The reflectivity is specified either from the usual parametric description 
* R0,Qc,alpha,W,m, or from a reflectivity file 'reflect' with a 2 column 
* format [q(Angs-1) R(0-1)].
*
* The complex OFF/PLY geometry option handles any closed non-convex polyhedra.
*   It supports the OFF and NOFF file format but not COFF (colored faces). 
*   Such files may be generated from XYZ data using:
*     qhull < coordinates.xyz Qx Qv Tv o > geomview.off 
*   or
*     powercrust coordinates.xyz
*   and viewed with geomview or java -jar jroff.jar (see below).
*   The default size of the object depends of the OFF file data, but its 
*   bounding box may be resized using xwidth,yheight and zdepth.
*   PLY geometry files are also supported.
*
* %BUGS
* This component does take into account gravitation accurately.
*
* %P
* INPUT PARAMETERS:
*
* geometry:(str)  Name of the OFF/PLY file describing the guide geometry
* xwidth:  (m)    Redimension the object bounding box on X axis is non-zero
* yheight: (m)    Redimension the object bounding box on Y axis is non-zero
* zdepth:  (m)    Redimension the object bounding box on Z axis is non-zero
* center:  (1)    When set to 1, the object will be centered w.r.t. the local coordinate frame
* R0:      (1)    Low-angle reflectivity
* Qc:      (AA-1) Critical scattering vector
* alpha:   (AA)   Slope of reflectivity
* m:       (1)    m-value of material. Zero means completely absorbing.
* W:       (AA-1) Width of supermirror cut-off
* m0:      (1)    m-value of material for color index 0 mirror
* m1:      (1)    m-value of material for color index 1 mirror
* m2:      (1)    m-value of material for color index 2 mirror
* m3:      (1)    m-value of material for color index 3 mirror
* PL: this is not at all elegant, should be replaced by some kind of list or table
* reflect: (str)  Reflectivity file name. Format [q(Angs-1) R(0-1)]
* transmit:(1)    When true, non reflected neutrons are transmitted through
*                 the surfaces, instead of being absorbed. No material absorption
*                 is taken into account though
*
* OUTPUT PARAMETERS:
* SCATTERED:    number of reflected events
*
* %D
* Example values: m=4 Qc=0.0219 W=1/300 alpha=6.49 R0=1
*
* %L
* <a href="http://www.geomview.org">Geomview and Object File Format (OFF)</a>
* %L
* Java version of Geomview (display only) <a href="http://www.holmes3d.net/graphics/roffview/">jroff.jar</a>
* %L
* <a href="http://qhull.org">qhull</a>
* %L
* <a href="http://www.cs.ucdavis.edu/~amenta/powercrust.html">powercrust</a>
*
* %E
*******************************************************************************/

DEFINE COMPONENT Guide_anyshape_pl
DEFINITION PARAMETERS (string reflect=0, string geometry=0)
SETTING PARAMETERS (xwidth=0, yheight=0, zdepth=0, center=0, transmit=0, 
                    R0=0.99, Qc=0.0219, alpha=3, m=0, W=0.0033, 
                     m0=-1, m1=-1, m2=-1, m3=-1)
OUTPUT PARAMETERS (pTable, offdata)
/* Neutron parameters: (x,y,z,vx,vy,vz,t,sx,sy,sz,p) */ 

SHARE
%{
%include "read_table-lib"
%include "interoff-lib"
%include "ref-lib"
%}

DECLARE
%{
  off_struct offdata;
  t_Table pTable;
%}

INITIALIZE
%{
  /* initialize OFF object from the file(s) */
  if (!off_init( geometry, xwidth, yheight, zdepth, !center, &offdata )) exit(-1);
  
  /* optionally initialize reflectivity curves */
  if (reflect && strlen(reflect) && strcmp(reflect,"NULL") && strcmp(reflect,"0")) {
    if (Table_Read(&pTable, reflect, 1) <= 0) /* read 1st block data from file into pTable */
      exit(fprintf(stderr,"Guide_anyshape: %s: can not read file %s. Aborting.\n", NAME_CURRENT_COMP, reflect));
    else 
      Table_Rebin(&pTable);         /* rebin as evenly, increasing array */
  }
    
%}

TRACE
%{
  int intersect=0;
  int counter=0;
  /* main loop for multiple reflections */
  do {
    double t0=0, t3=0, dt=0;
    unsigned long faceindex0=0, faceindex3=0, fi=0;
    Coords n0, n3, n={0,0,0};
    /* determine intersections with object; PL: get index of the intersected face */
    intersect = off_intersect(&t0, &t3, &n0, &n3, &faceindex0, &faceindex3,
       x,y,z, vx, vy, vz, offdata );
    /* get the smallest positive */
    if (t0 > 0) { dt = t0; n=n0; fi=faceindex0;}
    if (intersect > 1 && dt <= 0 && t3 > dt) { dt = t3; n=n3; fi=faceindex3;}
    /* exit loop when no intersection forward */
    if (dt <= 0 || !intersect) break;
    double nx,ny,nz;
    coords_get(n, &nx, &ny, &nz);
    
    /* test if the angle is large in case the object has an internal coating */
    double n2      = nx*nx+ny*ny+nz*nz;
    double n_dot_v = scalar_prod(vx,vy,vz,nx,ny,nz);
    double q       = 2*fabs(n_dot_v)*V2K/sqrt(n2);
    
    /* propagate neutron to reflection point */
    PROP_DT(dt); 
    
    /* handle surface intersection */
    double R=0;
    /* Reflectivity (see component Guide). */
    if (reflect && strlen(reflect) && strcmp(reflect,"NULL") && strcmp(reflect,"0"))
      TableReflecFunc(q, &pTable, &R);
    else {
      /* very crude first attempt to code up to four different m-values */
      double m_value=m;
      if (offdata.facepropsArray[fi]==0) m_value=m0;
      if (offdata.facepropsArray[fi]==1) m_value=m1;
      if (offdata.facepropsArray[fi]==2) m_value=m2;
      if (offdata.facepropsArray[fi]==3) m_value=m3;
      double par[] = {R0, Qc, alpha, m_value, W};
      StdReflecFunc(q, par, &R);
    }
    if (R > 1) {
      fprintf(stderr,"Guide_anyshape: %s: Warning: Reflectivity R=%g > 1 lowered to R=1.\n", NAME_CURRENT_COMP, R);
      R=1;
    }
    /* now handle either probability when transmit or reflect */
    if (R > 0) {
      /* when allowing transmission, we should check if indeed we reflect */
      if (!transmit || (transmit && rand01() < R)) {
        /* reflect velocity: -q -> -2*n*n.v/|n|^2 */
        if (!transmit) p *= R;
        n_dot_v *= 2/n2;
        vx -= nx*n_dot_v;
        vy -= ny*n_dot_v;
        vz -= nz*n_dot_v;
        SCATTER;
      } else {
        if (transmit) {
          p *= (1-R); /* transmitted beam has non reflected weight */
        } else ABSORB;
      }
    } else {
      /* R=0: no reflection: absorb or transmit through when allowed */
      if (!transmit) ABSORB;
    } 
    
    /* leave surface by a small amount so that next intersection is not the same one */
    PROP_DT(1e-9);
  } while (intersect && counter++<CHAR_BUF_LENGTH);
  /* end of main loop */
  
%}

MCDISPLAY
%{
  /* display the object */
  off_display(offdata);
  /* and its bounding box */
  /*
  mcdis_box(( offdata.xmin+offdata.xmax)/2,
            ( offdata.ymin+offdata.ymax)/2,
            ( offdata.zmin+offdata.zmax)/2,
            (-offdata.xmin+offdata.xmax),
            (-offdata.ymin+offdata.ymax),
            (-offdata.zmin+offdata.zmax));
  */
%}

END
-------------- next part --------------
OFF
8 4 0
-0.071 0.0   0
 0.0   0.071 0
 0.071 0.0   0
 0.0  -0.071 0
-0.071 0.0   20.0
 0.0   0.071 20.0
 0.071 0.0   20.0
 0.0  -0.071 20.0
4 0 1 5 4 0 
4 1 2 6 5 1
4 2 3 7 6 0
4 3 0 4 7 1
 
-------------- next part --------------
/*******************************************************************************
*         McStas instrument definition URL=http://www.mcstas.org
*
* Instrument: TEST 
*
* %Identification
* Written by: Peter Link (peter.link at frm2.tum.de)
* Date: 08.03.2017
* Origin: FRM II        
* Release: McStas
* Version: 2.3
* %INSTRUMENT_SITE: FRMII
*
* Instrument short description
*
* %Description
* Simulation to test Guide_anyshape 
*
* Example: mcrun test.instr <parameters=values>
*
* %Parameters
* Par1: [unit] Parameter1 description
*
* %Link
* A reference/HTML link for more information
*
* %End
*******************************************************************************/

/* Change name of instrument and input parameters with default values */
DEFINE INSTRUMENT Test()

/* The DECLARE section allows us to declare variables or  small      */
/* functions in C syntax. These may be used in the whole instrument. */
DECLARE
%{	
		
%}

/* The INITIALIZE section is executed when the simulation starts     */
/* (C code). You may use them as component parameter values.         */
INITIALIZE
%{


%}

TRACE


COMPONENT origin = Progress_bar()

  AT (0,0,0) ABSOLUTE


/*####################################################################*/
/* Source */
/*####################################################################*/


COMPONENT source = Source_gen(
		// T1=35.0, I1=9.38e12,T2=547.5,I2=2.23e12,T3=195.4,I3=1.26e13,  // "FRM2 cold" from mcstas.org
		Lmin = 2, Lmax = 9,                        // wavelength range can be adapted to optimise stats
		xwidth = 0.14, yheight= 0.21,              // SR1 neutron emitting area
		dist = 1.9,                                // focus on 1.9m
		focus_xw = 0.11, focus_yh = 0.11)          // entry of test guide + 1cm overillumination
    AT (0,0,0) RELATIVE origin  

/*    
COMPONENT testguide = Guide_gravity(
        R0 = .99, W = 0.003 ,Qc=0.02174, alpha = 6.07,  mtop=2, mbottom=2, mleft = 1.2, mright = 1.2,
        w1 = 0.1, h1 = 0.1, w2 = 0.1, h2 = 0.1, l = 20.0)
    AT (0, 0, 1.9) RELATIVE origin
    ROTATED (0,0,45) RELATIVE origin
    
*/    
/* using the original Guide_anyshape component 
COMPONENT testany = Guide_anyshape ( 
          geometry= "testguide.off",
          R0=0.99,Qc=0.02174,alpha=6.07,m=2.0,W=0.0033)
    AT (0,0,1.9) RELATIVE origin

*/


COMPONENT testany = Guide_anyshape_pl ( 
          geometry= "testguide_45deg.off",
          R0=0.99,Qc=0.02174,alpha=6.07,W=0.0033,m0=1.2,m1=2.0)
    AT (0,0,1.9) RELATIVE origin




    
/******************************************************************************/
/* Monitor section at the exit                                                */
/******************************************************************************/

COMPONENT det_arm = Arm()  
    AT (0,0,21.901) RELATIVE origin
    

COMPONENT PSD_Det1  = PSD_monitor(
		yheight = 0.15, xwidth = 0.15,
		filename = "PSD_det1", 
		nx= 150, ny = 150,
		restore_neutron = 1)
    AT (0,0, 0.0001) RELATIVE PREVIOUS

    
COMPONENT Hdiv_Det1 = Monitor_nD(xmin=-0.06, xmax=0.06, ymin=-0.060, ymax=0.060,
                                  filename="Hdivx_Det1.dat",
                                  options= "x bins=120 limits[-0.06 0.06] ; hdiv bins=40 limits[-2.0 2.0]")
  AT (0,0,0.0001) RELATIVE PREVIOUS
  ROTATED (0,0,0)  RELATIVE PREVIOUS

COMPONENT Vdiv_Det1 = Monitor_nD(xmin=-0.06, xmax=0.06, ymin=-0.06, ymax=0.06,
                                             filename="Vdivy_Det1.dat",
                                             options= "vdiv bins=40 limits[-2.0 2.0] ; y bins=120 limits[-0.06 0.06]")
  AT (0,0,0.0001) RELATIVE PREVIOUS
  ROTATED (0,0,0)  RELATIVE PREVIOUS


COMPONENT Vdivlam_Det1 = Monitor_nD(xmin=-0.06, xmax=0.06, ymin=-0.06, ymax=0.06,
                                             filename="Vdiv_det1.dat",
                                             options= "lamda wavelength bins=70 limits[2.0 9.0] ; vdiv bins=80 limits[-2.0 2.0]")
  AT (0,0,0.0001) RELATIVE PREVIOUS
  ROTATED (0,0,0)  RELATIVE PREVIOUS

COMPONENT Hdivlam_Det1 = Monitor_nD(xmin=-0.06, xmax=0.06, ymin=-0.06, ymax=0.06,
                                             filename="Hdiv_det1.dat",
                                             options= "lamda wavelength bins=70 limits[2.0 9.0] ; hdiv bins=80 limits[-2.0 2.0]")
  AT (0,0,0.0001) RELATIVE PREVIOUS
  ROTATED (0,0,0)  RELATIVE PREVIOUS


  
END
-------------- next part --------------
OFF
8 4 0
-0.05 -0.05 0
-0.05  0.05 0
 0.05  0.05 0
 0.05 -0.05 0
-0.05 -0.05 20.0
-0.05  0.05 20.0
 0.05  0.05 20.0
 0.05 -0.05 20.0
4 0 1 5 4 0 
4 1 2 6 5 1
4 2 3 7 6 0
4 3 0 4 7 1
 

From farhi at ill.fr  Thu May 25 10:39:42 2017
From: farhi at ill.fr (farhi)
Date: Thu, 25 May 2017 10:39:42 +0200
Subject: [mcstas-users] McStas question
In-Reply-To: <20170525095753.Horde.lhL2dcc6wwDPtGTT411uVXA@webmail.sic.rm.cnr.it>
References: <20170517172151.Horde.3M2UR960F85RxTLrT-mgWJC@webmail.sic.rm.cnr.it>
 <9bd79906-de3f-d768-62cb-820a3fe0777f@ill.fr>
 <20170525095753.Horde.lhL2dcc6wwDPtGTT411uVXA@webmail.sic.rm.cnr.it>
Message-ID: <fac8baef1bf33f5a2dcaaeefee06d4f9@ill.fr>

 

Hello Stefano,

it looks like the mpicc.bat is tuned to use MPICH and not OpenMPI.

Try to NOT to use 'mpicc.bat', that is put it somewhere not in the path.

Then change 'mpicc.bat' into 'mpicc' in the McStas Preferences. I think
there is an mpicc command installed by OpenMPI.

If this does not work, try changing the MPICH into the location to
OpenMPI lib and include paths in the mpicc.bat script.

Emmanuel.

Le 2017-05-25 09:57, stefano.bellissima at fi.isc.cnr.it a ?crit : 

> Dear Emmanuel,
> thanks for your help with this McStas question.
> 
> Actually, I have installed OpenMPI as you said.
> In the /Preferences panel I see the following Compilation options:
> - Compiler to use: gcc
> - MPI Compiler to use: mpicc.bat
> - MPIrun command to use: mpiexec.exe
> 
> I tried to run a file called prova_MPI.instr in this way:
> "mcrun -c --mpi=4 prova_MPI.instr"
> following an example written at pag 59 of the McStas manual,
> but it didn't work.
> Honestly, I don't know how to fix that.
> I have attached a screenshot of my desktop so that you can see the 
> type of error I have while compiling.
> Can you help me?
> 
> Many thanks
> Best regards
> Stefano Bellissima
> 
> Emmanuel FARHI <farhi at ill.fr> ha scritto:
> Hello Stefano, The simplest solution to run McStas with MPI under Windows is to install OpenMPI in addition to the C compiler (gcc) that is shipped with the McStas installer. Get it at e.g. <https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [1]>[1]. Then McStas should detect it when starting. Check the /Preferences/Configuration/ dialogue from the McStas main interface (File menu), that expects 'mpicc' and 'mpirun' to be available in the system PATH. Of course, an other solution is to switch to e.g. a Linux system. Tell me if that worked for you. Ciao, Emmanuel. On 05/17/2017 05:21 PM, stefano.bellissima at fi.isc.cnr.itwrote: Dear Emmanuel, I'm Stefano Bellissima. Probably Nando already told you that I'm working with McStas for the VESPA project here at the Cnr in Florence. Actually I'm not alone, because also Leonardo del Rosso (an ex PhD student of Lorenzo Ulivi) work with me. I'm sorry to bother you, but I have a (very simple) question to ask you about
McStas. We would like to perform multi-core simulations in our Desktop PC which has Windows 7 operating system. This machine has 8 cores. When I perform a simulation run, only one core works, while I would like to have more than one core working. I know that this is possible with McStas, but actually I don't know how. Could you help us with that? thanks best regards Stefano Bellissima and Leonardo del Rosso -- Emmanuel FARHI,www.ill.eu/computing/people/emmanuel-farhi[2] [2] |/ ____ |/ CS-Group ILL4/221, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO -@~ 71 av des Martyrs,CS 20156,38042 Grenoble Cedex 9,France /_( __/ )_ Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 48 39 06 __U_/ Link: ----- [1] https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [1] [2] http://www.ill.eu/computing/people/emmanuel-farhi [3]

-- 
FARHI Emmanuel <farhi at ill.fr>
Groupe DS/CS, ILL4/156, Tel (33) 4 76 20 71 35
ILL, Grenoble
 

Links:
------
[1]
https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe
[2] http://www.ill.eu/computing/people/emmanuel-farhi[2]
[3] http://www.ill.eu/computing/people/emmanuel-farhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170525/57d1139c/attachment.html>

From pkwi at fysik.dtu.dk  Thu May 25 11:14:44 2017
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Thu, 25 May 2017 09:14:44 +0000
Subject: [mcstas-users] McStas question
In-Reply-To: <fac8baef1bf33f5a2dcaaeefee06d4f9@ill.fr>
References: <20170517172151.Horde.3M2UR960F85RxTLrT-mgWJC@webmail.sic.rm.cnr.it>
 <9bd79906-de3f-d768-62cb-820a3fe0777f@ill.fr>
 <20170525095753.Horde.lhL2dcc6wwDPtGTT411uVXA@webmail.sic.rm.cnr.it>
 <fac8baef1bf33f5a2dcaaeefee06d4f9@ill.fr>
Message-ID: <2E223EE2178D2B9D.982FD419-F69A-4D58-B623-5B9D62D6BD0F@mail.outlook.com>

Hi both,

McStas 2.4 released very recently has an mpicc.bat set up to work with the most recent Microsoft MPI (which MPICH refer to these days). I provide binaries for that within the "extras" folder located together with the  windows installer: http://download.mcstas.org/mcstas-2.4/windows

The last time I tried openmpi with McStas on windows I had the issue that it was built with Microsoft Visual C and ended up not being binary-compatible with our default gcc compiler.

Best
Peter

F? Outlook til iOS<https://aka.ms/o0ukef>
_____________________________
From: farhi <farhi at ill.fr<mailto:farhi at ill.fr>>
Sent: torsdag, maj 25, 2017 10:39 AM
Subject: Re: [mcstas-users] McStas question
To: <stefano.bellissima at fi.isc.cnr.it<mailto:stefano.bellissima at fi.isc.cnr.it>>, McStas <mcstas-users at mcstas.org<mailto:mcstas-users at mcstas.org>>



Hello Stefano,

it looks like the mpicc.bat is tuned to use MPICH and not OpenMPI.

Try to NOT to use 'mpicc.bat', that is put it somewhere not in the path.
Then change 'mpicc.bat' into 'mpicc' in the McStas Preferences. I think there is an mpicc command installed by OpenMPI.

If this does not work, try changing the MPICH into the location to OpenMPI lib and include paths in the mpicc.bat script.

Emmanuel.

Le 2017-05-25 09:57, stefano.bellissima at fi.isc.cnr.it<mailto:stefano.bellissima at fi.isc.cnr.it> a ?crit :

Dear Emmanuel,thanks for your help with this McStas question.Actually, I have installed OpenMPI as you said.In the /Preferences panel I see the following Compilation options:- Compiler to use: gcc- MPI Compiler to use: mpicc.bat- MPIrun command to use: mpiexec.exeI tried to run a file called prova_MPI.instr in this way:"mcrun -c --mpi=4 prova_MPI.instr"following an example written at pag 59 of the McStas manual,but it didn't work.Honestly, I don't know how to fix that.I have attached a screenshot of my desktop so that you can see the  type of error I have while compiling.Can you help me?Many thanksBest regardsStefano BellissimaEmmanuel FARHI <farhi at ill.fr<mailto:farhi at ill.fr>> ha scritto:

Hello Stefano, The simplest solution to run McStas with MPI under Windows is to install OpenMPI in addition to the C compiler (gcc) that is shipped with the McStas installer. Get it at e.g. <https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe>[1]. Then McStas should detect it when starting. Check the /Preferences/Configuration/ dialogue from the McStas main interface (File menu), that expects 'mpicc' and 'mpirun' to be available in the system PATH. Of course, an other solution is to switch to e.g. a Linux system. Tell me if that worked for you. Ciao, Emmanuel. On 05/17/2017 05:21 PM, stefano.bellissima at fi.isc.cnr.it<mailto:stefano.bellissima at fi.isc.cnr.it>wrote:
Dear Emmanuel, I'm Stefano Bellissima. Probably Nando already told you that I'm working with McStas for the VESPA project here at the Cnr in Florence. Actually I'm not alone, because also Leonardo del Rosso (an ex PhD student of Lorenzo Ulivi) work with me. I'm sorry to bother you, but I have a (very simple) question to ask you about McStas. We would like to perform multi-core simulations in our Desktop PC which has Windows 7 operating system. This machine has 8 cores. When I perform a simulation run, only one core works, while I would like to have more than one core working. I know that this is possible with McStas, but actually I don't know how. Could you help us with that? thanks best regards Stefano Bellissima and Leonardo del Rosso
-- Emmanuel FARHI,www.ill.eu/computing/people/emmanuel-farhi[2]<http://www.ill.eu/computing/people/emmanuel-farhi[2]> \|/ ____ \|/ CS-Group ILL4/221, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~ 71 av des Martyrs,CS 20156,38042 Grenoble Cedex 9,France /_( \__/ )_\ Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 48 39 06 \__U_/ Link: ----- [1] https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [2] http://www.ill.eu/computing/people/emmanuel-farhi



--
FARHI Emmanuel <farhi at ill.fr<mailto:farhi at ill.fr>>Groupe DS/CS, ILL4/156, Tel (33) 4 76 20 71 35ILL, Grenoble


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

From farhi at ill.fr  Fri May 26 17:35:11 2017
From: farhi at ill.fr (farhi)
Date: Fri, 26 May 2017 17:35:11 +0200
Subject: [mcstas-users] McStas question
In-Reply-To: <20170526171116.Horde.Styj10KK3pn-QDtZkJIGcHs@webmail.sic.rm.cnr.it>
References: <20170517172151.Horde.3M2UR960F85RxTLrT-mgWJC@webmail.sic.rm.cnr.it>
 <9bd79906-de3f-d768-62cb-820a3fe0777f@ill.fr>
 <20170525095753.Horde.lhL2dcc6wwDPtGTT411uVXA@webmail.sic.rm.cnr.it>
 <fac8baef1bf33f5a2dcaaeefee06d4f9@ill.fr>
 <20170526171116.Horde.Styj10KK3pn-QDtZkJIGcHs@webmail.sic.rm.cnr.it>
Message-ID: <28d51776bd8126286444aad9f8ce99a3@ill.fr>

 

Hello Stefano,

glad you could fix the MPI installation, and now use all the CPU's. This
is much faster I guess.

The Virtual_source component is not recommended, especially when using
MPI/multicore machines. I rather use the SPLIT keyword, which actually
does the same, but without creating an intermediate file. This keyword
should be located on a component which uses random numbers, e.g.
monochromators, samples, ...

Emmanuel.

Le 2017-05-26 17:11, stefano.bellissima at fi.isc.cnr.it a ?crit : 

> Dear Emmanuel,
> thanks for the help.
> After some trials to fix the error, I didn't manage to come to a solution.
> Maybe because I was still doing something wrong.
> So I decided to install the 2.4 version and, fortunately, the error
> didn't show up anymore.
> 
> Apart from this,
> I would like to ask you another question:
> I'm using the component "Virtual Output/Input" in my .instr file of
> the VESPA spectrometer.
> I've seen that you wrote that component, so maybe you can easely
> answer my question.
> It's not clear to me if this "source" file should have a maximum size.
> Usually I generate a file of about 100 Mb containg about 1.5e6 rows
> (event), placing it at the end of my primary spectrometer, and then I
> use it as my source for the secondary spectrometer.
> When I run it under Linux on my laptop no warning show up, but when I
> run it under Windows on my pc the following warning shows up
> continuously:
> "Warning: Read_Table : source.list catenated Data has 549996 values
> that should be 50000x11".
> Actually the number 549996 is not always the same. Sometimes is
> 549999, or 549995 etc...
> So, it means that if the file contains more than 50000 rows the
> program ignores the other and "repeat" always the first 50000?
> 
> Thanks for the help,
> best regards
> 
> Stefano
> 
> farhi <farhi at ill.fr> ha scritto:
> Hello Stefano, it looks like the mpicc.bat is tuned to use MPICH and not OpenMPI. Try to NOT to use 'mpicc.bat', that is put it somewhere not in the path. Then change 'mpicc.bat' into 'mpicc' in the McStas Preferences. I think there is an mpicc command installed by OpenMPI. If this does not work, try changing the MPICH into the location to OpenMPI lib and include paths in the mpicc.bat script. Emmanuel. Le 2017-05-25 09:57, stefano.bellissima at fi.isc.cnr.ita ?crit : Dear Emmanuel, thanks for your help with this McStas question. Actually, I have installed OpenMPI as you said. In the /Preferences panel I see the following Compilation options: - Compiler to use: gcc - MPI Compiler to use: mpicc.bat - MPIrun command to use: mpiexec.exe I tried to run a file called prova_MPI.instr in this way: "mcrun -c --mpi=4 prova_MPI.instr" following an example written at pag 59 of the McStas manual, but it didn't work. Honestly, I don't know how to fix that. I have attached a screenshot of my
desktop so that you can see the type of error I have while compiling. Can you help me? Many thanks Best regards Stefano Bellissima Emmanuel FARHI <farhi at ill.fr> ha scritto: Hello Stefano, The simplest solution to run McStas with MPI under Windows is to install OpenMPI in addition to the C compiler (gcc) that is shipped with the McStas installer. Get it at e.g. <https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [1] [1]>[1]. Then McStas should detect it when starting. Check the /Preferences/Configuration/ dialogue from the McStas main interface (File menu), that expects 'mpicc' and 'mpirun' to be available in the system PATH. Of course, an other solution is to switch to e.g. a Linux system. Tell me if that worked for you. Ciao, Emmanuel. On 05/17/2017 05:21 PM, stefano.bellissima at fi.isc.cnr.itwrote: Dear Emmanuel, I'm Stefano Bellissima. Probably Nando already told you that I'm working with McStas for the VESPA project here at the Cnr in Florence. Actually
I'm not alone, because also Leonardo del Rosso (an ex PhD student of Lorenzo Ulivi) work with me. I'm sorry to bother you, but I have a (very simple) question to ask you about McStas. We would like to perform multi-core simulations in our Desktop PC which has Windows 7 operating system. This machine has 8 cores. When I perform a simulation run, only one core works, while I would like to have more than one core working. I know that this is possible with McStas, but actually I don't know how. Could you help us with that? thanks best regards Stefano Bellissima and Leonardo del Rosso -- Emmanuel FARHI,www.ill.eu/computing/people/emmanuel-farhi[2] [2] [2] |/ ____ |/ CS-Group ILL4/221, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO -@~ 71 av des Martyrs,CS 20156,38042 Grenoble Cedex 9,France /_( __/ )_ Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 48 39 06 __U_/ Link: ----- [1] https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [1] [1] [2]
http://www.ill.eu/computing/people/emmanuel-farhi [3] [3] -- FARHI Emmanuel <farhi at ill.fr> Groupe DS/CS, ILL4/156, Tel (33) 4 76 20 71 35 ILL, Grenoble Links: ------ [1] https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [1] [2] http://www.ill.eu/computing/people/emmanuel-farhi[2] [2] [3] http://www.ill.eu/computing/people/emmanuel-farhi [3]

-- 
FARHI Emmanuel <farhi at ill.fr>
Groupe DS/CS, ILL4/156, Tel (33) 4 76 20 71 35
ILL, Grenoble
 

Links:
------
[1]
https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe
[2] http://www.ill.eu/computing/people/emmanuel-farhi[2]
[3] http://www.ill.eu/computing/people/emmanuel-farhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170526/a26798bb/attachment.html>

From pkwi at fysik.dtu.dk  Fri May 26 18:27:41 2017
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Fri, 26 May 2017 16:27:41 +0000
Subject: [mcstas-users] McStas question
In-Reply-To: <28d51776bd8126286444aad9f8ce99a3@ill.fr>
References: <20170517172151.Horde.3M2UR960F85RxTLrT-mgWJC@webmail.sic.rm.cnr.it>
 <9bd79906-de3f-d768-62cb-820a3fe0777f@ill.fr>
 <20170525095753.Horde.lhL2dcc6wwDPtGTT411uVXA@webmail.sic.rm.cnr.it>
 <fac8baef1bf33f5a2dcaaeefee06d4f9@ill.fr>
 <20170526171116.Horde.Styj10KK3pn-QDtZkJIGcHs@webmail.sic.rm.cnr.it>
 <28d51776bd8126286444aad9f8ce99a3@ill.fr>
Message-ID: <2E223EE2178D2B9D.5C01C5BC-2831-445E-A874-4FA8820EA7AB@mail.outlook.com>

Hi both,

With respect to intermediate files I tend to agree with Emmanuel that SPLIT is in most cases a better choice when using MPI.

Please note however that we now support a more lightweight, binary event file format using the MCPL_output and MCPL_input components , where use of MPI can be combined with small MC choices of energy, position and divergence. (To not simply repeat every stored  neutron "blindly".)

Best
Peter Willendrup

F? Outlook til iOS<https://aka.ms/o0ukef>
_____________________________
From: farhi <farhi at ill.fr<mailto:farhi at ill.fr>>
Sent: fredag, maj 26, 2017 5:35 PM
Subject: Re: [mcstas-users] McStas question
To: <stefano.bellissima at fi.isc.cnr.it<mailto:stefano.bellissima at fi.isc.cnr.it>>
Cc: McStas <mcstas-users at mcstas.org<mailto:mcstas-users at mcstas.org>>



Hello Stefano,

glad you could fix the MPI installation, and now use all the CPU's. This is much faster I guess.

The Virtual_source component is not recommended, especially when using MPI/multicore machines. I rather use the SPLIT keyword, which actually does the same, but without creating an intermediate file. This keyword should be located on a component which uses random numbers, e.g. monochromators, samples, ...

Emmanuel.

Le 2017-05-26 17:11, stefano.bellissima at fi.isc.cnr.it<mailto:stefano.bellissima at fi.isc.cnr.it> a ?crit :

Dear Emmanuel,thanks for the help.After some trials to fix the error, I didn't manage to come to a solution.Maybe because I was still doing something wrong.So I decided to install the 2.4 version and, fortunately, the errordidn't show up anymore.Apart from this,I would like to ask you another question:I'm using the component "Virtual Output/Input" in my .instr file ofthe VESPA spectrometer.I've seen that you wrote that component, so maybe you can easelyanswer my question.It's not clear to me if this "source" file should have a maximum size.Usually I generate a file of about 100 Mb containg about 1.5e6 rows(event), placing it at the end of my primary spectrometer, and then Iuse it as my source for the secondary spectrometer.When I run it under Linux on my laptop no warning show up, but when Irun it under Windows on my pc the following warning shows upcontinuously:"Warning: Read_Table : source.list  catenated Data has 549996 valuesthat should be 50000x11".Actually the number 549996 is not always the same. Sometimes is549999, or 549995 etc...So, it means that if the file contains more than 50000 rows theprogram ignores the other and "repeat" always the first 50000?Thanks for the help,best regardsStefanofarhi <farhi at ill.fr<mailto:farhi at ill.fr>> ha scritto:

Hello Stefano, it looks like the mpicc.bat is tuned to use MPICH and not OpenMPI. Try to NOT to use 'mpicc.bat', that is put it somewhere not in the path. Then change 'mpicc.bat' into 'mpicc' in the McStas Preferences. I think there is an mpicc command installed by OpenMPI. If this does not work, try changing the MPICH into the location to OpenMPI lib and include paths in the mpicc.bat script. Emmanuel. Le 2017-05-25 09:57, stefano.bellissima at fi.isc.cnr.it<mailto:stefano.bellissima at fi.isc.cnr.it>a ?crit :
Dear Emmanuel, thanks for your help with this McStas question. Actually, I have installed OpenMPI as you said. In the /Preferences panel I see the following Compilation options: - Compiler to use: gcc - MPI Compiler to use: mpicc.bat - MPIrun command to use: mpiexec.exe I tried to run a file called prova_MPI.instr in this way: "mcrun -c --mpi=4 prova_MPI.instr" following an example written at pag 59 of the McStas manual, but it didn't work. Honestly, I don't know how to fix that. I have attached a screenshot of my desktop so that you can see the type of error I have while compiling. Can you help me? Many thanks Best regards Stefano Bellissima Emmanuel FARHI <farhi at ill.fr<mailto:farhi at ill.fr>> ha scritto: Hello Stefano, The simplest solution to run McStas with MPI under Windows is to install OpenMPI in addition to the C compiler (gcc) that is shipped with the McStas installer. Get it at e.g. <https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [1]>[1]. Then McStas should detect it when starting. Check the /Preferences/Configuration/ dialogue from the McStas main interface (File menu), that expects 'mpicc' and 'mpirun' to be available in the system PATH. Of course, an other solution is to switch to e.g. a Linux system. Tell me if that worked for you. Ciao, Emmanuel. On 05/17/2017 05:21 PM, stefano.bellissima at fi.isc.cnr.itwrote:<mailto:stefano.bellissima at fi.isc.cnr.itwrote:> Dear Emmanuel, I'm Stefano Bellissima. Probably Nando already told you that I'm working with McStas for the VESPA project here at the Cnr in Florence. Actually I'm not alone, because also Leonardo del Rosso (an ex PhD student of Lorenzo Ulivi) work with me. I'm sorry to bother you, but I have a (very simple) question to ask you about
McStas. We would like to perform multi-core simulations in our Desktop PC which has Windows 7 operating system. This machine has 8 cores. When I perform a simulation run, only one core works, while I would like to have more than one core working. I know that this is possible with McStas, but actually I don't know how. Could you help us with that? thanks best regards Stefano Bellissima and Leonardo del Rosso -- Emmanuel FARHI,www.ill.eu/computing/people/emmanuel-farhi[2]<http://www.ill.eu/computing/people/emmanuel-farhi[2]> [2] |/ ____ |/ CS-Group ILL4/221, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO -@~ 71 av des Martyrs,CS 20156,38042 Grenoble Cedex 9,France /_( __/ )_ Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 48 39 06 __U_/ Link: ----- [1] https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [1] [2] http://www.ill.eu/computing/people/emmanuel-farhi [3] -- FARHI Emmanuel <farhi at ill.fr<mailto:farhi at ill.fr>> Groupe DS/CS, ILL4/156, Tel (33) 4 76 20 71 35 ILL, Grenoble Links: ------ [1] https://www.open-mpi.org/software/ompi/v1.6/downloads/OpenMPI_v1.6-1_win64.exe [2] http://www.ill.eu/computing/people/emmanuel-farhi[2] [3] http://www.ill.eu/computing/people/emmanuel-farhi



--
FARHI Emmanuel <farhi at ill.fr<mailto:farhi at ill.fr>>Groupe DS/CS, ILL4/156, Tel (33) 4 76 20 71 35ILL, Grenoble


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

From sgomez at cab.cnea.gov.ar  Wed May 31 21:56:40 2017
From: sgomez at cab.cnea.gov.ar (=?UTF-8?Q?Santiago_G=C3=B3mez?=)
Date: Wed, 31 May 2017 16:56:40 -0300
Subject: [mcstas-users] =?utf-8?q?monitor=5FnD_renormalization?=
Message-ID: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>

Hello,

Is there any simple way to automatically renormalize the results of a 
monitor_nD component with a factor which is obtained once the simulation 
was finished?

Best Regards
Santiago


-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la
inteligencia al servicio del amor." Antoine de Saint-Exupery


From andrew.jackson at esss.se  Thu Jun  1 09:39:38 2017
From: andrew.jackson at esss.se (Andrew Jackson)
Date: Thu, 1 Jun 2017 07:39:38 +0000
Subject: [mcstas-users] monitor_nD renormalization
In-Reply-To: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>
References: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>
Message-ID: <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>

Hi

I've never found a way to do so.

I this do this by processing the mcstas output through a python script as needed. If I want it automated, I run the mcstas simulation and the Python script from a bash script.

Best
Andrew



On Wed, May 31, 2017 at 9:56 PM +0200, "Santiago G?mez" <sgomez at cab.cnea.gov.ar<mailto:sgomez at cab.cnea.gov.ar>> wrote:


Hello,

Is there any simple way to automatically renormalize the results of a
monitor_nD component with a factor which is obtained once the simulation
was finished?

Best Regards
Santiago


--
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente
la
inteligencia al servicio del amor." Antoine de Saint-Exupery
_______________________________________________
mcstas-users mailing list
mcstas-users at mcstas.org
http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users

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

From farhi at ill.fr  Thu Jun  1 10:44:48 2017
From: farhi at ill.fr (Emmanuel FARHI)
Date: Thu, 1 Jun 2017 10:44:48 +0200
Subject: [mcstas-users] monitor_nD renormalization
In-Reply-To: <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>
References: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>
 <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>
Message-ID: <2a9190b8-d5da-0d3f-44ec-ef4c0c86be20@ill.fr>

An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170601/27a4f9d5/attachment.html>

From andrew.jackson at esss.se  Thu Jun  1 11:41:00 2017
From: andrew.jackson at esss.se (Andrew Jackson)
Date: Thu, 1 Jun 2017 09:41:00 +0000
Subject: [mcstas-users] monitor_nD renormalization
In-Reply-To: <2a9190b8-d5da-0d3f-44ec-ef4c0c86be20@ill.fr>
References: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>
 <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>
 <2a9190b8-d5da-0d3f-44ec-ef4c0c86be20@ill.fr>
Message-ID: <A2759BA1-AF09-4C06-8999-8EE2A5EA76CA@esss.se>

Hi Emmanuel,

Very handy - good to know. I shall be making use of this method for sure!

Andrew
______________________________________
Andrew Jackson
Instrument Scientist - Small Angle Scattering
Deputy Head of Neutron Instruments Division
European Spallation Source, P.O Box 176, SE-221 00 Lund, Sweden
Adjunct Associate Professor (Adjungerad Lektor)
Physical Chemistry, Lund University, P.O. Box 124, SE-221 00, Lund, Sweden

Phone: +46 46 888 3015
Mobile: +46 72 179 2015
E-mail: a<mailto:andrew.jackson at esss.se>ndrew.jackson at esss.se

www.esss.se


From: mcstas-users <mcstas-users-bounces at mcstas.org> on behalf of Emmanuel FARHI <farhi at ill.fr>
Organization: Institut Laue-Langevin
Date: Thursday 1 June 2017 at 10:44
To: "mcstas-users at mcstas.org" <mcstas-users at mcstas.org>, "sgomez at cab.cnea.gov.ar" <sgomez at cab.cnea.gov.ar>
Subject: Re: [mcstas-users] monitor_nD renormalization


Hello all,



there is a way. Detector values are stored into a structure of type MCDETECTOR defined in lib/share/mccode-r.h, which can be retrieved e.g. in an instrument SAVE section. Then you can assemble an other data set to be exported as a 'normal' new monitor.

TRACE

COMPONENT blah = Monitor_nD(...)

...

SAVE %{

/* get the detector structure */

MCDETECTOR det = MC_GETPAR(blah,       detector);

/* then use any of: det.(field)

  double xmin,xmax;                   /* min max of axes */
  double ymin,ymax;
  double zmin,zmax;
  double intensity;                   /* integrated values for data block */
  double error;
  double events;
  double min;                         /* statistics for data block */
  double max;
  double mean;
  double centerX;                     /* statistics for axes */
  double halfwidthX;
  double centerY;
  double halfwidthY;
  int    rank;                        /* dimensionaly of monitor, e.g. 0 1 2 3 */

  long   m,n,p;                       /* dimensions of data block and along axes */

  double *p0, *p1, *p2;               /* pointers to saved data, NULL when freed */

*/

double new_array = malloc(sizeof(double)*det.m*det.n); /* do not free the array as it will be wrtten to disk */

double factor = 10;

for (i=0; i<det.n*det.m; i++) {

new_array[i] = det.p1[i] * factor;    /* in this example we just multiply by factor=10 */

}

/* generate new detector, with only the intensity, no sigma nor ncount per pixel */

DETECTOR_OUT_1D(title,xlabel,ylabel,

"new_signal",det.xmin,det.xmax,det.m,

NULL,&new_array[0],NULL,"filename");



DETECTOR_OUT_2D(title,xlabel,ylabel,

det.xmin,det.xmax,det.ymin,det.ymax,det.m,det.n,

NULL,&new_array[0],NULL,"filename");

%}

END



Emmanuel.


On 06/01/2017 09:39 AM, Andrew Jackson wrote:

Is there any simple way t



--

Emmanuel FARHI,www.ill.eu/computing/people/emmanuel-farhi<http://www.ill.eu/computing/people/emmanuel-farhi> \|/ ____ \|/

CS-Group ILL4/221, Institut Laue-Langevin (ILL) Grenoble  ~@-/ oO \-@~

71 av des Martyrs,CS 20156,38042 Grenoble Cedex 9,France  /_( \__/ )_\

Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 48 39 06     \__U_/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170601/4cd3ef4f/attachment.html>

From sgomez at cab.cnea.gov.ar  Thu Jun  1 17:41:48 2017
From: sgomez at cab.cnea.gov.ar (=?UTF-8?Q?Santiago_G=C3=B3mez?=)
Date: Thu, 01 Jun 2017 12:41:48 -0300
Subject: [mcstas-users] =?utf-8?q?monitor=5FnD_renormalization?=
In-Reply-To: <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>
References: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>
 <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>
Message-ID: <30c3427cc4c53dd5e3cfaf8b13459e0a@cab.cnea.gov.ar>

Dear Andrew, thank for your reply, yes at last I was thinking to do it 
in this way, modifying the output data files of monitor_nD.

Emmanuel Farhi explained an other possibility to do that in the SAVE 
part of the instrument, so i will try to implement that.

Best Regards
Santiago

On 2017-06-01 04:39, Andrew Jackson wrote:
> Hi
> 
> I've never found a way to do so.
> 
> I this do this by processing the mcstas output through a python script
> as needed. If I want it automated, I run the mcstas simulation and the
> Python script from a bash script.
> 
> Best
> Andrew
> 
> 
> 
> On Wed, May 31, 2017 at 9:56 PM +0200, "Santiago G?mez"
> <sgomez at cab.cnea.gov.ar<mailto:sgomez at cab.cnea.gov.ar>> wrote:
> 
> 
> Hello,
> 
> Is there any simple way to automatically renormalize the results of a
> monitor_nD component with a factor which is obtained once the 
> simulation
> was finished?
> 
> Best Regards
> Santiago
> 
> 
> --
> Santiago Miguel G?mez
> Departamento de F?sica de Reactores y Radiaciones
> Centro At?mico Bariloche
> Int.: 5971
> 
> "Si queremos un mundo de paz y de justicia hay que poner decididamente
> la
> inteligencia al servicio del amor." Antoine de Saint-Exupery
> _______________________________________________
> mcstas-users mailing list
> mcstas-users at mcstas.org
> http://mailman.mcstas.org/cgi-bin/mailman/listinfo/mcstas-users

-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la
inteligencia al servicio del amor." Antoine de Saint-Exupery


From sgomez at cab.cnea.gov.ar  Thu Jun  1 18:13:04 2017
From: sgomez at cab.cnea.gov.ar (=?UTF-8?Q?Santiago_G=C3=B3mez?=)
Date: Thu, 01 Jun 2017 13:13:04 -0300
Subject: [mcstas-users] =?utf-8?q?monitor=5FnD_renormalization?=
In-Reply-To: <2a9190b8-d5da-0d3f-44ec-ef4c0c86be20@ill.fr>
References: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>
 <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>
 <2a9190b8-d5da-0d3f-44ec-ef4c0c86be20@ill.fr>
Message-ID: <815c1b30b6d8a98a9b0eb4343fb6b9b1@cab.cnea.gov.ar>

Dear Emmanuel,

thank for your reply, I will try to implement that. Anyway, I have to 
renormalize all my monitor (about 10 or more), so I think the post 
processing option mentioned by Andrew is also good, I will explore which 
solution is most favorable for the way I am doing the different 
simulations.

Best Regards
Santiago

On 2017-06-01 05:44, Emmanuel FARHI wrote:
> Hello all,
> 
> there is a way. Detector values are stored into a structure of type
> MCDETECTOR defined in _lib/share/mccode-r.h_, which can be retrieved
> e.g. in an instrument SAVE section. Then you can assemble an other
> data set to be exported as a 'normal' new monitor.
> 
> TRACE
> 
> COMPONENT BLAH = Monitor_nD(...)
> 
> ...
> 
> SAVE %{
> 
> /* get the detector structure */
> 
> MCDETECTOR det = MC_GETPAR(BLAH,?????? detector);
> 
> _/* then use any of: det.(field)_
> 
> _? double xmin,xmax;?????????????????? /* min max of axes */_
> _? double ymin,ymax;_
> _? double zmin,zmax;_
> _? double intensity;?????????????????? /* integrated values for data 
> block */_
> _? double error;_
> _? double events;_
> _? double min;???????????????????????? /* statistics for data block */_
> _? double max;_
> _? double mean;_
> _? double centerX;???????????????????? /* statistics for axes */_
> _? double halfwidthX;_
> _? double centerY;_
> _? double halfwidthY;_
> _? int??? rank;??????????????????????? /* dimensionaly of monitor, e.g. 
> 0 1 2 3 */_
> 
> _? long?? m,n,p;?????????????????????? /* dimensions of data block and 
> along axes */_
> 
> _? double *p0, *p1, *p2;?????????????? /* pointers to saved data, NULL 
> when freed */_
> 
> _*/_
> 
> double NEW_ARRAY = malloc(sizeof(double)*det.m*det.n); _/* do not free 
> the array as it will be wrtten to disk */_
> 
> double factor = 10;
> 
> for (i=0; i<det.n*det.m; i++) {
> 
> NEW_ARRAY[i] = det.p1[i] * factor;??? /* in this example we just 
> multiply by factor=10 */
> 
> }
> 
> /* generate new detector, with only the intensity, no sigma nor ncount 
> per pixel */
> 
> DETECTOR_OUT_1D(title,xlabel,ylabel,
> 
> "new_signal",det.xmin,det.xmax,det.m,
> 
> NULL,&NEW_ARRAY[0],NULL,"filename");
> 
> DETECTOR_OUT_2D(title,xlabel,ylabel,
> 
> det.xmin,det.xmax,det.ymin,det.ymax,det.m,det.n,
> 
> NULL,&NEW_ARRAY[0],NULL,"filename");
> 
> %}
> 
> END
> 
> Emmanuel.
> 
> On 06/01/2017 09:39 AM, Andrew Jackson wrote:
> 
> Is there any simple way t
> 
> --
> Emmanuel FARHI,www.ill.eu/computing/people/emmanuel-farhi [1] |/ ____ 
> |/
> CS-Group ILL4/221, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO -@~
> 71 av des Martyrs,CS 20156,38042 Grenoble Cedex 9,France /_( __/ )_
> Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 48 39 06 __U_/
> 
> 
> 
> Links:
> ------
> [1] http://www.ill.eu/computing/people/emmanuel-farhi

-- 
Santiago Miguel G?mez
Departamento de F?sica de Reactores y Radiaciones
Centro At?mico Bariloche
Int.: 5971

"Si queremos un mundo de paz y de justicia hay que poner decididamente 
la
inteligencia al servicio del amor." Antoine de Saint-Exupery


From farhi at ill.fr  Thu Jun  1 22:46:46 2017
From: farhi at ill.fr (farhi)
Date: Thu, 01 Jun 2017 22:46:46 +0200
Subject: [mcstas-users] =?utf-8?q?monitor=5FnD_renormalization?=
In-Reply-To: <815c1b30b6d8a98a9b0eb4343fb6b9b1@cab.cnea.gov.ar>
References: <ca106e481d33afef23afc2c7cbe520a2@cab.cnea.gov.ar>
 <54A3E5E58388EE43.8DE24AF6-436F-450A-906F-3F22E724DEA2@mail.outlook.com>
 <2a9190b8-d5da-0d3f-44ec-ef4c0c86be20@ill.fr>
 <815c1b30b6d8a98a9b0eb4343fb6b9b1@cab.cnea.gov.ar>
Message-ID: <2359dbc01594f093960a11c64f5e46e2@ill.fr>

 

Hello Santiago,

you can also try my iFit from http://ifit.mccode.org, and proceed with:

>> a = iData('path_to_monitors');
>> renormalized = a/10;

much more complex stuff can be done. Look at the doc. You can re-export
the modified data sets in many formats.

Emmanuel.

Le 2017-06-01 18:13, Santiago G?mez a ?crit : 

> Dear Emmanuel,
> 
> thank for your reply, I will try to implement that. Anyway, I have to 
> renormalize all my monitor (about 10 or more), so I think the post 
> processing option mentioned by Andrew is also good, I will explore which 
> solution is most favorable for the way I am doing the different 
> simulations.
> 
> Best Regards
> Santiago
> 
> On 2017-06-01 05:44, Emmanuel FARHI wrote:
> 
>> Hello all, there is a way. Detector values are stored into a structure of type MCDETECTOR defined in _lib/share/mccode-r.h_, which can be retrieved e.g. in an instrument SAVE section. Then you can assemble an other data set to be exported as a 'normal' new monitor. TRACE COMPONENT BLAH = Monitor_nD(...) ... SAVE %{ /* get the detector structure */ MCDETECTOR det = MC_GETPAR(BLAH, detector); _/* then use any of: det.(field)_ _ double xmin,xmax; /* min max of axes */_ _ double ymin,ymax;_ _ double zmin,zmax;_ _ double intensity; /* integrated values for data block */_ _ double error;_ _ double events;_ _ double min; /* statistics for data block */_ _ double max;_ _ double mean;_ _ double centerX; /* statistics for axes */_ _ double halfwidthX;_ _ double centerY;_ _ double halfwidthY;_ _ int rank; /* dimensionaly of monitor, e.g. 0 1 2 3 */_ _ long m,n,p; /* dimensions of data block and along axes */_ _ double *p0, *p1, *p2; /* pointers to saved data, NULL when freed */_ _*/_ double
NEW_ARRAY = malloc(sizeof(double)*det.m*det.n); _/* do not free the array as it will be wrtten to disk */_ double factor = 10; for (i=0; i<det.n*det.m; i++) { NEW_ARRAY[i] = det.p1[i] * factor; /* in this example we just multiply by factor=10 */ } /* generate new detector, with only the intensity, no sigma nor ncount per pixel */ DETECTOR_OUT_1D(title,xlabel,ylabel, "new_signal",det.xmin,det.xmax,det.m, NULL,&NEW_ARRAY[0],NULL,"filename"); DETECTOR_OUT_2D(title,xlabel,ylabel, det.xmin,det.xmax,det.ymin,det.ymax,det.m,det.n, NULL,&NEW_ARRAY[0],NULL,"filename"); %} END Emmanuel. On 06/01/2017 09:39 AM, Andrew Jackson wrote: Is there any simple way t -- Emmanuel FARHI,www.ill.eu/computing/people/emmanuel-farhi [1] [1] |/ ____ |/ CS-Group ILL4/221, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO -@~ 71 av des Martyrs,CS 20156,38042 Grenoble Cedex 9,France /_( __/ )_ Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 48 39 06 __U_/ Links: ------ [1]
http://www.ill.eu/computing/people/emmanuel-farhi [1]

-- 
FARHI Emmanuel <farhi at ill.fr>
Groupe DS/CS, ILL4/156, Tel (33) 4 76 20 71 35
ILL, Grenoble
 

Links:
------
[1] http://www.ill.eu/computing/people/emmanuel-farhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170601/fea7d92d/attachment.html>

From alaa.falahat at gmail.com  Thu Jun  8 14:44:42 2017
From: alaa.falahat at gmail.com (Ala'a Al-Falahat)
Date: Thu, 8 Jun 2017 14:44:42 +0200
Subject: [mcstas-users] PSD monitor
Message-ID: <CAPTfGGvkXN0JZG2x_zL8oGfERzgMaF84Zqv9C657Xn1ABP_3aA@mail.gmail.com>

Dear All,


I am wondering why the sample shape does not appear in the PSD monitor
while the slit in front of the sample is active (please find instrument
file) but when I deactivate the slit in front of the sample I clearly see
the sample.


Any solutions for this matter will be appreciated
Best Regards
Alaa

---------------------------------------------------------------------------------------------------------------------------





*Institute of Applied MaterialsHelmholtz-Zentrum Berlin for Materials and
EnergyHahn-Meitner-Platz , 114109 BerlinGermany*

- Sent via Doubletick <https://doubletick.co/?ref=alaa.falahat at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170608/a2fe9eea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test (2).instr
Type: application/octet-stream
Size: 2383 bytes
Desc: not available
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170608/a2fe9eea/attachment.obj>

From boin at helmholtz-berlin.de  Thu Jun  8 15:06:41 2017
From: boin at helmholtz-berlin.de (Boin, Mirko)
Date: Thu, 8 Jun 2017 13:06:41 +0000
Subject: [mcstas-users] PSD monitor
In-Reply-To: <CAPTfGGvkXN0JZG2x_zL8oGfERzgMaF84Zqv9C657Xn1ABP_3aA@mail.gmail.com>
References: <CAPTfGGvkXN0JZG2x_zL8oGfERzgMaF84Zqv9C657Xn1ABP_3aA@mail.gmail.com>
Message-ID: <B745FD0E9218194FB55793C34227806F4581D54E@didag1>

Hi Alaa,

I believe, in your configuration the slit is simply smaller than your sample, which makes is hard to identify it on the PSD.

Best wishes,
Mirko.

From: mcstas-users [mailto:mcstas-users-bounces at mcstas.org] On Behalf Of Ala'a Al-Falahat
Sent: Thursday, June 08, 2017 2:45 PM
To: mcstas-users at mcstas.org
Subject: [mcstas-users] PSD monitor

Dear All,


I am wondering why the sample shape does not appear in the PSD monitor while the slit in front of the sample is active (please find instrument file) but when I deactivate the slit in front of the sample I clearly see the sample.


Any solutions for this matter will be appreciated
Best Regards
Alaa


---------------------------------------------------------------------------------------------------------------------------

Institute of Applied Materials
Helmholtz-Zentrum Berlin for Materials and Energy
Hahn-Meitner-Platz , 1
14109 Berlin
Germany

- Sent via Doubletick<https://doubletick.co/?ref=alaa.falahat at gmail.com>
[https://doubletick.co/pixel.jpg?sento=mcstas-users at mcstas.org&trackingid=9l6%3c04fsiw86a%3e7%5beuxh]

________________________________

Helmholtz-Zentrum Berlin f?r Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Gesch?ftsf?hrung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170608/422b287a/attachment.html>

From j.voigt at fz-juelich.de  Thu Jun  8 17:44:19 2017
From: j.voigt at fz-juelich.de (=?utf-8?B?IlZvaWd0LCBKw7ZyZyI=?=)
Date: Thu, 8 Jun 2017 15:44:19 +0000
Subject: [mcstas-users] Focusing monochromator
Message-ID: <7928D574-6A49-489F-AC5E-7329FC2B152C@fz-juelich.de>

Dear McStas users,
I would like to use a horizontally focusing monochromator with a virtual or point like source. The crystals should then be located approximately on the Rowland circle with radius L/sin(theta), while the lattice planes should be parallel to a circle  with Radius 2L/sin(theta), where L denotes the equal distance source-mono and mono-sample (symmetric Rowland configuration). Assuming a parallel incoming beam the lattice planes should be on a circle with radius 2*L/sin(theta), L being the distance between monochromator and sample, as also written in the documentation. But how can I correctly realise the case of a symmetric Rowland circle?

Thanks in advance

J?rg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4969 bytes
Desc: not available
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170608/8a6174e1/attachment.p7s>

From John.Brokx at open.ac.uk  Wed Jun 14 12:34:31 2017
From: John.Brokx at open.ac.uk (John.Brokx)
Date: Wed, 14 Jun 2017 10:34:31 +0000
Subject: [mcstas-users] Attenuation in powder sample
Message-ID: <VI1PR04MB1424982AE8E4F8D8F642564CB3C30@VI1PR04MB1424.eurprd04.prod.outlook.com>

Dear all


I am using McStas to run simulations(scans) of a powder sample for the ENGINX instrument (ISIS RAL).

The powder sample is made of an Aluminium hull filled with iron. The density of the real sample is 41 % of

solid iron and has a linear attenuation coefficient of 0.45 /cm. I am using the packing factor as explained in the McStas component manual(section on PowderN component) to reflect this.

I ran several simulations with different values of the packing factor. I started initially with a packing factor of 0.41 but it appeared that I needed a packing factor of 0.82 to get a good match with the  real measurements done on ENGINX. I suspect that the factor 2 comes from the number of atoms in the unit cell but I am not entirely sure. I am interested to understand how the packing factor relates to the attenuation and density and if there are other ways in McStas to adjust the attenuation.



Thanks

John Brokx

Open University UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman2.mcstas.org/pipermail/mcstas-users/attachments/20170614/a04dec27/attachment.html>

From pkwi at fysik.dtu.dk  Mon Jun 26 14:33:43 2017
From: pkwi at fysik.dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=)
Date: Mon, 26 Jun 2017 12:33:43 +0000
Subject: [mcstas-users] McStas 2.4.1 released!
Message-ID: <0DDF5B5A-D136-4F09-BD9A-A4290D34A88D@fysik.dtu.dk>

Dear all,


McStas 2.4.1 has been released and is ready for download via http://downloads.mcstas.org/mcstas-2.4.1

Release changes are listed below, and the full list of project changes is also available at http://mcstas.org/CHANGES_McStas.

Greetings from the McStas team - hope you will enjoy this new release! :-)

Peter Willendrup

Changes in McStas v.2.4.1, June 26th, 2017

McStas 2.4.1 is the sixth release in the 2.x series and fixes various issues with McStas 2.4, plus provides a small set of new developments.

Thanks:

  *   Thanks to all contributors of components, instruments etc.! This is what Open Source and McStas is all about!

Fixes of issues from last release:

  *   A number of issues from 2.4 were corrected, see the relevant GitHub issues for details<https://github.com/McStasMcXtrace/McCode/issues?&q=is%3Aissue%20is%3Aclosed%20label%3A%22McStas%202.4%22%20>

Tools:

  *   As for 2.4 we the default set of tools are Python-based and developed by Jakob Garde, DTU. The perl ones will stay around as a backup solution
     *   See the GitHub Wiki doc page<https://github.com/McStasMcXtrace/McCode/wiki/User-documentation-for-the-2017--Python-tool-set> for usage
     *   On Unix platforms, the perl tools are accessible by adding .pl to the wanted tool (mcgui.pl etc.)
     *   On Windows, the perl tools are accessible by adding -pl to the wanted tool (mcgui-pl etc.)
     *   BUT: Please use the Python tools and provide feedback rather that sticking with the Perl! :-)
  *   Minor feature developments:
     *   The mcrun utility script now automatically stores a copy of the instr file in the dataset output folder
     *   mcplot-pyqtgraph, mcdisplay-pyqtgraph and mcdisplay-webgl provide the --invcanvas to select white backgrounds in the plots (for now only available from the commandline!)
     *   When installed, the mcstas-clusterscripts package provides an easy way to generate SLURM or PBS cluster batchfiles. The Python mcgui allows to access these via the File -> Configuration menu.

Components and instruments:

  *   MCPL library still at v. 1.1
     *   A minor issue in MCPL_output.comp was fixed
     *   Minor updates to the ESS_butterfly_MCPL.instr, see also: https://confluence.esss.lu.se/display/MCSTAS/Using+MCPL+as+source+term+in+McStas
  *   SNS_BASIS - model of the BASIS backscattering instrument at SNS, from Niko Tsapatsaris, ESS. Further serves as test instrument for two component contributions from the same author:
     *   Spherical_Backscattering_Analyser, a spherical backscattering analyser with variable reflectivity and mosaic gaussian response.
     *   Guide_m, guide piece like the normal Guide.comp, but with independent reflectivity specification for all four mirrors.

Best regards,

Peter Willendrup

Peter Kj?r Willendrup
Senior Research Engineer, Special Advisor

DTU Physics

[cid:image001.gif at 01CCCAF1.5E6331F0]

Technical University of Denmark



[cid:image002.gif at 01CCCAF1.5E6331F0]


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/20170626/e945eeca/attachment.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/20170626/e945eeca/attachment.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/20170626/e945eeca/attachment-0001.gif>