we have get_seed and put_seed, but a more correct command wording would be get_seed and the other command being set_seed
See:

model.proclist.put_seed(PRNG_state)
https://kmcos.readthedocs.io/en/latest/tutorials/index.html

def write_settings in io.py has the random seed and the size of the simulation as hardcoded.

These should not be hardcoded. They should be options that a person can set in the Project class ("kmc_model" object) and the numbers should be pulled from there. The random seed might need to be converted into a PRNG object, which means it might need to be converted into something like 30 digits even if it is one digit.

Dear kmcos developers,

I am learning kmc and kmcos, I would like to ask you if it is possible to perform time-dependent rate constant kmc with kmcos.

Best regards,
Van

Expected behavior

The assert statement comparing the actual and expected XML files in test/types should return True

Actual behavior

The assert statement returns false, as the XML files have the same values in different order

Steps to reproduce the issue

1. Run test_xml_ini_conversion.py
   located here:
   https://github.com/kmcos/kmcos/tree/master/tests/test_types

System information

Ubuntu 18 LTS
kmcos version 0.0.63

Expected behavior
Successful calculation of MyFirstSnapshots__build.py

Actual behavior
When running MyFirstSnapshots__build.py, an unexpected error has occured.
Warning: kiwi Validation not working. (this warning is expected)
Statistics

Parameters: 4
Species: 2
Sites: 3
Processes (3/3/4)

    - CO : 2
    - CO_diffusion_hollow1 : 1
    - CO_diffusion_hollow2 : 1

sh: 1: del: not found
rm: cannot remove 'MyFirstDiffusion.xml': No such file or directory
sh: 1: del: not found
rm: cannot remove 'MyFirstDiffusion.ini': No such file or directory
sh: 1: del: not found
rm: cannot remove '*.so': No such file or directory
sh: 1: del: not found
sh: 1: del: not found
XML file exported to MyFirstDiffusion.xml , now validating model.
No export path provided. Exporting to MyFirstDiffusion_local_smart
Traceback (most recent call last):
File "/home/ksakai/kmcos/examples/MyFirstDiffusion__build.py", line 72, in
kmcos.compile(kmc_model)
File "/home/ksakai/anaconda3/envs/catalyst/lib/python3.11/site-packages/kmcos-1.1.0-py3.11.egg/kmcos/init.py", line 440, in compile
kmcos.export(kmc_model.filename + ' -b' + kmc_model.backend + ' ' + kmc_model.compile_options) # You can find these various compile_options in get_options() in kmcos/cli.py
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/ksakai/anaconda3/envs/catalyst/lib/python3.11/site-packages/kmcos-1.1.0-py3.11.egg/kmcos/init.py", line 457, in export
cli.main('export'+' ' + argumentsString)
File "/home/ksakai/anaconda3/envs/catalyst/lib/python3.11/site-packages/kmcos-1.1.0-py3.11.egg/kmcos/cli.py", line 373, in main
project.import_file(xml_file)
File "/home/ksakai/anaconda3/envs/catalyst/lib/python3.11/site-packages/kmcos-1.1.0-py3.11.egg/kmcos/types.py", line 662, in import_file
self.import_xml_file(filename)
File "/home/ksakai/anaconda3/envs/catalyst/lib/python3.11/site-packages/kmcos-1.1.0-py3.11.egg/kmcos/types.py", line 932, in import_xml_file
xmlparser = ET.XMLParser()
^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'XMLParser'

System information
kmcos version=1.1.0, Ubuntu 22.04

Need to have our XML files have its own backends by default

Expected behavior

All test cases of kmcos/test/export_test to pass/

Actual behavior

test_7.py fails due to a goocanvas error

Steps to reproduce the issue

1. Running "pytest test_7.py or pytest" in kmcos/tests/export_tests

System information

• result of kmcos version, operating system, version, python version, possibly link to model file
  Ubuntu 18.04.6 LTS

