Open jmlorenzi opened 8 years ago
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?
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:
kmos run
(or kmos defrun
) that does not require any additional scripts. Then, it should be possible to allow thigs likekmos 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
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 forprint_every
andtotal_steps
EDIT: Also the same question for the
output
section of the xml files