Re: Is it possible to discard beam particles past a certain region?

From: Mina Nozar <nozarm_at_triumf.ca>
Date: Wed, 24 Aug 2011 10:18:53 -0700

Dear all,

Thank you for your responses.
Looks like setting the transport energy threshold for electrons to an energy above the beam energy will also not
transport the secondary electrons and positrons below this energy.

This must affect the secondary electron, as well as e+ and photon production as

I would have thought one could set the transport threshold for BEAMPART using the PART-THRES. I don't see BEAMPART as
an option to use in for the PART-THRES.

Francesco, is it possible to set the weight for BEAMPART in the usrmed routine? I haven't used user routines up to now
but I will look into it.

Also, I have been looking at the BEAMPART distribution using the usrbin estimator. This does give me the beam particle
distribution (electrons in my case) through the setup. And the ELECTRON distribution will show both the beam electrons
as well as secondary electrons. Correct?

As always, thank you very much,
Mina

On 11-08-24 07:57 AM, Francesco Cerutti wrote:
>
> Dear Mina,
>
>> My question is: is it possible to discard (stop) the primary beam particles (electrons) past the converter, in order
>> to speed up the processing?
>
> yes, you can implement a very thin fake region filled with low density gas downstream the converter and set there a high
> electron transport threshold via EMFCUT (you need the gas since particles cannot stop in vacuum). [This is a trick
> already discussed by Alberto, though I cannot find now the proper link].
>
> As an alternative (needed for other particles to which EMFCUT do not apply), you can selectively kill particles at a
> boundary by zeroing their weight WEE inside the usrmed routine, to be activated in connection with the downstream region
> material via MAT-PROP (SDUM=USERDIRE, see the manual as well as the thread
> http://www.fluka.org/web_archive/earchive/new-fluka-discuss/3152.html).
>
> I have then to warn you about the fact that the calculated photofission yields are affected by the issue mentioned in
> the release notes, responsible for significant underestimation especially at low photon energies
>
> Best regards
> Francesco
> **************************************************

> On 11-08-24 07:48 AM, Alberto Fasso' wrote:
> Dear Mina,
>
> yes, it is possible to stop the electrons (but all electrons, you cannot discriminate between primaries and
> secondaries)
> when they enter a given region.
> Set the electron transport cutoff very high in that region: higher than the
> beam energy. Use for this purpose the EMFCUT command with SDUM blank, and set
> WHAT(1) higher than the BEAM energy. If necessary, split one of the regions into two parts, if you want to stop the
> electrons only in one of them.
>
> Using the same command, make instead WHAT(2) about 6 MeV in all 238U regions: you don't want to stop the photons, but
> neither you want to track photons which are below the threshold for nuclear interactions (6.2 MeV for 238U).
>
> Regards,
> Alberto
> ***************************************************

> On 11-08-24 01:45 AM, sujoy_at_vecc.gov.in wrote:
> Dear Mina,
>
> In reply to ur previous mail, you can stop the electrons in the convertor by putting transport cutoff in the
> convertor
> more than the energy of the primary electron beam.

>> Hi everyone,
>>
>> I am working on a setup, producing RIB out of photo-fissions in a Uranium Carbide.
>>
>> primary beam: electrons
>> converter: to produce photons
>> target: depleted Uranium Carbide
>>
>> In order to optimize the length of the converter, I look at number of fissions in the target as a function of the
>> converter thickness (several runs with different converter thickness).
>>
>> My question is: is it possible to discard (stop) the primary beam particles (electrons) past the converter, in order
>> to speed up the processing? I looked at the DISCARD card but this card doesn't allow for setting transport thresholds
>> in a given regions or a set of regions.
>>
>> Thank you,
>> Mina
Received on Thu Aug 25 2011 - 09:27:42 CEST

This archive was generated by hypermail 2.2.0 : Thu Aug 25 2011 - 09:27:43 CEST