A potential fix to this issue can be seen here: https://askubuntu.com/questions/1388277/how-to-install-python-pygoocanvas-since-i-need-it-to-run-old-ns-3-24-projects

Hi,

how to encounter the titled problem? I just want to use it for diffusion problems but it shows "Warning: kiwi Validation not working. (this warning is expected)" when I type "from kmcos.types import *".

your help in this regard will be appreciated
thanks

Expected behavior

The XML/INI should have to conform to a schema (or similar) which we can validate against when exporting and importing models. It should be simple to modify and occur smoothly.

Actual behavior

There is something similar to a schema used right now, a DTD. But the process for using it and the logic inside the code for export/import of models is not smooth. https://github.com/kmcos/kmcos/blob/master/kmcos/kmc_project_v0.3.dtd

The Problem

I wanted to add a string to the XML in order to put that information into kmc_settings to be able to access that string from the model during runtime. To do so was a big pain. Accordingly, I ended up generalizing the string into a connected_variables dictionary , so that a person is less likely to need to go through this hassle again. However, the code and way of doing things should still be solved in a better way in the future.

The Current Logic

The current logic is something like this:

1. A person's build file makes a Project class object (typically "kmc_model")
2. A person's build file makes an xml file (or ini file).
3. That xml is then read back in and validated , which occurs against a DTD. A new Project class object is made from is read back in.
4. Then the source code compilation occurs, along with making kmc_settings. What is in kmc_settings roughly mirrors the original Project class object, but it is actually from the new Project class object that has been created from the xml. Unfortunately, creating the xml, reading the xml, and the DTD, all have hardcoded things with unusual parsing syntax because the way the data is structured in these different formats is currently not compatible. It's not like a JSON to YAML or XML to JSON conversion. Due to this hardcoding, it is non-trivial to add new variables to them.

The current steps for adding a variable

I found the correct order by trial and error. It should not be like this.

1. I first added a new variable into the Project class init function, inside types.py. self.connected_variables = {}
2. I needed to make a new dtd file: https://github.com/kmcos/kmcos/blob/master/kmcos/kmc_project_v0.4.dtd
3. Inside types.py, I needed to change several hardcoded places:

    xml_api_version = (0,4)
    kmcproject_v0_04_dtd = 'kmc_project_v0.4.dtd'  # This is not good variable naming and should change. It also should not be hardcoded like this, it should be parsing the string so that arbitrary numbers of versions can be added without updating the hardcoding each time.
   # There were other lines lower down inside types.py, in def import_xml_file, that I needed to update. For example,  supported_versions = ....    And these hardcodings need to be improved.  I improved one line of the hardcodings, but additional lines of the hardcoding still needs to be removed there.
  # it was especially confusing because all of these ways of writing the string of the version number are used: 0.4, 0_4, (0,4).  And the variable names do not make it very obvious that these hardcoded places need to be updated!

4. I needed to add my new variable into the writing of types.py so that connected_variables would become added to the xml, and needed to give a "heading" to the subitem contained in it, which I ended up calling connected_variables_string.
5. I needed to add both connected_variables and the connected_variables_string into the dtd file as things to expect. The DTD is not user friendly. JSON Schema would be better.
6. In the write_settings of io.py I needed to add
   out.write("connected_variables = " + )
7. I needed to add 'kmc_project_v0.4.dtd' into package_data of setup.py

Suggested Solution

We should cleanup the logic inside types.py so that ...
(a) the newest dtd is detected automatically rather than being hardcoded (just read filenames in the directory with some specific namestring in front, like kmcos_dtd_0.4)
(b) the internal variable names and supported versions should similarly not have hardcoding.
(c) We should switch to JSON and JSON Schema. Today the ecosystem for that is better. While JSON Schema were not really available at the time the core code was written, XML Schema was. Using an XML schema probably would have been a better choice than the DTD, but at this point we should probably just migrate to JSON Schema.

