Bug 38 - network interations should be user-definable
network interations should be user-definable
Status: REOPENED
Product: WebRun Interface
Classification: Unclassified
Component: All
unspecified
PC Linux
: --- enhancement
Assigned To: Andrey Vladimirov
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-05 06:53 PDT by Andy Strong
Modified: 2013-10-24 08:39 PDT (History)
5 users (show)

See Also:
Web Browser: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Strong 2010-11-05 06:53:11 PDT
(from forum, user tomassetti, reposted here)

In public GALPROPs, the option "network_iterations" is 1 by default.
Since some "special" channels seem not to respect the top-bottom fragmentation sequence (like 10Be->10B decay; hope it is clear what I mean),
I wonder if these "special" channels require some more iterations (2?) to be considered (and give the correct abundances).

I don't see this option in the WebRun online-interface. What's its default setting?
Why don't make it specifiable by the user?
Comment 1 Andy Strong 2010-11-05 07:03:31 PDT
to see it click on 'advanced user' and 'fixed parameters'.
You will see it is fixed to 2 which indeed covers the case you mention (probably the only one but important for B/C).
It is indeed there for the reason you mention. 2 is always enough as far as I know (though never checked in detail - would be worth trying 3 so see).
I agree it should be free (with default=2) since for some things (e.g. gamma rays) it is redundant, and sometimes it is useful to check the effect by changing it.
Comment 2 Andy Strong 2010-11-05 07:04:50 PDT
original forum posting:
http://galprop.stanford.edu/forum/viewtopic.php?f=19&t=112
Comment 3 Andy Strong 2010-11-05 07:52:02 PDT
(from forum, tomassetti)
Yes, when the user does not need >1 iterations, this option would save much cpu time on your farm.
Comment 4 Nicola Tomassetti 2010-11-05 09:35:51 PDT
Hello.
Just for the record, 
I have quickly inspected the effect of using N=3 iterations instead N=2.
In the 10Be and 10B fluxes (the most sensitive ones to N), the difference is within ~0.1% or less at few GeV/n, and vanishes at higher energies, as expected. 
(Tried with v50p under some arbitrary configuration).
Comment 5 Andy Strong 2010-11-05 09:41:05 PDT
interesting that it still has a tiny effect, wonder where it comes from (maybe just residual propagation differences from the timesteps).

NB I assume you will upgrade from 50p to the current public on or use Webrun.
Comment 6 Andrey Vladimirov 2010-11-05 12:06:12 PDT
The reason we have network_iterations fixed at =2 is that it is crucial for anything of importance one may want from a GALPROP calculation, e.g., B/C ratio. Correct me if I am wrong: the 1st iteration is necessary to calculate the production of secondary boron, and the 2nd iteration -- to calculate the propagation of secondary boron. There is a high risk that one may be tempted to save time by setting network_iterations=1, which will lead to unphysical results, so we set it to =2 to prevent these mistakes (that's what WebRun's parameter validation is all about).

If the user wishes to only calculate emission, and does not care about CR nuclei, the better way to save time is by setting max_Z=2 (or even =1?). Propagation of H and He, even with 2 iterations, will take a negligible amount of time compared to emission calculation. The only reason one may wish to use network_iterations=1 is to study the intermediate result of the propagation model. I suppose it may only be important for developers, but normal users, who want physically relevant results from GALPROP, will benefit from NOT being able to make a drastic mistake of doing only one iteration. 

For this reason, I vote to keep network_iterations fixed at =2 and add a note to the description of max_Z, explaining how to save computational time by setting it to =2 (or =1), if only emission calculation is interesting.
Comment 7 Andy Strong 2010-11-05 12:47:22 PDT
the user may want to see the effect of different iterations, even 3 as discussed above. for anything apart from B/C it has no effect so don't see the point of fixing it.
At least for the advanced user who is supposed to know what she is doing.
Comment 8 Nicola Tomassetti 2010-11-05 12:49:07 PDT
OK. 
I want just note the 2nd iteration gives only a few percent refinement in B/C (maybe more in 10Be/9Be) as it perform a real decoupling of B-Be transport equations. 
It does not really make the difference if we compare that to other assumtpions or uncertainties like cross sections or CR data themselves. Even for many purposes involving CR nuclei (e.g. spectra of primaries, heavy nuclei, integrated abundances...) it has no effect. 
In my opinion, N=2 is important only for advanced/quantitative studies involving fits to data or dedicated analysis of uncertainties.
3rd iteration seems to me unnecessary for all purposes, present and future.


