[mcstas-users] Fwd: Re: Fwd: Fwd: split neutron into component

Mon May 15 22:12:18 CEST 2017

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