Bugzilla for GALPROP – Bug 44
time steps should be user-defined
Last modified: 2011-01-09 16:37:27 PST
The timestep size and number of repeats both for variable and constant steps should all be user definable. At present all the timestep parameters are fixed in in the advanced mode.
This is important since the rapid solution is not guaranteed to give correct results in all cases, and a check with short steps is very desirable.
We have found cases where the rapid solution does not conserve particles, which is a new issue under investigation. The short-step runs are OK in this regard.
A note on this has been added to the Explanatory Supplement, in the parameters section for timesteps.
(I thought this had been registered in bugs before, but cannot find it, so evidently was not).
I made start_timestep, end_timestep, timestep_factor and timestep_repeat editable in the advanced user mode. The following validation rules will be imposed:
1 <= start_timestep <= 1.0e10
1 <= end_timestep <= 1.0e4
end_timestep <= start_timestep
(end_timestep/start_timestep) <= timestep_factor <= 0.99
0 < timestep_repeat <= 1000
Additionally, all of the following:
are required to be 0, unless end_timestep <= 1.0e2.
Please check to see if these validation rules seem safe for the numerical scheme. As a reminder: validation rules in WebRun are soft, i.e., the user will always get a warning, but may choose to ignore it and execute the run anyway.
Also, a question: timestep_mode is mentioned in some parameter descriptions, but it is not specified in the galdef file, and not required by Galprop. Is this parameter obsolete?
no reason to limit timestep_repeat. for small step runs it can be 1000000 eg to get 1e8 years in 1e2 year steps
need also timestep_repeat2 (see Expl. Supp). For this check for 3D since it has not effect in 2D.
timestep_mode is not a parameter, but distinguishes the diminishing steps from the constant ones.
Thanks, got it. Will fix soon (want to wait for Igor's comment on start_timestep and leptons).
(In reply to comment #2)
> no reason to limit timestep_repeat. for small step runs it can be 1000000 eg to
> get 1e8 years in 1e2 year steps
> need also timestep_repeat2 (see Expl. Supp). For this check for 3D since it has
> not effect in 2D.
> timestep_mode is not a parameter, but distinguishes the diminishing steps from
> the constant ones.
All the parameters of the timesteps can be checked against the built in analytical test for electrons - they are mostly affected by the energy losses. The initial timestep should be 10^9 or lager, this is important to have low energy electrons correct. The timestep factor was also tested, but I do not remember its value - perhaps galdef-files that Andrey copied from the old galprop machine have the correct values. I will check.
The buit in test was in perfect agreement with the numerical solution, so if in doubts, this is the first stop to check. If it does not work, somebody might have introduced a bug later.
the main check is fast-track versus small steps. anyone can do this.
I suggest the standard fast track cf 100 years times a million steps.
It is a fact that these do not agree at all energies and positions, so
they cannot both be correct - and the small steps are the reference.
And, of course, I forgot to add that steps larger than 10^9 yr are Okay.
My interpretation of this is that at the energies where leptons have a minimum in the energy loses, the diffusion coeff. is small enough so they need more time to fill the volume. Here is an estimate:
D~(3-6) 10^28 cm^2 s^-1, t~10^9 yr ~3 10^16 s
x~sqrt(2Dt)~a few times 10^22 cm~3-6 kpc
but remember very large steps gives a meaningless solution at high energies,
so the method relies on this very wrong solution being eliminated by the small smaller steps later, which may or may not happen.
I put the requested changes in: timestep_repeat does not have an upper limit, timestep_repeat2 is editable, and start_timestep has a lower limit.
thanks, I am now testing this to make some accurate runs and see how long they take on the cluster.
Resolved. Additional discussion here: http://galprop.stanford.edu/bugs/show_bug.cgi?id=48