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

From: Stefano Sinigardi <Stefano.Sinigardi_at_bo.infn.it>
Date: Thu, 23 Aug 2012 19:15:54 +0200

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 <sroesler_at_mail.cern.ch> 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
>> https://github.com/cenit/Fluka_Astra_tools
>> 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
>> <Stefano.Sinigardi_at_bo.infn.it> 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 Thu Aug 23 2012 - 21:13:49 CEST

This archive was generated by hypermail 2.2.0 : Thu Aug 23 2012 - 21:13:54 CEST