Positioning atoms while preparing the model

[vpasumarthi]

Hi Max,

Thanks for sharing the kmos. I am trying to use the kmos installation on the linux cluster. Though the GUI is not working, I'm managing with the API mode. Now, I have been able to build and run models using the docuementation provided on the kmos website for all three supported processes (adsorption, desorption and diffusion). I could perform diffusion as long as there is an adsorption process associated to place the atoms on the surface. But, how to prepare a model with only diffusion process and starting with some atoms/molecules positioned on the lattice surface? I have checked the diffusion related examples from kmos package, and most of them and including the above described model are resulting in the following error:

ERROR: interval_search_real can't find available process
This usually means one of the following:

• you forgot to define rate constants
• you create a dead-lock: e.g. adsorption without corresponding desorption.
• you started the model in an initial state without transitions

I believe this is because there is no atom available on the surface to diffuse.

Thank you and your help is appreciated.
Viswanath.

[mhoffman]

Hi Viswanath

thanks for reaching out. Getting a model running from a user defined initial configuration can sometimes be a bit tricky. However there are ways to debug it by hand quite easily. So I assume that you are using an instantiated kinetic Monte Carlo model (kmos shell) and manipulate the configuration with either model._set_configuration(<np-array>) or model._put(...). In either case you have to run model._adjust_database() to make sure the change in configuration is reflected in the database of available processes.

If you have made sure the database is up to date it will be useful to find out if the model runs out of available processes (which points toward an ill-defined initial configuration) or later in the simulation run (which points towards a dead-lock situation in your elementary process catalog). To this end you should run model.print_accum_rate_summation(). It will tell you exactly which process are available right now.

If there are processes available I would try to reproduce the state in which is crashes by running it and print model.print_accum_rate_summation(). If there are no processes available you should inspect the current state (model.print_coverages(), model.show(), etc).

You mention that you couldn't in install the GUI on the linux cluster. In my experience the GUI can be really quite helpful for debugging a model. EIther by displaying kmos.show() or by inspecting the model file with kmos edit <model-file>.(xml/ini). If you can manage to install that locally somehow you will most likely see soon what is going on. Almost regardless of your local OS I would bet that a recent Ubuntu in a Docker will get you there with moderate effort.

Best of luck and let me know how it goes,
Max.

[vpasumarthi]

Hi Max,

I was busy with the semester work and couldn't get time to work with kmos. But I have started working from where I left off last time. I have taken your suggestion and installed the python modules required to use the GUI version in my Mac (OS X El Capitan Version 10.11.4).

However, when the xml file is exported, it generated src folder in the destination directory but not the model files (kmc_model.so and kmc_settings.py). Only output in the terminal during this process is /Users/Viswanath/Library/Python/2.7/lib/python/site-packages/kmos. Upon navigating to the src folder and firing kmos build, it generated the files kmc_model.so*, kmc_model.so.dSYM/, f2py_selected_kind.so*, f2py_selected_kind.so.dSYM.

Alternatively, I looked into the cli.py (kmos command-line interface) file to find that the model files are only generated for Linux and Windows (nt) based systems during export. So, I have changed the condition from os.uname()[0] == 'Linux' to os.uname()[0] == 'Darwin' to support Mac OS X based systems. Upon repeating the export process, I found the model file kmc_model.so* generated in the destination folder, along with an additional kmc_settings.py.dSYM file.

However, in either case, I have tried firing kmos view to find the interactive window coming up and is working perfectly fine. However in the plot window, only TOF count is plotted and no data is being plotted for coverage section.

My questions to you:

1. Is the above mentioned procedure appropriate? Isn't kmos developed to support Mac OS X systems?
2. How are * files different and what is the reason for the generation of additional .dSYM files?
3. What is the reason for coverage data to be not plotted? But the model files from examples generate the tracking of coverage data. I've compared my python files with the ones used in the examples folder to generate xml files to find nothing substantially different.

Thank you,
Viswanath.

[mhoffman]

1. Is the above mentioned procedure appropriate? Isn't kmos developed to support Mac OS X systems?

I am currently using and developing kmos under OSX 10.11.4, CentOS 6.7, and RedHat 6.8. So your case should be covered.

1. How are * files different and what is the reason for the generation of additional .dSYM files?

Despite working on OSX for over a year now, I have not crossed *.dSYM files. kmos certainly does nothing to create them and one doesn't need them. Maybe check your xcode settings?

1. What is the reason for coverage data to be not plotted? But the model files from examples generate the tracking of coverage data. I've compared my python files with the ones used in the examples folder to generate xml files to find nothing substantially different.

I remember that this was a bit tricky to get going. Do you have matplotlib installed? Maybe some additional gtk package is required as well.

[vpasumarthi]

Thanks for the comments Max. I checked the source code on github, and found that you added Darwin to allow for automatic building on export on Mac OS couple of years ago. I don't understand how I missed that version. Anyhow, after reinstalling kmos using the current version available on github, my first and last questions are solved for. Now I can see the data plotting for both TOF count and coverage.

However, the .so* and .dSYM files are generated all the same. Here I'm attaching the text of the printed output (output.txt) while building on the exported .xml file. Do you have any idea what might have been causing this anomaly?