These changes are low priority since right now the changes being focused on are the ones that would increase kmcos adoption (not specialized applications kmcos development). Also, the new connected_variables will allow a variety of specialized applications, as long as they are intended to be from python and not from the backend.

More should be automated, and the usage of the various project object types should be better presented to new users.

• For example, i, j, k in generate_coord are almost always “0,0,0”. Generate_coord is already written in a way that the offset of 0,0,0 does not need to be included, so examples should be updated to use the simpler syntax.

• Direct calling of generate_coord by regular users is also superfluous. If somebody has created a site, currently done using sites.append, then obviously they want coordinates created for that site, so we should should make coordinates for the user automatically at the stage the sites are added. The site already has a name even when it is appended. The coordinates objects should be automatically generated for each site. Currently, layer.sites.append(xxxx) simply appends to a list of sites. Rather than layer.sites_append we can have layer.sites.add_site which will not only append to that list, but also automatically call generate_coord, and (if an optional name has been provided), generate_coord will add it to a global dictionary of coordinates. Then there will be a dictionary with each site’s name. The function generate_coord is already in the LayerList class, so it has access to the higher level layer object to put the dictionary inside the layer object. Then user can type coord = sitesDict[‘hollow’] or something like that. Note: there is already an add_site inside types.py project class, and in fact that then calls an “add_site” in the layer class, but it does not do a generate_coords at the same time..
  We should go one step further -- if someone types coord = ‘hollow’ that should also work, because we can check if it’s a coordinate or not, and retrieve the site. This only works if we force the site names to be globally unique (not just in layers) or if we force people to specify the layer name as well. Since there is an unclear usability decision to be made, this can be discussed before implementation.

Expected behavior

I was expecting kmcos to be ready to use after step 5.

Actual behavior

Examples:
Following the istructions reported here: https://github.com/kmcos/kmcos/blob/master/examples/README_for_Examples200423.txt

I get the following after slightly changing the command (there is no MyFirstSnapshots.py in the examples folder):

>> python3 MyFirstSnapshots__build.py
Traceback (most recent call last):                                                                                                                                                                  
File "C:\Users\MatteoAmbrosetti\kmcos\examples\MyFirstSnapshots__build.py", line 2, in <module>
import kmcos
ModuleNotFoundError: No module named 'kmcos' 

GUI:
If I type kmcos view I get the attached screenshot.

I have also tried to add the pygobject module (conda install -c conda-forge pygobject), but apparently nothing changes.

Steps to reproduce the issue

1. Create a new environment with Python 3.9.7
2. Add numpy and git module to the environment via GUI
3. Open terminal
4. Install ASE: conda install -c conda-forge ase
5. Download and install kmcos: Python setup.py install (Here I get kiwi Validation not working)

Instructions on using model.put and model._put() in the read the docs are not clear.

Try the following with an atoms object from ipython after running some steps

import ase.io.xyz

atoms = kmc_model.get_atoms(reset_time_overrun=False) #here, the self is the KMC_Model object.

ase.io.xyz.write_xyz(“ConfigurationXYZ.xyz”, atoms)

If that doesn’t work, try doing this for the last line:
ase.io.xyz.write_xyz(“ConfigurationXYZ.xyz”, [atoms])

Right now, a problem with kmcos is that we don’t have any way of exporting the configuration to other programs.
But, based on this link, I think we might be able to with the above commands.
https://wiki.fysik.dtu.dk/ase/_modules/ase/io/xyz.html#write_xyz

Expected behavior

kmcos viewer should appear when typing python kmc_settings.py view

Actual behavior

one or two steps occur then a crash

Traceback

/home/kmcos/VENV/kmcos/lib/python3.10/site-packages/kmcos-1.0.1-py3.10.egg/kmcos/view.py:281: UserWarning: Attempting to set identical left == right == 8.416152310568448e-06 results in singular transformations; automatically expanding.

self.tof_diagram.set_xlim(self.times[0], self.times[-1])

