Talk:Kinetic Monte Carlo

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 piss:

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]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Kinetic Monte Carlo. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20081010112418/http://www.ipam.ucla.edu/publications/matut/matut_5898_preprint.pdf to http://www.ipam.ucla.edu/publications/matut/matut_5898_preprint.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:01, 10 December 2017 (UTC)[reply]