(In reply to comment #6)
> The reason we have network_iterations fixed at =2 is that it is crucial for
> anything of importance one may want from a GALPROP calculation, e.g., B/C
> ratio. Correct me if I am wrong: the 1st iteration is necessary to calculate
> the production of secondary boron, and the 2nd iteration -- to calculate the
> propagation of secondary boron. There is a high risk that one may be tempted to
> save time by setting network_iterations=1, which will lead to unphysical
> results, so we set it to =2 to prevent these mistakes (that's what WebRun's
> parameter validation is all about).
> 
> If the user wishes to only calculate emission, and does not care about CR
> nuclei, the better way to save time is by setting max_Z=2 (or even =1?).
> Propagation of H and He, even with 2 iterations, will take a negligible amount
> of time compared to emission calculation. The only reason one may wish to use
> network_iterations=1 is to study the intermediate result of the propagation
> model. I suppose it may only be important for developers, but normal users, who
> want physically relevant results from GALPROP, will benefit from NOT being able
> to make a drastic mistake of doing only one iteration. 
> 
> For this reason, I vote to keep network_iterations fixed at =2 and add a note
> to the description of max_Z, explaining how to save computational time by
> setting it to =2 (or =1), if only emission calculation is interesting.
Comment 9 Andy Strong 2010-11-05 12:55:40 PDT
Re:
"Correct me if I am wrong: the 1st iteration is necessary to calculate
the production of secondary boron, and the 2nd iteration -- to calculate the
propagation of secondary boron."

no, every iteration computes both primaries and secondaries and their propagation.
It's a top-down process, one iteration is correct.

The only reason for 2 iterations is the rare case where beta-decay transforms a nucleus so it contributes via another route. Such a case is 10Be->10B,
and it the only one of any importance that I know of.
Comment 10 Nicola Tomassetti 2010-11-05 13:41:07 PDT
I don't know very well how the code works, but I see this physical meaning:

1) 1st iteration produces all the cascade (top-down cascade).
2) 2nd iteration produces a "new" 10B component (from 10Be of (1)). 
3) 3rd iteration may produce e.g. 6Li, 7Li or 7Be as new fragmentation products of this 10B component of (2). 


(In reply to comment #5)
> interesting that it still has a tiny effect, wonder where it comes from (maybe
> just residual propagation differences from the timesteps).
> 
> NB I assume you will upgrade from 50p to the current public on or use Webrun.
Comment 11 Andy Strong 2010-11-05 13:49:20 PDT
3) should already happen in the 2nd iteration since it's top-down.
At least I think so.
Comment 12 Andrey Vladimirov 2010-11-05 14:41:34 PDT
Thanks for explanations and tests! I made network_iterations editable in the advanced user mode, with the following description:

"Number of iterations of the entire nuclei fragmentation network. Use 2 if B/C important; use 1 if a few percent error on B/C is acceptable. 3rd iteration may be used to confirm convergence."

Please confirm or correct the description, after which this bug may be closed.
Comment 13 Andy Strong 2010-11-05 23:45:14 PDT
This looks fine - I think the 1-iteration error on B/C is around 10% so maybe give such a number so people don't imagine it can be ignored  - which 'few percent' might suggest.
Comment 14 Andrey Vladimirov 2010-11-06 01:30:59 PDT
Thanks, done.
Comment 15 Andrey Egorov 2013-10-22 12:34:42 PDT
Hello!
I'm not sure exactly here, but it seems to me that a significant confusion is still present between the parameters "network_iterations" and "network_iterations_compl". Firstly let's look at the Webrun interface. The parameter "network_iterations" is adjustable and described there as "Number of iterations of the entire nuclei fragmentation network. Use 2 if B/C ratio is important...". The parameter "network_iterations_compl" is fixed to 2 and described as "Number of iterations of the nuclei fragmentation entire network. Use 2 if B/C important...". Both descriptions look exactly the same, which doesn't make sense. Now let's look into the newest manual from here - http://www.mpe.mpg.de/~aws/propagate.html  It says: "network_iterations =1 number of iterations of protons (default 1 if absent)
network_iter_compl =1 number of iterations of entire network (default 1 if absent)...
Note that if network_iterations < network_iter_compl, network_iterations is increased to be equal to network_iter_compl."
This looks different from the descriptions from Webrun - first parameter seems to control protons only, the second one - all nuclei; which make more sense. Then. In real practice Webrun now seems to be executing 2 iterations for all nuclei even if network_iterations is set to 1. It's very understandable due to the rule "Note that if network_iterations < network_iter_compl, network_iterations is increased to be equal to network_iter_compl", because network_iterations_compl is fixed to 2 in Webrun. This effectively means that changing network_iterations doesn't change anything, which doesn't seem to be good.

As I understood so far, two iterations of all nuclei are needed only for very peculiar cases, when the user is concerned about an exact B/C ration or uses damping. These can be rare cases. For this reason, I think it's necessary (of course, if my thoughts above are correct):
1) Correct the description of both parameters in Webrun;
2) Allow users to change network_iterations_compl, because not everybody is concerned about B/C, but doing one iteration instead of 2 greatly reduced computation time, for example, right now I'm running with 2 iterations (being unable to set 1), and it can't converge during over 36 hours already!
Comment 16 Andy Strong 2013-10-24 08:39:42 PDT
Right the description should be corrected, and the parameters should be all freely definable by the user as required.
If you are anyway not interested in B/C you can run without those nuclei. If you are interested in it, then 2 iterations is required for a reliable result.