The OPAL Discussion Forum

[Matthias Toggweiler <matthias.toggweiler AT psi.ch>]

Hi John

I agree with you that there is HUGE potential to automate stuff and to 
present the end-user with a smaller set of numerical parameters. The current 
freedom is surely overwhelming. To make it clear right away: The adaptive 
algorithm I am working on is an efficiency improvement for space charge 
dominated beam simulations, and does not solve the problem with the number of 
numerical parameters. On the contrary, it decouples external and internal 
field integration in OPAL and therefore needs one parameter more. This is the 
price for the flexibility and gained speed.

But the question remains what smaller set of parameters a simulation 
framework should present. In my dream, the user could check boxes which 
effects should be modeled (external fields, space charge, boundary geometry, 
...) and choose how long he or she is willing to wait for the simulation to 
finish. Then the framework would balance the numerical parameters. This is 
somehow adaptivity on a horizontal level that balances effort between 
simulation of different effects, whereas the adaptivity I talk about is 
vertical, i.e. model one effect more efficiently. I don't know if there are 
plans (or better: money) to implement such an automatism in OPAL, but I won't 
be part of the game :-(

I doubt that everything is abstracted from you in GPT. What is possible that 
they have some more "vertical" adaptivity for effects that OPAL does not 
have, like mesh adaptivity.

You said that things are worse because the parameter choice affects 
convergence of other effects. But then you also say it can be done by hand. 
This surprises me a little...what is your algorithm to determine good 
parameters? :-)

Matthias

Am 16.05.2012 um 00:30 schrieb Power, John:

