|Message: How to treat rapidly changing MFP due to E-field acceleration?||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
I have a package to treat propagation of conduction electrons and holes in semiconductors at very low energies (including kinematics involving the mass tensor, etc.). An issue we have had in developing this package is that the rates for processes (and hence their MFPs) are either rapidly varying functions of energy, or have energy thresholds where they step up by many orders of magnitude.
If we implement the processes "naively," and launch an electron from near rest (1e-6 eV) in an E-field, the electron takes a single giant step directly to the volume boundary, which is obviously wrong. Why? Because at rest the process cross-sections/rates are zero, so the MFPs are DBL_MAX, and Transportation wins the day.
To work around this, we did two things. First, we introduced a step-limiting process which estimates from the local electric field how far a particle might travel before gaining "too much energy". This is done in a very ad hoc way, without treating E-field variation, boundaries, or anything else complex.
Second, we make all our processes Forced (so that PostStepDoIt() is called for every process on every step). We check at the top of PostStepDoIt() whether "this" was the step-limiting process, and if it was not, we clear the interaction length accumulator and return a no-effect particleChange.
The net result is that we limit steps to a micron or less, and end up taking many thousands of them per track. This (I believe) makes our code extremely slow compared to what it should be.
My question is whether there is any better way to deal with the problem of rapidly changing cross-sections. Is there a way to interact with the field propagator directly to ask it questions like "how long would a step be to get to a new energy E?" I have my MFP functions set up so that I could find the energy at which the rate becomes 50% larger, or doubles, o whatever; if I had a way to convert that information into a path length, then I could use it as a more natural step limiter.
There must be other situations where cross-sections vary strongly with energy, or have turn-on thresholds. Is there a better technique than what I've described, either in the toolkit, or out in the user community?
-- Michael Kelsey