Re: source.f & mgdraw.f - input and output my own particles

From: Stefan Roesler <>
Date: Fri, 24 Aug 2012 14:55:04 +0200

Hi Stefano

Thanks, that's clear now. I think this is also the "easiest" way to do it.
Apart from the input cards mentioned earlier I cannot think of anything
built-in. If someone else has a suggestion, please feel free to propose...


On Thu, 23 Aug 2012, Stefano Sinigardi wrote:

> My problem is related to the fact that I need to use the particles
> that come out from fluka simulations as an input of another code.
> Because of the fact that the particles have a broad energy spectrum,
> during their drift inside the Fluka simulation, they are going to
> create a "long bunch". But Fluka is able to dump particles only at a
> certain position, collapsing my bunch on a plane. So at the moment I
> use this trick (the variable ATRACK inside the TRACKR common) to
> obtain at which time step each one passes through this particular z
> (the interface at the rear side of my target), and then using another
> small program that I wrote I just reconstruct the length of the bunch.
> I hope that it's a little more clear now, but I understand that it's
> an unusual problem.
> Thanks a lot for your appreciations
> Regards,
> Stefano
> On Thu, Aug 23, 2012 at 6:56 PM, Stefan Roesler <> wrote:
>> Hi Stefano
>> Thanks for sharing your solutions, that's always appreciated on this list!
>> Regarding your question, I am not 100% sure what you want, but did you try
>> input options TCQUENCH with a scoring or TIME-CUT that discards particles
>> outside a certain time gate?
>> Cheers
>> Stefan
>> On Wed, 22 Aug 2012, Stefano Sinigardi wrote:
>>> Dear all,
>>> I'm replying to my own email sent some time ago because finally I was
>>> able to solve my problems using source.f and mgdraw.f to read and dump
>>> the raw particles at the beginning and at the end of the simulations.
>>> In case you're interested I wanted to share my results.
>>> You can find all the code on my github repo page at
>>> Just one problem remains, that is how to obtain a dump at a certain
>>> time step, instead that at a certain interface. At the moment I'm
>>> reconstructing it using the time variable at which each particle
>>> reaches the z position and letting the quickest to drift freely while
>>> waiting for the slowest using a small routine that I've written, but
>>> it would be better if fluka could do that. If it's possible, how could
>>> I do?
>>> Best regards,
>>> Stefano
>>> On Thu, Jun 21, 2012 at 1:24 PM, Stefano Sinigardi
>>> <> wrote:
>>>> Dear Fluka experts,
>>>> I'd like to "include" fluka inside a kit of programs that we use to
>>>> simulate our beamline. To do so, I must be able to use as an input an
>>>> ASCII files which describes our protons, which structured in this way [6
>>>> columns]: x (micrometers), y, z, px (gamma*beta), py, pz, with z as the
>>>> longitudinal direction of our beam.
>>>> To do so, I tried to learn from manual and previous question in this
>>>> mailing list and I prepared the source.f attached.
>>>> In my initial tests, I'm using very small files with just 997 protons,
>>>> but this number will grow to maybe one million. So I must put just one
>>>> particle at a time on the stack. I hope that a source.f done in this way
>>>> is correct. Also, I put a START 997 scorecard in the input file.
>>>> At the end of the interaction of my protons with this small slab of
>>>> material, in which they will not be stopped when we will finalize the
>>>> thickness, I will have to obtain a similar file with the new positions
>>>> and momenta of just the protons (if not position and momenta, position,
>>>> angular direction and energy can be of course accepted, anyway the full
>>>> phase space), so I though that I have to use mgdraw.f.
>>>> I tried to write that too, and enabled through the USERDUMP scorecard.
>>>> It compiles and runs, but unfortunately it's just writing a lot of trash
>>>> on the final phase-space file. Also, I'm not sure if I'm reading my
>>>> particles correctly.
>>>> Any help will be very well appreciated.
>>>> Best regards,
>>>> Stefano
>>>> ps: i put a .txt extension at the end of the filenames attached to
>>>> prevent a problem with mimetype I got in the past. You have to rename
>>>> them and remove those .txt of course if you'd like to test them.
Received on Fri Aug 24 2012 - 18:28:16 CEST

This archive was generated by hypermail 2.2.0 : Fri Aug 24 2012 - 18:28:17 CEST