Re: [fluka-discuss]: geometry access in source.f

From: Vittorio Boccone <dr.vittorio.boccone_at_ieee.org>
Date: Thu, 4 Dec 2014 23:09:50 +0100

Hi Clay,
  you have of course multiple choices to face the problem.

If the focus of your problem is the thermal load, the activation and/or the
radiation damage to the wheel then I would go for for run with the bodies
moved fly flair (or a script). Define an angle segmentation depending on
the size and dimension of your beam-spot. It's not a big issue to merge
hundreds of files from different run. Just be neat in naming the jobs and
the rest is low level scripting.

If the focus of your problem is instead several meters downstream then I
would consider the runtime geometry modification, defining an "average
wheel" or even a wheel holes much smaller than the beam such that they
reflect the same area ratio of the spinning wheel.
Best regards

Vittorio

On Thu, Dec 4, 2014 at 7:36 PM, Clay Lindsay <claylindsay_at_gmail.com> wrote:

> Hi Vittorio
>
> Thanks for your reply. The movement speed is slow compared to the
> cyclotron bunch frequency, so randomly sampling an angle for the
> spinning wheel component shouldn't be an issue. I've used flair to
> loop over discrete angles in the past, but it would be convenient to
> have a source routine which could do the same and sample more angles.
> Yes, this is exactly my thought, to couple finite element analysis
> with FLUKA to help study isotope production in liquid/gas targets.
> Though I think you are right that , that a soft coupling through flair
> with weightings should be fine.
>
> Thanks again,
>
> Clay
>
>
>
>
>
> On Wed, Dec 3, 2014 at 11:29 PM, Vittorio Boccone
> <dr.vittorio.boccone_at_ieee.org> wrote:
> > Hi Clay,
> > depending on which is the actual movement speed and the amount of steps
> you want to reproduce in your simulation it might be useful instead to run
> several simulation with different densities and positions and the merge the
> data together using the relevant weight.
> >
> > This is particularly interesting in case of evolving systems.This
> methods has been applied, for example, to simulate the effects of beam
> penetration on targets and collimators by soft-coupling FLUKA with finite
> element codes.
> >
> > Flair already allows you introduce variables and formula in the FLUKA
> files and to generate and run set of 'child jobs' with different variable
> values.
> >
> > Variable are converted to numbers before running.
> >
> > Best, V
> > Sent from my iPhone
> >
> >> On 04/dic/2014, at 00:28, Clay Lindsay <claylindsay_at_gmail.com> wrote:
> >>
> >> Hello Fluka users,
> >>
> >> I'm interested in simulating a moving component by changing geometry
> >> in a source routine. I saw another post referring to 'RSTBDY' or
> >> 'SETBDY' routines for this purpose. While this achieves the goal
> >> nicely, it would be convenient to be able to access a body's
> >> parameters inside the source routine. Does there exist a 'GETBDY'
> >> routine which returns the whats of an existing body? This way I can
> >> define a body in an input file, get those parameters in the source
> >> routine, and move the body based on pre-input position. Is there a
> >> place I could find documentation on these types of routines?
> >>
> >> Another way to do this would be the use of the transform directives.
> >> If it was possible to modify transform directives in source, it would
> >> be easy to achieve the desired motion without directly managing
> >> bodies. Are transforms (ROT-DEFIni) directives pre-computed, or can
> >> they change in source?
> >>
> >> Also I'm interested in changing materials in source. Is it possible
> >> to change a region's material, or a material's density? This would be
> >> useful in modifying input based on a metrics like energy deposition
> >> (eg. changing a gas density depending on local energy deposition).
> >>
> >> Thanks for you help,
> >>
> >> Clay Lindsay
> >>
>
Received on Fri Dec 05 2014 - 00:32:34 CET

This archive was generated by hypermail 2.3.0 : Fri Dec 05 2014 - 00:32:38 CET