Nearest Neighbor Interactions in kmcos

[EricS]

Hello,

Most of the examples that involve movement on the surface have simple and symmetric conditions/actions.  For example if an adsorbate is in location A and a neighbor location B is empty, the action is to swap.

How does kmos handle nearest neighbor interactions between adsorbates?  More specifically, can you a.) have a files that mixes simple processes that ignore occupation that is not involved in movement with processes that need to quantify the exact population of nearest neighbors or b.) do you need to elevate all processes to detailed neighbor checking (e.g., specifying a diffusion rate for every nearest site+neighbor-shell configuration so that the unique one with a different rate constant is captured.)  If processes are checked in the order they are entered you might be able to play some tricks here?

This might be a naive question.  I am still very new to KMC.

Best,

Eric

[Aditya "Ashi" Savara]

These are good questions and are things that I'd like to have better documented. I'd like to have an interactions section for the read the docs.

[After writing most of this email, it looks like I said some of the below in this file: https://github.com/kmcos/kmcos/blob/master/examples/0-README_for_Examples200423.txt ]

 There will be a few subtopics in my reply.

First, there are two ways to include lateral interactions in KMC, in general. Kmcos has both.
a) Separate processes with separate conditions. [local_smart and lat_int backends]. This can easily result in thousands of processes.
b) Defining processes with dynamic rate constants that change based on the occupations around them [this is called 'on the fly' and is in the otf backend]

Now to explain the 3 backends, then come back to how to do it in kmcos.
local_smart: this is the default backend.  Let's say that it's basically the fastest KMC problem in the world for this type of problem -- whether it's the fastest or not is debatable, but it is certainly one of the fastest.  However, it does not support on the fly and it also does not work when there are more than let's say 500 processes, but maybe the actual possible number is much bigger than that.

lat_int: this backend is really misnamed. It is just a backend that supports essentialy arbitrarily large numbers of processes by breaking the process list into a smaller number of processes. If local_smart fails to build or fails to run due to computer memory issues, one should switch to this one. One can also go directly to this one, it's not terribly slower than local_smart even for small problems.  Maybe a factor of 2 if I remember correctly.

otf: The on-the-fly backend does dynamic rate constants, which means that one can have (for example) 8 processes rather than (for example) 1000 processes that each have different conditions. I just made up those numbers, but they are the right order of magnitude.

The people who made the backends have moved on to demanding jobs and don't look at kmcos related things anymore, we simply have their documentation, and in some cases examples.

I don't remember the details of the The otf backend. It couldn't do what I wanted it do for one of my studies, so I made a lateral interactions module since I needed BEP relations and then I used the lat_int backend.

In all cases, what is really happening is that at the time of process execution, the rate constant's value is based on what are called the "conditions" for a process to occur. I will come back to this point.

OTF way:
https://kmcos.readthedocs.io/en/latest/topic_guides/otf_backend.html#advanced-otf-rate-expressions
https://github.com/kmcos/kmcos/blob/master/examples/pairwise_interaction_otf_no_JANAF__build.py

By-hand-way (can include loops, it's not totally by hand):
https://github.com/kmcos/kmcos/blob/master/examples/MyThirdTPR__build.py

My interactions module way that automatically generates processes based on nearest neighbors up to whatever distance you want

Note that it says compiling upToDistance1 for that example (which has many possibilities) can take 30 hours to compile. The KMC steps run a bit slower, too, I don't remember by how much.

https://github.com/kmcos/kmcos/tree/master/examples/InteractionsModuleExample
My  interactions module includes pairwise and supports BEP relationships in those pairwise interactions. It currently has nothing more sophisticated, but was designed to be extendable to arbitrary cases [like cluster expansions for example -- but I'm not saying it would be easy to extend]

A better solution is really a more general on the fly backend, which is planned, but could be a few years away [assuming that no other kmc code becomes so dominant and with enough features that this code becomes obsolete -- I hope that is unlikely but it is possible]


No matter which way you do things, you need to think very carefully about site positions etc. At least, I had to for the problems I worked on.
It could take a few days or a week, drawing things out, just to figure out how the pseudo code should be written. Then writing the code could take a day or more, then testing it, then one can run things.  Your problems could be simpler or harder. Probably simpler if you're looking at diffusion.

There is an important point though: outside of defining things up to a far distance of nearest neighbors with my module, kmcos does not have any way of looking at non-local interactions. For solid state diffusion, there are codes that consider particle distance some 30 atoms away or something. Kmcos was really designed for local configurations. If you need to consider 10 atoms away, I imagine (without knowing) that KMCLib would be a better choice.

[Aditya "Ashi" Savara]

I suppose I should point out that if one wanted to write some on the fly some more general far interaction terms code in the backend (which would require doing so in fortran and be a big undertaking), that would certainly be welcome.

Also, it may be possible to use the otf backend to far distances like a radius of 30 nearest neighbors. I don't know, I didn't look at it further once I found that it couldn't do what I needed even for first nearest neighbor, due to not having BEP relationship capabilities [yet].

[Aditya Ashi Savara]

To answer one of your other questions:

With kmcos, the order of the process tree cannot be used to play the types of tricks you are describing (that one process gets checked before the other one).  A standard KMC algorithm will not allow that and will treat both processes as allowable (meaning as parallel, if both have their conditions fulfilled).

With kmcos, You can have a process that occurs with (for example) empty surrounding sites, and a process that is identical other than having a neighbor, and having a different rate constant.  You can have a process that requires "at least" one nearest neighbor, and another one that is identical but requires "at least 2". In this example, when there are 2 neighbors either could occur, based on which random number gets selected when a kmc step is taken. At least, for local_smart and lat_int that is how it would be. The otf backend. can probably be used that way but is not intended to be used that way.

--
You received this message because you are subscribed to a topic in the Google Groups "kmcos-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kmcos-users/LaBmohD-m_Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kmcos-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kmcos-users/c4bfe84b-79e3-4bc9-9734-607c9cf9b909n%40googlegroups.com.