/home/kmcos/VENV/kmcos/lib/python3.10/site-packages/kmcos-1.0.1-py3.10.egg/kmcos/view.py:292: UserWarning: Attempting to set identical left == right == 8.416152310568448e-06 results in singular transformations; automatically expanding.

self.occupation_diagram.set_xlim([self.times[0], self.times[-1]])

(kmc_settings.py:2266): GLib-GIO-CRITICAL **: 20:37:39.143: g_application_parse_command_line: assertion '!application->priv->options_parsed' failed

Segmentation fault (core dumped)

System information

Ubuntu 20 on Virtualbox

#Snapshots module should save the current values of the parameters of interest. That way, if it is loaded, it becomes easier to populate the kmcos fortran variables with those values (in fact there should be a function based on load_simulation_state from the examples that does so).

load_simulation_state currently exists inside some of the TPD/TPR examples in the runfiles as a block of code. It should be made into a function inside the snapshots module. Then, a pointer to it should be made from the parent kmcos module so that people can type kmcos.load_simulation_state() and kmcos.save_simulation_state()

Use multithreading for do_snapshots() and exporting the configurations, so that exporting configurations does not slow down the do_snapshots() and create the TOF files quicker.

There seems to be a problem with seed_arr = seed_gen integer length.

Expected behavior

No Warnings during fortran compilation.

Actual behavior

405 | seed_arr = seed_gen(seed)
| 1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]

Suggested solution:

Fix to using Integer(8) for both. This is in proclist and I think it is in the proclist generic functions code.
look at proclist_constants.mpy and proclist_generic_subroutines.mpy inside kmcos\fortran_src

Steps to reproduce the issue

1. Go to examples, and do "kmcos export MyFirstDiffusion.xml" Please note that if you use "kmcos export MyFirstDiffusion.xml > seed_arr_issue.txt" , the warning will not be saved into the file seed_arr_issue.txt , this warning only appears on the screen.

System information

kmcos version 0.0.40

Expected behavior

When stopping a trajectory, saving parameters with save_params, loading the parameters with load_params, 'loading' the PRNG state via the snapshots module, we expect the exact same trajectory to occur as if we had not stopped and started the simulation.

Actual behavior

A reproducible trajectory occurs, but it is not the exact same trajectory as if we had not stopped and restarted the simulation.

Steps to reproduce the issue

1. Go into examples, kmcos export MyFirstTPD_Precovered.xml , then go into MyFirstTPD_Precovered_local_smart.xml
2. Run runfile1.py (then check the .csv file for TOFs etc.)
3. Run runfile2.py, then check the .csv file for TOFs etc., then run runfile3.py and check the .csv file for TOFs etc.

You will see that the temperature and time are continued as they should be, but that the trajectory produced is different.

System information

kmcos version 0.0.40

Compiling kmc models returns an error.
If the latest version of kmcos is installed using the provided install bash scripts from https://github.com/kmcos/kmcos-installers
it fails at compiling the test system MyFirstSnapshots__build.py
It gives the error

Error: Symbol ‘get_seed’ at (1) has no IMPLICIT type; did you mean ‘get_seedf2pywrap’?
...
error: Command "/usr/bin/gfortran -ffree-line-length-none -ffree-form -xf95-cpp-input -Wall -O3 -fimplicit-none -time -fmax-identifier-length=63 -fPIC -O3 -funroll-loops -I/tmp/tmpyjr9my3m/src.linux-x86_64-3.10 -I/usr/local/lib/python3.10/site-packages/numpy/core/include -I/usr/local/include/python3.10 -c -c /tmp/tmpyjr9my3m/src.linux-x86_64-3.10/kmc_model-f2pywrappers2.f90 -o /tmp/tmpyjr9my3m/tmp/tmpyjr9my3m/src.linux-x86_64-3.10/kmc_model-f2pywrappers2.o -J/tmp/tmpyjr9my3m/ -I/tmp/tmpyjr9my3m/" failed with exit status 1

