mhoffman / kmos

kMC on steroids: A vigorous attempt to make lattice kinetic Monte Carlo modelling easier

Home Page:http://mhoffman.github.com/kmos/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rate constant evaluation

mieand opened this issue · comments

I am currently trying to implement a model with lateral interactions, scaling relations, and thermochemistry corrections. I run into the problem that it becomes increasingly cumbersome to follow the original approach, whereby rate constants are defined as a string and all input as kmos parameters. I am therefore instead considering to define all parameters (beta, h, T, p, energies, frequencies) directly in my input file and to carry out the evaluation of the rate constant also directly in my input file.

My question is: Could this cause any unforeseen problems, for example making the code slower to compile? What was the reason that the string rate constant approach was chosen originally?

As far as I can tell compilation speed cannot be the issue here. It is more about control and documentation (transparency). If you evaluate parameters to (floating point) numbers in your input file, you can no longer change later easily at runtime (e.g. kmos.parameters.T = 545). I don't see why one would want to give up this possibility.

Also as long as you use the kmos parameter idiom every parameter will end up in the kmc_settings.py in a pretty easy to read way. So a year from now you will still know what every number in the model stands for or you can look it up quickly in the generated model code. That may no longer be true if the generated code contains one or more 'magic' numbers.