'lattice_size' parameter in some models

[jmlorenzi]

I see that in some example models a lattice_size parameter appears... Is this deprecated or still used in the current version of the code? Ditto for print_every and total_steps

EDIT: Also the same question for the output section of the xml files

[mhoffman]

Yes, I would say we should regard all of these as deprecated (at least in this location). They where initially all put in these different places to make the model/results specification as complete as possible. However I think practice has shown that it is more intuitive keep all runtime parameters in kmos.run (or function calls therein) and only put actual model parameters into kmos.types and class instances therein.

I think this split is more intuitive because specifying a model is one type of activity (possible involving electronic structure calculations) and converging, running, analyzing model and extracting observables is another type of activity. And both may happen on different filesystems and by different users etc. ... However I did not realize this in the beginning. My bad.

I am happy to refactor these parameters out if you think they lead to confusion. What do you think?

Talking about standardizing the evaluation work-flow: What do you think is the best way to do this? I think there should be standard way to evaluate models (and possible create plots). However one can also go a long way by providing documentation for more complicated operations. That way we capture both the standard use case for equilibrating/sampling rates and coverages but also allow advanced users to hack and extend these capabilities. For catmap I am planning on devising a command line call. Currently the specification looks as follows:

Usage: catmap run_kmc -E <N> -S <N>
Options :
    -E, --equilibration-steps (default: 1e8)
        number of equilibration steps before sampling
        CHECK CAREFULLY IF SUFFICIENT

    -S, --sampling-steps (default 1e8)
       number of sampling steps to calculate rates
       and coverages.
       CHECK CAREFULLY IF SUFFICIENT

    -s, --single-point
      Force 'catmap run_kmc'  to only evalute one descriptor point
      and finish evaluation.
      Otherwise the model runner will keep evaluating descriptor
      points until they are all exhausted.

    -n, --dont-run
     If 'catmap run_kmc' should only plot results and
     not evaluate any descriptor points

    -p, --print
     If 'catmap run_kmc' should plot results

    -c, --initial-configuration
     Pick how the kmc model runner initializes the lattice.
     Currently implemented are:
     probabilistic [default], empty, species:<species_name>, and majority.

When coming from the catmap side the sampled parameters (e.g. temperature, pressure, descriptors, ...) are specified in the CatMAP model input file (*.mkm). Maybe in the kmos case we could make kmos run behave like catmap run_kmc (or similar) if the user puts a file like run.py into the same directory? I think it should make nice plots for single-parameter scans (line plots) and two parameters (contour plots). Furthermore it should provide some useful output for single-point time-series. What other use cases can you think of?

[jmlorenzi]

Hi Max,

Regarding these "deprecated" parameters: I only came to notice them because the source code generated by otf for some of these example models crashed when it tryed to evaluate lattice_size, as its value was "20 20" (at initialization, models built with otf use python to evaluate all user parameters and stores them in fortran variables). I do not think they lead to confusion... may be we could keep them, depending on what is decided in the issue you raised.

My initial comment on having kmos output default output is for two main reasons:

1. I have the impression that it might be an early barrier for newcomers (the only evidence I have is an old issue raised here, but it seems plausible)
2. I have found that sometimes I regret not having 'pulled out' more information from model runs. In particular I think we should evaluate the posibility of dumping procstat to a file during normal execution, in a way that can be turned on/off with a simple flag in methods from kmos.run. I don't how huge these files might be...

Regarding you specific points:

• Definitely more documentation on 'running model examples' would be awesome
• I do think a default command line script would be awesome. I have build one similar for me, that reads an input file and takes lots of options and either submits the jobs to the cluster or run thems locally. However, in the current state is not portable at all.
• In line with this, I think it would be nice to have a default behavior for kmos run (or kmos defrun) that does not require any additional scripts. Then, it should be possible to allow thigs like

kmos defrun --nrelax 1e7 --nsample 2e8 --p-cogas 1e-3 --t 650

And this should write some messages to stdout, and one or more files.

Best Juan