> Hi Matthias,
> 
>>> But adaptive is a very broad term, the thing that matters is which 
>>> criteria steer the adaptation and which situations can profit from it.
> 
> I think you have it exactly right.  In my opinion, the main difficulty with 
> Parmela, (and similar codes) is that the user must study the convergence of 
> many _numerical parameters_ every time a _physical parameter_ is changed.  
> This makes rf photoinjector simulations particularly time consuming.
> 
> Convergence depends on the following numerical parameters:
> *time step
> *number of macroparticles
> *distance over which the image charge calculation is turned on
> * radial space charge grid, size and number of grids
> *longitudinal space charge grid, size and number of grids
> *mesh factor, i.e. how often to apply the space charge impulse
> 
> To make matters worse, the numerical parameter affect each other.  In other 
> words, when I change the number of macroparticles the convergence of the 
> time step changes too.
> 
> Since all of this can be done by hand it surprises me that it has not been 
> automated.  
> 
> --John
> 
> 
> 
>>> -----Original Message-----
>>> From: Matthias Toggweiler [mailto:rmf7 AT m4t.ch]
>>> Sent: Sunday, May 06, 2012 5:09 PM
>>> To: Power, John
>>> Cc: opal AT lists.psi.ch
>>> Subject: Re: [Opal] Runge-Kutta
>>> 
>>> Hi John
>>> 
>>> Thanks for further infos.
>>> 
>>> You are right that adaptive time steps for external fields could be useful
>>> too. The reasons why adaptivity concerned with space charge is our first
>>> goal are:
>>> - Space charge calculation is more expensive than external field 
>>> evaluation
>>> - I chose this path in the master thesis; in my opinion adaptivity for 
>>> external
>>> fields requires a different treatment. Not necessarily less interesting, 
>>> but
>>> not doable with our current approach.
>>> 
>>> It is possible (if there is manpower for it) to extend our current 
>>> adaptivity
>>> later to include more aspects.
>>> 
>>> It is interesting that GPT has adaptive steps. But adaptive is a very 
>>> broad
>>> term, the thing that matters is which criteria steer the adaptation and 
>>> which
>>> situations can profit from it.
>>> 
>>> Matthias
>>> 
>>> Am 06.05.2012 um 18:03 schrieb "Power, John" <JP AT anl.gov>:
>>> 
>>>> Thanks to everyone for your answers.   I really appreciate the work you
>>> guys are doing here since the community is need of a modern, well-
>>> documented, well-vetted code. Please keep up the good work.
>>>> 
>>>> I should have written that I was looking for something similar to GPT
>>> (other than the price) which uses a 5th order embedded Runge-Kutta
>>> integrator with adaptive stepsize control.  Further, as a code user it is 
>>> really
>>> the adaptive timestep that I find attractive; not the integration 
>>> algorithm.
>>> Setting the initial time step is not a problem.
>>>> 
>>>> By the way, I would have thought that an adaptive timestep would be
>>> helpful in more cases than just those having to do with space charge. For
>>> instance, an adaptive step would insure that one does not "step" over a
>>> short element.
>>>> 
>>>> Cheers,
>>>> John
>>>> 
>>>> 
>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Matthias Toggweiler [mailto:matthias.toggweiler AT psi.ch]
>>>>>> Sent: Sunday, May 06, 2012 8:05 AM
>>>>>> To: Power, John
>>>>>> Cc: opal AT lists.psi.ch
>>>>>> Subject: Re: [Opal] Runge-Kutta
>>>>>> 
>>>>>> Hi John
>>>>>> 
>>>>>> My colleagues already answered most points, but to summarize and to
>>>>>> give a little bit more detail:
>>>>>> 
>>>>>> - Runge-Kutta integrator per se does not use adaptive time steps,
>>>>>> but is just an integrator of higher order available in OPAL-CYCL in
>>>>>> addition to the standard Boris-Buneman integrator.
>>>>>> 
>>>>>> - OPAL-T has only the Boris-Buneman integrator (second order
>>>>>> leapfrog-like scheme). There is no plan to add a Runge-Kutta
>>>>>> integrator here; memory requirements of RK are higher.
>>>>>> 
>>>>>> - The adaptivity in our current work deals with varying the time
>>>>>> step according to how strong space charge forces are. Simulations
>>>>>> where space charge effects are important (RF photoinjector is a
>>>>>> perfect candidate) can profit from this adaptivity a lot.
>>>>>> 
>>>>>> - Simulations where space charge is less important do not profit
>>>>>> noticeably from the variable time stepping. There, another approach
>>>>>> makes more sense. For example, a multiple-time-stepping integrator
>>>>>> in OPAL-CYCL evaluates space charge effects less often than external
>>> field effects.
>>>>>> 
>>>>>> - Not everything will be automatic: for example, you will still have
>>>>>> to set an initial time step. Nevertheless, less manual work will be
>>>>>> required to achieve better quality solutions.
>>>>>> 
>>>>>> - In my masterthesis, good results were obtained with a first
>>>>>> prototype (see scenario EGun-CTF3 in http://e-
>>>>>> collection.library.ethz.ch/eserv/eth:5175/eth-5175-01.pdf). The
>>>>>> problem there was that the time step used for space charge effects
>>>>>> dictates the time step used for external field effects. We are
>>>>>> working on an improved prototype where the integration of these two
>>> effects is less tightly coupled.
>>>>>> Our understanding how to the time step should be chosen has also
>>>>>> improved since then.
>>>>>> 
>>>>>> To conclude, I am happy that you are interested in this work and we
>>>>>> are working hard to get this going. However, as already noted, it is
>>>>>> not magic that will do everything automatically, but one step
>>>>>> towards more intelligent integration.
>>>>>> 
>>>>>> Best,
>>>>>> Matthias
>>>>>> 
>>>>>> Am 04.05.2012 um 17:55 schrieb Power, John:
>>>>>> 
>>>>>>> Dear All,
>>>>>>> 
>>>>>>> I am looking for an alternative to PARMELA so I am lurking on your
>>>>>>> list. J
>>>>>>> 
>>>>>>> I see in the user's manual that the Runge-Kutta time integrator is
>>>>>>> only
>>>>>> available in OPAL-CYCL.  Since I work mostly with RF photoinjectors,
>>>>>> and I would rather not have to set the time step manually as is done
>>>>>> in PARMELA, I wonder if there are any near term plans to add this to
>>> OPAL-T since.
>>>>>>> 
>>>>>>> cheers,
>>>>>>> John
>>>> 
>>>> _______________________________________________
>>>> Opal mailing list
>>>> Opal AT lists.psi.ch
>>>> https://lists.web.psi.ch/mailman/listinfo/opal