Talk:Kinetic Monte Carlo

Physics Start‑class Mid‑importance

	Physics portal This article is within the scope of WikiProject Physics, a collaborative effort to improve the coverage of Physics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.PhysicsWikipedia:WikiProject PhysicsTemplate:WikiProject Physicsphysics
Start	This article has been rated as Start-class on Wikipedia's content assessment scale.
Mid	This article has been rated as Mid-importance on the project's importance scale.

Am I wrong in thinking that it actually makes sense to update the simulation clock BEFORE the move? I understand why people are used to clocks being incrimented after a configuration change, but in this case I think it makes the algorithm more confusing. The way it is currently laid out, an evarsefuckent table has to be generated twice, even though the first table is really the same table that would have been generated at the end of the previous loop.

To me it sounds like this would be a better way of putting it:

1. determine possible events, and corresponding rates

2. draw random number from the distribution

3. draw random number from a uniform distribution, compare with rate table to decided what happens

4. carry out event

5. repeat

That way there is only ever one rate table.

Also, on a different note, could someone please explain why there needs to two random numbers generated? This is not clear from the article, and I think it should be addressed.

Itamblyn 00:24, 15 April 2007 (UTC)[reply]

Yeah, certainly it is not intended that the event list be updated more than necessary. The way that is written I intended to mean that "forming a list" and changing the rates is distinct operations, but in practice that most likely is not the case. I'll change the algorithm to point to 2.

About the order: it is the usual convention in most sources that the time is updated after the change is made, so it is best to keep it that way.

Since the time step updating is not correlated with which event is choses, it is physically more reasonable to use different random numbers.

Knordlun (talk) 16:25, 6 January 2008 (UTC)[reply]

I just want to note that the external links are currently down, the message says the site is suspended so it may be up once again —Preceding unsigned comment added by 141.24.104.205 (talk) 14:08, 8 June 2010 (UTC)[reply]

I want to clarify two issues raised by Itamblyn: (1) In the basic algorithm described in this article it matters not which of the two to perform first - randomly sampling an event or randomly sampling the event time. These two steps commute for as long as the unit events are Poisson. (2) Yes, in the BKL algorithm described in the articles one must use two random numbers, one for selecting an event and another one for selecting the time increment. Otherwise, if the same random number is used for both, one introduces spurious bias (correlations). For example, when the sample time increment happens to be small compared to 1/R (random number u happens to be close to 1) then some event that is closer to the end of the frequency line is selected (which corresponds to the same large u). This would be a very wrong algorithm. Finally, at this point I have no time to edit the article itself, but it would be good to also point out that use of 1/R for the time increment may not be always accurate and requires additional considerations: whereas the BKL algorithm, as described in the article, samples from the solution of the Master Equation for state probabilities of the underlying continuous time Markov Chain (CTMC), the 1/R algorithm does not. However, with the 1/R selection for the time increment, CTMC should (but not guaranteed) converge asymptotically to the solution of the ME but only for times much longer than 1/R. By comparison, the BKL algorithm can be used to obtain solution of the ME for any times, even for times much shorter than 1/R. (Vasily Bulatov) —Preceding unsigned comment added by 75.18.231.144 (talk) 05:37, 17 June 2010 (UTC)[reply]