If the numpy version is set back to 1.24.2 it succesfully compiles the model. Seems to be some issue with the f2py compilation.

Expected behavior

janaf_data directory should be made during installation along with a few files.

Actual behavior

janaf_data directory is not automatically put in the right place during installation.

Solution:
make janaf_data directory and move some files into it during installation. The Ubuntu installers from the bash script can certainly do that.
https://kmcos.readthedocs.io/en/latest/installation/index.html?highlight=janaf#installing-janaf-thermochemical-tables

The read the docs also needs to be updated:
https://kmcos.readthedocs.io/en/latest/topic_guides/developers_guide.html
The link to the janaf tables is an old link and should be: https://janaf.nist.gov/
and the text should be changed since janaf tables can be distributed, they are not copyrighted.

And the instructions for janaf should refer to the chemical potential question here:
https://kmcos.readthedocs.io/en/latest/troubleshooting/index.html

Expected behavior

Even if somebody has not used the Throttling Module, save_params with the 'default' Throttling Module settings and then loading them should not cause an error.

Actual behavior

An error is returned.

Steps to reproduce the issue

1. Go into the examples for MyFirstTPD_Precovered_local_smart, in runfile3 uncomment the line that says "#tg_module.load_params()"
2. Run runfile2, then run runfile3. An unexpected error will occur.

This is during April 2021. Version 0.0.40

get_next_kmc_step currently does not return the same output if called twice without doing any steps. Evidently, the random numbers advance after calling it. The routine should be changed to reset the random numbers after calling them. The code is inside:

kmcos\kmcos\fortran_src\proclist_generic_subroutines.mpy

https://github.com/kmcos/kmcos/blob/master/kmcos/snapshots.py (for do_snapshots)
https://github.com/kmcos/kmcos/blob/master/kmcos/run/__init__.py (for export_movie)

Change the export_movie() function to use do_snapshots() instead of steps so when exporting every image, the do_snapshots method is called. Or, make a do_snapshots_movie command or something like that.

Also, do_snapshots() should have an option to export configurations.

Expected behavior

Actual behavior

//: # (Besides the text description, include any screenshot(s) that help us visualize the issue you're facing)

Steps to reproduce the issue

System information

• result of kmcos version, operating system, version, python version, possibly link to model file

Expected behavior

XML and other file comparisons should pass when they match.

Actual behavior

Sometimes they don't during unit tests. Even when notepad++ says the files are the same. For example, on April 9 2021, for export_test, the test_5 lattice.f90 files did not pass the comparison with filecmp, but in Notepad++ the file compare said no difference.

Suggested fix

Use a diff utility or read the strings in. Consider using the below xml comparison.
https://stackoverflow.com/questions/321795/comparing-xml-in-a-unit-test-in-python
Python has difflib. Difflib should, at least in principle, also enable fixing the issue of the various proclist unit tests which put out the cases in inconsistent order.

Edit: A better fix will be using this highly used package -- https://github.com/hamcrest/PyHamcrest

The JANAF installation should be improved

And the instructions for janaf should refer to the chemical potential question here:
https://kmcos.readthedocs.io/en/latest/troubleshooting/index.html

Expected behavior

In page 10 of the Workshop Introduction to Kinetic Monte Carlo of Systems(KMCOS) when using kmcos from client scripts the example MyFirstTPD_Precovered_local_smart is used to explain snapshots. After compiling the model by running the build file, a runfile7 will appear in model's directory. Running this file can plot temperature vs TOFs.

Actual behavior

When running runfile7 an unexpected error "import export_import_library as eil; ModuleNotFound Error: No module named export_import_library" appears. Reinstall python will not solve the problem and cannot find where the export_import_library module belong to.
//: # (Besides the text description, include any screenshot(s) that help us visualize the issue you're facing)

Steps to reproduce the issue

System information

• result of kmcos version, operating system, version, python version, possibly link to model file

