I noticed that warm_start is fixed to 0. Does the web run do it automatically, or is the nuclei output wrong?

it would require a previous run with output_nuclei_full=1,
which is then read in by the next run. not sure whether webrun can handle that
question for Andrey....

_________________
Andy Strong, MPE

Okay. The gamma output should be the same in any case, no?

after a warm start the propagation continues, so not necessarily unless it has already converged

_________________
Andy Strong, MPE

I am not sure I understand what you mean by nuclei output being wrong. Warm_start is not used in WebRun. Any run that calculates gamma-rays must calculate cosmic ray propagation first (at least protons and electrons) -- that's how it is set up in WebRun now.

_________________
Andrey Vladimirov
http://galprop.stanford.edu/

as long as warm start is not allowed, this is fine.
but warm start is an interesting option, eg. when making long 3D runs for stochastic sources.
If you want that then the best thing would be to get the code.

_________________
Andy Strong, MPE

Any work on this yet? I really would like to get accurate nuclei files out.

Sorry, Brandon, I did not realize that you were expecting some modifications to the service after the conversation above. I believe that everything that can be done using warm_start=1, can also be done with warm_start=0, so changing it was not on my to do list.

If you give me some details on what you want to accomplish, I am sure I will be able to help you figure out how to do it in WebRun.

Andrey

_________________
Andrey Vladimirov
http://galprop.stanford.edu/

Interesting. My impression was that without a warm start, some of the nuclei products would not be propagated, and therefore the nuclei output (at earth radius) would be inaccurate. And as Andy said, unless the gamma has converged, it will also be inaccurate. Do you mean to say that warm_start=0 on the server actually performs all the propagation correctly and that warm_start=1 is simply a time saver? That would certainly make sense... I am just used to a version where warm/not warm means the difference between accurate/inaccurate results.

You may be confusing warm_start with network_iterations. You need network_iterations=2 to get B/C accurately. But warm_start is not required to get accurate nuclear reactions network and propagation. Here is what the explanatory supplement ( http://galprop.stanford.edu/code.php?option=manual ) says:

_________________
Andrey Vladimirov
http://galprop.stanford.edu/

Oh wow. They actually accomplish the same thing, I had just overlooked network iterations and was doing things the hard way. Thanks very much.

You are welcome. Sorry I did not understand you at first, I am not familiar with the older Galprop version that you are used to.

_________________
Andrey Vladimirov
http://galprop.stanford.edu/

it would anyway be a good idea to enable the warm start.
it could well be required for small constant timesteps to get accurate results.
the rapid-solution scheme is not necessarily always reliable.

_________________
Andy Strong, MPE

Andy, why can't one just specify a small time step and run a single calculation?
Implementing warm start in webrun will take some work, because fetching and staging additional files will be necessary, and specifying the run to be used for input will take some interface surgery. I would like to avoid it if it is not necessary.

_________________
Andrey Vladimirov
http://galprop.stanford.edu/

indeed one should do that, especially now the machines are fast.
warm start would really only be required for following time-dependent runs, and can happily be left to those installing locally.
But we should really encourage the small-timestep runs. I have added something on that in the latest version of the Explanatory Supplement.
It looks like the timesteps are still fixed in Webrun even for advanced mode, could you enable changes ?

I registered this as a bug under
http://galprop.stanford.edu/bugs/show_bug.cgi?id=44


NB the small timesteps in are controlled by timestep_repeat, with e.g. start_timestep=end_timestep = 1000 (yr) and timestep_repeat = 100000. Put timestep_factor = 0.9 to terminate the run appropriately.
One can also use timestep_repeat2 (with timestep_repeat=0) but this is only available in 3D .

_________________
Andy Strong, MPE