Currently, kmc_model.compile_options = '-d' turns on the assert statements, but they do not work while running a model in a typical installation. They may need some kind of special fortran environment (I do not know which one is needed).

I think the assert statement should be made into a 'regular' fortran function rather than in a ppc file so that it can work in the normally used environment.

Expected behavior

When a snapshot is run, its output should be added to a list rather than only to a file.
This way, people who want to do many iterations and use the output in some other software don't have to wait for the I/O of writing to file. This matters for parameter estimation, for example.

Actual behavior

Currently only writing to file is possible for snapshot output, unless a person manually extracts each output.

Suggested Solution

have optional arguments "storeInMemory=False" and "writeToFile=True". memory being false and file being true will be the default, but the other way also becomes readily accessible (and one can also do both if desired).

Model Dimension is not a meta variable

[ ] The MyFirstThrottling example currently requires typing "kmcos export". It should be changed to use the new syntax of exporting directly from the python file that makes the xml.
[ ] In MyFirstSnasphots the plotting configuration example currently does not show how to change the size and colors of the points by plot_settings. Those features should be shown by example and/or should have those features added. Currently, the source code is in /run/init.py https://github.com/kmcos/kmcos/pull/119/files . Additionally, under the documentation, plot_configuration we should have the full set of information about plot_settings. Additionally, an argument should be added to export all of the XY data to a single CSV.

Expected behavior

In model.view(), the various slider bars should allow the user to adjust the model parameter at runtime

Actual behavior

The slider functionality in model.view() does not work as intended. The slider window opens, but the sliders are locked in place.

Steps to reproduce the issue

1. Enter ipython inside one of the local_smart directories in kmcos (MyFirstDiffusion_local_smart for example)
2. Enter 'model.view()' in the ipython terminal
3. Viewer GUI shows up and shows the slider window locked in place

System information

Ubuntu 18.04.6 LTS

The ParamSlider Class is not working as intended (can be found in kmcos/view.py).
class ParamSlider(gtk.HScale):

The throttling module currently exports semi colon separated csv files
It should be changed to also export tab separated versions (.tsv) since some people might find that easer

https://github.com/kmcos/kmcos/blob/master/kmcos/throttling.py

do_steps (and related functions) should return the number of steps taken.
When a deadlock occurs, maybe a none object should be returned, without exiting the simulation, that way an external python script can know that the simulation failed. Currently, if a surface becomes deadlocked, scripts stop, which prevents creations of logs etc.

when people first install kmcos, there should be something which indicates whether they will be using python or python3 from the command line, and that should be recorded during installation in some kind of installation log file that will be read later. Then we would not have this issue of having to change it in init.py between different systems:

m-deimel@b151663

Expected behavior

I can get same results from the same MyFirstSnapShot__build.py.

Actual behavior

I got two diffrent results from the same MyFirstSnapShot__build.py.

In Ubuntu22.04, python 3.11.3, kmcos=1.1.0, When I run the kmc_settings.py, I got the message.
Warning: kiwi Validation not working. (this warning is expected)
Using the [local_smart] backend.
1000000 steps took 0.36 seconds
Or 2.75e+06 steps/s

In Ubuntu18.04, python 3.6.7, kmcos=1.1.0, When I run the kmc_settings.py, I got the message.
Warning: kiwi Validation not working. (this warning is expected)
Using the [local_smart] backend.
1000000 steps took 2.75 seconds
Or 3.64e+05 steps/s

There is also a difference of the outlog of MyFirstSnapShot__build.py between two version.
Which is the correst result?

Thank you.

Expected behavior

When running pytest with individual files passes, running pytest on the entire directory should also work

Actual behavior

In test/acceleration, running pytest on the directory does not work "completely". Test_3.py fails . A message is displayed that says that the model is not a compiled accelerated model.

Steps to reproduce the issue

1. pytest in test/acceleartion

System information

Ubuntu 18 LTS
kmcos 0.0.63