Skip to content

Parameters

Introduction

About

This section provides a detailed overview of all unique parameters for all workflows.

To identify the parameters allowed for a specific workflow, use the explore command or workflow.show_parameters():

simmate workflows explore

workflow.show_parameters()

File vs. Python formats

When switching from Python to YAML, make sure you adjust the input format of your parameters. This is especially important if you use python a list or dict for one of your input parameters. Further, if you have complex input parameters (e.g. nested lists, matricies, etc.), we recommend using a TOML input file instead:

# in python
my_parameter = [1,2,3]

# in yaml
my_parameter:
    - 1
    - 2
    - 3


# in python
my_parameter = {"a": 123, "b": 456, "c": ["apple", "orange", "grape"]}

# in yaml
my_parameter:
    a: 123
    b: 456
    c:
        - apple
        - orange
        - grape

# in toml
[my_parameter]
a = 123
b = 456
c = ["apple", "orange", "grape"]


# in python
my_parameter = [
    [1, 2, 3],
    [4, 5, 6],
    [7, 8, 9],
]

# in yaml (we recommend switching to TOML!)
my_parameter:
    - - 1
        - 2
        - 3
    - - 4
        - 5
        - 6
    - - 7
        - 8
        - 9

# in toml
my_parameter = [
    [1, 2, 3],
    [4, 5, 6],
    [7, 8, 9],
]


# in python
my_parameter = (1,2,3)

# in yaml
my_parameter:
    - 1
    - 2
    - 3
# WARNING: This will return a list! Make sure you call 
#   `tuple(my_parameter)`
# at the start of your workflow's `run_config` if you need a tuple.

# in toml
my_parameter = [1, 2, 3]
# WARNING: This will return a list! Make sure you call 
#   `tuple(my_parameter)`
# at the start of your workflow's `run_config` if you need a tuple.

algorithm

This parameter is specific to the BadELf workflows in the warrenapp. Options include badelf, voronelf, or zero-flux.

zero-flux will use traditional bader-like partitioning. voronelf will use planes located at minima in the ELF along atomic bonds. badelf will use a hybrid, separating atoms with planes and bare electrons with a zero-flux surface.

algorithm: badelf

algorithm = "badelf"

algorithm = "badelf"

angle_tolerance

This parameter is used to determine if the angles between sites are symmetrically equivalent when standardize_structure=True. The value is in degrees.

angle_tolerance: 10.0

angle_tolerance = 10.0

angle_tolerance = 10.0

chemical_system

This parameter specifies the chemical system to be used in the analysis. It should be given as a string in the format Element1-Element2-Element3-.... For example, Na-Cl, Y-C, and Y-C-F are valid chemical systems.

chemical_system: Na-Cl

chemical_system = "Na-Cl"

chemical_system = "Na-Cl"

Warning

Some workflows only accept a chemical system with a specific number of elements. An example of this is the structure-prediction.python.binary-composition search which only allows two elements (e.g. Y-C-F would raise an error)

command

This parameter specifies the command that will be called during the execution of a program. There is typically a default set for this that you only need to change if you'd like parallelization. For example, VASP workflows use vasp_std > vasp.out by default but you can override this to use mpirun.

command: mpirun -n 8 vasp_std > vasp.out

command = "mpirun -n 8 vasp_std > vasp.out"

command = "mpirun -n 8 vasp_std > vasp.out"

composition

The composition input can be anything compatible with the Composition toolkit class. Note that compositions are sensitive to atom counts / multiplicity. There is a difference between giving Ca2N and Ca4N2 in several workflows. Accepted inputs include:

a string (recommended)

composition: Ca2NF

composition = "Ca2NF"

composition = "Ca2NF"

a dictionary that gives the composition

composition:
    Ca: 2
    N: 1
    F: 1

[composition]
Ca = 2
N = 1
F = 1

composition={
    "Ca": 2, 
    "N": 1, 
    "F": 1,
}

a Composition object (best for advanced logic)

from simmate.toolkit import Compositon

composition = Composition("Ca2NF")

compress_output

This parameter determines whether to compress the directory to a zip file at the end of the run. After compression, it will also delete the directory. The default is False.

compress_output: true

compress_output = true

compress_output = True

copy_previous_directory

This parameter determines whether to copy the directory from the previous calculation (if one exists) and use it as a starting point for the new calculation. This is only possible if you provided an input that points to a previous calculation. For instance, structure would need to use a database-like input:

structure:
    database_table: Relaxation
    database_id: 123
copy_previous_directory: true

copy_previous_directory: true

[structure]
database_table = "Relaxation"
database_id = 123

structure = {"database_table": "Relaxation", "database_id": 123}
copy_previous_directory=True

diffusion_analysis_id

(advanced users only) This is the entry id from the DiffusionAnalysis table to link the results to. This is set automatically by higher-level workflows and rarely (if ever) set by the user.

directory

This is the directory where everything will be run -- either as a relative or full path. This is passed to the utilities function simmate.ulitities.get_directory, which generates a unique folder name if not provided (such as simmate-task-12390u243). This will be converted into a pathlib.Path object. Accepted inputs include:

leave as default (recommended)

a string

directory: my-new-folder-00

directory = "my-new-folder-00"

directory = "my-new-folder-00"

a pathlib.Path (best for advanced logic)

from pathlib import Path

directory = Path("my-new-folder-00")

directory_new

Exclusive to the restart.simmate.automatic workflow, this is the folder where the workflow will be continued. It follows the same rules/inputs as the directory parameter.

directory_old

Exclusive to the restart.simmate.automatic workflow, this is the original folder that should be used as the starting point. It follows the same rules/inputs as the directory parameter.

downscale_resolution

Exclusive to BadELF workflows. This is the resolution in voxels/Angstroms^3 that the ELF will be downscaled to in the ElfAnalysisToolkit to increase speed. This can be ignored by setting the value to None.

downscale_resolution: 1200

downscale_resolution = 1200

downscale_resolution = 1200

elf_analyzer_kwargs

Exclusive to BadELF workflows. These are the keyword arguments passed to the ElfAnalyzerToolkit class that control how features in the ELF (e.g. bare electrons, covalent/metallic bonds, etc.) are automatically found and labeled.

elf_analyzer_kwargs:
    resolution: 0.01,
    include_lone_pairs: false,
    include_shared_features: true,
    metal_depth_cutoff: 0.1,
    min_covalent_angle: 135,
    min_covalent_bond_ratio: 0.4,
    shell_depth: 0.05,
    electride_elf_min: 0.5,
    electride_depth_min: 0.2,
    electride_charge_min: 0.5,
    electride_volume_min: 10,
    electride_radius_min: 0.3,
    radius_refine_method: linear,
    write_results: true,

[elf_analyzer_kwargs]
resolution = 0.01
include_lone_pairs = false
include_shared_features = true
metal_depth_cutoff = 0.1
min_covalent_angle = 135
min_covalent_bond_ratio = 0.4
shell_depth = 0.05
electride_elf_min = 0.5
electride_depth_min = 0.2
electride_charge_min = 0.5
electride_volume_min = 10
electride_radius_min = 0.3
radius_refine_method = "linear",
write_results = true,

elf_analyzer_kwargs = dict(
    resolution = 0.01,
    include_lone_pairs = false,
    include_shared_features = true,
    metal_depth_cutoff = 0.1,
    min_covalent_angle = 135,
    min_covalent_bond_ratio = 0.4,
    shell_depth = 0.05,
    electride_elf_min = 0.5,
    electride_depth_min = 0.2,
    electride_charge_min = 0.5,
    electride_volume_min = 10,
    electride_radius_min = 0.3,
    radius_refine_method = "linear",
    write_results = True,
)

Each keyword argument controls an aspect of how ELF features are found:

resolution

The interval at which to scan the ELF to generate BifurcationGraphs. Larger values will be faster, but may miss bifurcations.

include_lone_pairs

Whether or not to include lone-pairs in the labeled structure. It is generally recommended to leave this as false when using plane partitioning for atoms.

include_shared_features

Whether or not to include shared features such as metallic/covalent bonds in the labeled structure. If splitting these features at their maxima with planes is the desired output, set to false. If the goal is a comprehensive charge analysis of these features, set to true. If set to true, the shared_feature_algorithm parameter will control how they are separated from nearby atoms/features.

metal_depth_cutoff

For ELF features other than atom cores/shells or lone-pairs, this parameter controls the maximum depth (Difference from ELF maximum to bifurcation) that a metallic feature can have. Any non-atomic/lone-pair feature with a depth below this value will be assigned as metallic.

min_covalent_angle

For features other than atom cores/shells, the algorithm will check whether the feature is along an atomic bond within an angle tolerance. This corresponds to the angle between the neighboring atoms and the feature. Any feature with an angle below this value will not be assigned covalent.

min_covalent_bond_ratio

When determining between a lone-pair or covalent bond, the algorithm will check how far along the bond the feature is (noramalized to 1). Anything below this parameters value will be considered a lone-pair. This is done to avoid misassignment in situations where the lone-pairs align with nearby atoms in a dipole interaction.

shell_depth

In ionic compounds, the unshared electrons will form a sphere around the more electronegative atom. As the bond becomes more covalent, this feature will break into smaller features along the atomic bonds. As covalency increases, the depth of these features increases. Thus, this parameter effectively defines a cutoff for what should be considered covalent vs. ionic.

Additionally, due to voxelation, atomic shells may split into many different basins around their ELF maximum. This parameter also controls recombining these voxelated basins into one.

electride_elf_min

The minimum ELF value that a bare-electron feature must have to be considered an electride.

electride_depth_min

The minimum ELF depth that a bare-electron feature must have to be considered an electride.

electride_charge_min

The minimum charge that a bare-electron feature must have to be considered an electride.

electride_volume_min

The minimum volume that a bare-electron feature must have to be considered an electride.

electride_radius_min

The minimum ELF radius that a bare-electron feature must have to be considered an electride. The radius is defined as the distance from the feature to the closest atom minus that atoms radius. Atomic radii are determined by checking the EN difference between the atom and its nearest neighbors. If the EN difference is above 1.6, the average ionic radii for the atom is used. If the EN is below 1.6, the atomic radius is used.

radius_refine_method

The type of interpolation used to refine the ionic radius. This only effects the data stored in the graphs created using the ElfAnalyzerToolkit, not the planes used in the BadELF algorithm. However, it does effect the radius used to find electride features.

write_results

Whether or not to write the bifurcation plot and labeled structure generated by the BadELF algorithm to the assigned directory.

find_electrides

Exclusive to the BadELF workflows. This parameter indicates whether the algorithm should search for electrides. Reasons to set this as false may be that the user knows there is no electride character in the structure of interest or if the user would like to manually indicate the location of electrides.

Warning

If this parameter is set to false, the labeled_structure_up and/or labeled_structure_down parameters must be set.

find_electrides: true

find_electrides = true

find_electrides = True

fitness_field

(advanced users only) For evolutionary searches, this is the value that should be optimized. Specifically, it should minimize this value (lower value = better fitness). The default is energy_per_atom, but you may want to set this to a custom column in a custom database table.

ignore_low_pseudopotentials

Exclusive to BadELF workflows. Indicates whether the algorithm should throw an exception when the used pseudopotential didn't contain enough valence electrons. It is generally recommended to leave this as False as the results will likely be nonsense. Instead it is recommended to use pseudopotentials with more electrons, such as Vasp's GW PPs.

ignore_low_pseudopotentials: false

ignore_low_pseudopotentials = false

ignore_low_pseudopotentials = False

input_parameters

(experimental feature) Exclusive to customized.vasp.user-config. This is a list of parameters to pass to workflow_base.

is_restart

(experimental feature) This parameter indicates whether the calculation is a restarted workflow run. The default is False. If set to true, the workflow will go through the given directory (which must be provided) and determine where to resume.

directory: my-old-calc-folder
is_restart: true

directory = "my-old-calc-folder"
is_restart = true

directory = "my-old-calc-folder"
is_restart = True

labeled_structure_up

In BadELF workflows, if find_electrides is set to false, this parameter is a structure with "dummy" atoms representing non-atomic features in the spin-up system. Inputs options are the same as for the structure parameter.

Note

If a non-polarized ELF/charge density is used, this represents the labeled structure for the total system.

The required labels for each type of non-atomic feature are:

Feature Label
Covalent Bond "Z"
Lone-Pair "Lp"
Metal "M"
Electride "E"
Other Bare Electron "Le" 
labeled_structure_up: Ca2N_labeled_up.cif

labeled_structure_up = Ca2N_labeled_up.cif

labeled_structure_up: "Ca2N_labeled_up.cif"

labeled_structure_down

The equivalent setting to labeled_structure_up for the spin-down system.

labeled_structure_down: Ca2N_labeled_down.cif

labeled_structure_down = Ca2N_labeled_down.cif

labeled_structure_down: "Ca2N_labeled_down.cif"

max_atoms

For workflows that involve generating a supercell or random structure, this will be the maximum number of sites to allow in the generated structure(s). For example, an evolutionary search may set this to 10 atoms to limit the compositions & stoichiometries that are explored.

max_atoms: 10

max_atoms = 10

max_atoms = 10

max_path_length

For diffusion workflows, this is the maximum length allowed for a single path.

max_path_length: 3.5

max_path_length = 3.5

max_path_length = 3.5

max_stoich_factor

This is the maximum stoichiometric ratio that will be analyzed. In a binary system evolutionary search, this will only look at non-reduced compositions up to the max_stoich_factor. For example, this means Ca2N and max factor of 4 would only look up to Ca8N4 and skip any compositions with more atoms (e.g. Ca10N5 is skipped)

max_stoich_factor: 5

max_stoich_factor = 5

max_stoich_factor = 5

max_supercell_atoms

For workflows that involve generating a supercell, this will be the maximum number of sites to allow in the generated structure(s). For example, NEB workflows would set this value to something like 100 atoms to limit their supercell image sizes.

max_supercell_atoms: 100

max_supercell_atoms = 100

max_supercell_atoms = 100

max_structures

For workflows that generate new structures (and potentially run calculations on them), this will be the maximum number of structures allowed. The workflow will end at this number of structures regardless of whether the calculation/search is converged or not.

max_structures: 100

max_structures = 100

max_structures = 100

migrating_specie

This is the atomic species/element that will be moving in the analysis (typically NEB or MD diffusion calculations). Note, oxidation states (e.g. "Ca2+") can be used, but this requires your input structure to be oxidation-state decorated as well.

migrating_specie: Li

migrating_specie = "Li"

migrating_specie = "Li"

migration_hop

(advanced users only) The atomic path that should be analyzed. Inputs are anything compatible with the MigrationHop class of the simmate.toolkit.diffusion module. This includes:

  • MigrationHop object
  • a database entry in the MigrationHop table

(TODO: if you'd like full examples, please ask our team to add them)

migration_images

The full set of images (including endpoint images) that should be analyzed. Inputs are anything compatible with the MigrationImages class of the simmate.toolkit.diffusion module, which is effectively a list of structure inputs. This includes:

MigrationImages object

a list of Structure objects

a list of filenames (cif or POSCAR)

migration_images:
    - image_01.cif
    - image_02.cif
    - image_03.cif
    - image_04.cif
    - image_05.cif

migration_images = [
    "image_01.cif",
    "image_02.cif",
    "image_03.cif",
    "image_04.cif",
    "image_05.cif",
]

migration_images = [
    "image_01.cif",
    "image_02.cif",
    "image_03.cif",
    "image_04.cif",
    "image_05.cif",
]

min_atoms

This is the opposite of max_atoms as this will be the minimum number of sites allowed in the generate structure(s). See max_atoms for details.

min_supercell_atoms

This is the opposite of max_supercell_atoms as this will be the minimum number of sites allowed in the generated supercell structure.

min_supercell_vector_lengths

When generating a supercell, this is the minimum length for each lattice vector of the generated cell (in Angstroms). For workflows such as NEB, larger is better but more computationally expensive.

min_supercell_vector_lengths: 7.5

min_supercell_vector_lengths = 7.5

min_supercell_vector_lengths = 7.5

nfirst_generation

For evolutionary searches, no mutations or "child" individuals will be scheduled until this number of individuals have been calculated. This ensures we have a good pool of candidates calculated before we start selecting parents and mutating them.

nfirst_generation: 15

nfirst_generation = 15

nfirst_generation = 15

nimages

The number of images (or structures) to use in the analysis. This does NOT include the endpoint images (start/end structures). More is better, but computationally expensive. We recommend keeping this value odd in order to ensure there is an image at the midpoint.

nimages: 5

nimages = 5

nimages = 5

Danger

For apps such as VASP, your command parameter must use a number of cores that is divisible by nimages. For example, nimages=3 and command="mpirun -n 10 vasp_std > vasp.out" will fail because 10 is not divisible by 3.

nsteadystate

This parameter sets the number of individual workflows to be scheduled at once, effectively setting the queue size of an evolutionary search. The number of workflows run in parallel is determined by the number of Workers started. However, the nsteadystate value sets the maximum number of parallel runs as the queue size will never exceed this value. This parameter is closely tied with steadystate_sources.

nsteadystate: 50

nsteadystate = 50

nsteadystate = 50

nsteps

This parameter sets the total number of steps for the calculation. For instance, in molecular dynamics workflows, the simulation will stop after this many steps.

nsteps: 10000

nsteps = 10000

nsteps = 10000

percolation_mode

This parameter sets the percolating type to detect. The default is ">1d", which searches for percolating paths up to the max_path_length. Alternatively, this can be set to "1d" to stop unique pathway finding when 1D percolation is achieved.

percolation_mode: 1d

percolation_mode = "1d"

percolation_mode = "1d"

relax_bulk

This parameter determines whether the bulk structure (typically the input structure) should be relaxed before running the rest of the workflow.

relax_bulk: false

relax_bulk: false

relax_bulk: false

relax_endpoints

This parameter determines whether the endpoint structures for an NEB diffusion pathway should be relaxed before running the rest of the workflow.

relax_endpoints: false

relax_endpoints: false

relax_endpoints: false

run_id

This parameter is the id assigned to a specific workflow run/calculation. If not provided, this will be randomly generated. It is highly recommended to leave this at the default value. This id is based on unique-ids (UUID), so every id should be 100% unique and in a string format.

run_id: my-unique-id-123

run_id = "my-unique-id-123"

run_id = "my-unique-id-123"

search_id

(advanced users only) This parameter is the evolutionary search that this individual is associated with. This allows us to determine which Selector, Validator, and StopCondition should be used when creating and evaluating the individual. When running a search, this is set automatically when submitting a new flow.

selector_kwargs

(advanced users only) This parameter is a dictionary of extra conditions to use when initializing the selector class. MySelector(**selector_kwargs). This is closely tied with the selector_name parameter.

selector_name

(experimental feature; advanced users only) This parameter is the base selector class that should be used. The class will be initialized using MySelector(**selector_kwargs). The input should be given as a string.

Warning

Currently, we only support truncated selection, so this should be left at its default value.

separate_spin

In BadELF workflows, determines whether the spin-up and spin-down ELF/charge-density should be treated separately. Setting to false more closely matches the original BadELF paper, but relies on the assumption that the system is closed and the spin-up/spin-down are identical.

separate_spin: true

separate_spin = true

separate_spin = True

shared_feature_algorithm

For BadELF workflows, this parameter determines how shared ELF features such as covalent/metallic bonds are seperated from nearby atoms. Options are "zero-flux" or "voronoi" corresponding to bader-like and plane-like seperations.

covalent_bond_alg: zero-flux

covalent_bond_alg = "zero-flux"

covalent_bond_alg = "zero-flux"

shared_feature_separation_method

For BadELF workflows, this parameter determines how the charge in shared ELF features such as covalent/metallic bonds is divided and assigned to nearby atoms. Options are "pauling", "plane", or "equal".

Pauling: Divides charge based on the electronegativities of the neighboring atoms. The fraction of charge assigned is defined as Xi/(X0+X1+X2+...Xn) where Xi is the pauling electronegativity for each neighboring atom.

Equal: Divides charge equally to each neighboring atom.

Plane: Divides charge by placing a voronoi plane at the maximum of covalent bonds between atoms. May not work well for systems with metallic features not along atom bonds.

covalent_bond_alg: pauling

covalent_bond_alg = "pauling"

covalent_bond_alg = "pauling"

singleshot_sources

(experimental feature; advanced users only) This parameter is a list of structure sources that run once and never again. This includes generating input structures from known structures (from third-party databases), prototypes, or substituting known structures.

In the current version of simmate, these features are not enabled and this input should be ignored.

sleep_step

This parameter is the amount of time in seconds that the workflow will shutdown before restarting the cycle when there is a cycle within a workflow (such as iteratively checking the number of subworkflows submitted and updating results). For evolutionary searches, setting this to a larger value will save on computation resources and database load, so we recommend increasing it where possible.

run_id: 180

run_id = 180

sleep_step = 180  # 3 minutes

source

(experimental feature; advanced users only) This parameter indicates where the input data (and other parameters) came from. The source could be a number of things including a third party id, a structure from a different Simmate database table, a transformation of another structure, a creation method, or a custom submission by the user.

By default, this is a dictionary to account for the many different scenarios. Here are some examples of values used in this column:

# from a thirdparty database or separate table
source = {
    "database_table": "MatprojStructure",
    "database_id": "mp-123",
}

# from a random structure creator
source = {"creator": "PyXtalStructure"}

# from a templated structure creator (e.g. substituition or prototypes)
source = {
    "creator": "PrototypeStructure",
    "database_table": "AFLOWPrototypes",
    "id": 123,
}

# from a transformation
source = {
    "transformation": "MirrorMutation",
    "database_table":"MatprojStructure",
    "parent_ids": ["mp-12", "mp-34"],
}

Typically, the source is set automatically, and users do not need to update it.

standardize_structure

This parameter determines whether to standardize the structure during our setup(). This means running symmetry analysis on the structure to reduce the symmetry and convert it to some standardized form. There are three different forms to choose from and thus 3 different values that standardize_structure can be set to:

  • primitive: for the standard primitive unitcell
  • conventional: for the standard conventional unitcell
  • primitive-LLL: for the standard primitive unitcell that is then LLL-reduced
  • False: this is the default and will disable this feature

We recommend using primitive-LLL when the smallest possible and most cubic unitcell is desired.

We recommend using primitive when calculating band structures and ensuring we have a standardized high-symmetry path. Note,Existing band-structure workflows use this automatically.

To control the tolerances used to symmetrize the structure, you can use the symmetry_precision and angle_tolerance attributes.

By default, no standardization is applied.

standardize_structure: primitive-LLL

standardize_structure = "primitive-LLL"

standardize_structure = "primitive-LLL"

steadystate_source_id

(advanced users only) This parameter is the structure source that this individual is associated with. This allows us to determine how the new individual should be created. When running a search, this is set automatically when submitting a new flow.

steadystate_sources

(experimental feature; advanced users only) This parameter is a dictionary of sources that will be scheduled at a "steady-state", meaning there will always be a set number of individuals scheduled/running for this type of structure source. This should be defined as a dictionary where each is {"source_name": percent}. The percent determines the number of steady stage calculations that will be running for this at any given time. It will be a percent of the nsteadystate parameter, which sets the total number of individuals to be scheduled/running. For example, if nsteadystate=40 and we add a source of {"RandomSymStructure": 0.30, ...}, this means 0.25*40=10 randomly-created individuals will be running/submitted at all times. The source can be from either the toolkit.creator or toolkit.transformations modules.

singleshot_sources:
    RandomSymStructure: 0.30
    from_ase.Heredity: 0.30
    from_ase.SoftMutation: 0.10
    from_ase.MirrorMutation: 0.10
    from_ase.LatticeStrain: 0.05
    from_ase.RotationalMutation: 0.05
    from_ase.AtomicPermutation: 0.05
    from_ase.CoordinatePerturbation: 0.05

[singleshot_sources]
"RandomSymStructure": 0.30
"from_ase.Heredity": 0.30
"from_ase.SoftMutation": 0.10
"from_ase.MirrorMutation": 0.10
"from_ase.LatticeStrain": 0.05
"from_ase.RotationalMutation": 0.05
"from_ase.AtomicPermutation": 0.05
"from_ase.CoordinatePerturbation": 0.05

singleshot_sources = {
    "RandomSymStructure": 0.30,
    "from_ase.Heredity": 0.30,
    "from_ase.SoftMutation": 0.10,
    "from_ase.MirrorMutation": 0.10,
    "from_ase.LatticeStrain": 0.05,
    "from_ase.RotationalMutation": 0.05,
    "from_ase.AtomicPermutation": 0.05,
    "from_ase.CoordinatePerturbation": 0.05,
}

Note: if your percent values do not sum to 1, they will be rescaled. When calculating percent*nsteadystate, the value will be rounded to the nearest integer.

We are moving towards accepting kwargs or class objects as well, but this is not yet allowed. For example, anything other than percent would be treated as a kwarg:

[singleshot_sources.RandomSymStructure]
percent: 0.30
spacegroups_exclude: [1, 2, 3]
site_generation_method: "MyCustomMethod"

stop_conditions

(experimental feature; advanced users only) This parameter provides a set of stop conditions that will be checked periodically to determine if a FixedComposition evolutionary search should be stopped. It should be defined as a dictionary where each key is the string name of a StopCondition and the value is any kwargs that are needed to instantiate the class.

stop_conditions:
    BasicStopConditions:
        max_structures: 1000
        min_structures_exact: 100
        convergence_cutoff: 0.001
        best_survival_cutoff: 100
    ExpectedStructure:
        structure: NaCl.cif

[stop_conditions.BasicStopConditions]
max_structures = 1000
min_structures_exact = 100
convergence_cutoff = 0.001
best_survival_cutoff = 100
[stop_conditions.ExpectedStructure]
structure: NaCl.cif

stop_conditions = {
    "BasicStopConditions": {
    "max_structures": 1000,
    "min_structures_exact": 100,
    "convergence_cutoff": 0.001
    "best_survival_cutoff": 100
    },
    "ExpectedStructure": {
    "structure": "NaCl.cif"
    },
}

Currently, only the BasicStopConditions and ExpectedStructure stop conditions are supported. They each have the following subparameters

BasicStopConditions The BasicStopConditions are those that are important to all searches. If this StopCondition is not provided, defaults will be constructed.

max_structures

The maximum number of structures generated. The search will end at this number of structures regardless of if the search has converged. If not provided, the workflow estimates a reasonable value based on the number of atoms.

Warning

min_structure_exact takes priority over this setting, so it is possible for your search to exceed your maximum number of structures. If you want max_structures to have absolute control, you can set min_structure_exact to 0.

min_structures_exact

The minimum number of structures that must be calculated with exactly matching nsites as specified in fixed-composition. If not provided, the workflow estimates a reasonable value based on the number of atoms.

convergence_cutoff

The search will be considered converged when the best structure is not changing by this amount (in eV). In order to officially signal the end of the search, the best structure must survive within this convergence limit for a specific number of new individuals -- this is controlled by the best_survival_cutoff. The default of 1meV is typically sufficient and does not need to be changed. More often, users should update best_survival_cutoff instead.

best_survival_cutoff

The search will stop when the best individual remains unbeaten for this number of new individuals.

To account for similar structures (e.g., identical structures with minor energy differences), structures within the convergence_cutoff parameter (e.g., +1meV) are not considered when counting historical structures. This helps to prevent the search from continuing in cases where the search is likely already converged but making <0.1meV improvements. If not provided, the workflow estimates a reasonable value based on the number of atoms.

ExpectedStructure The ExpectedStructure stop condition will compare all structures generated in the search to a provided structure and immediately halt the search if there is a match.

expected_structure

When a structure is found in the search that matches this structure, the search will be stopped. The allowed inputs follow the same scheme as in the Structure parameter.

structure

The crystal structure to be used for the analysis. The input can be anything compatible with the Structure toolkit class. Accepted inputs include:

a filename (cif or poscar) (recommended)

structure: NaCl.cif

structure = NaCl.cif

structure="NaCl.cif"

a dictionary that points to a database entry. 

# example 1
structure:
    database_table: MatprojStructure
    database_id: mp-123

# example 2
structure:
    database_table: StaticEnergy
    database_id: 50

# example 3
structure:
    database_table: Relaxation
    database_id: 50
    structure_field: structure_final

# example 1
[structure]
database_table: MatprojStructure
database_id: mp-123

# example 2
[structure]
database_table: StaticEnergy
database_id: 50

# example 3
[structure]
database_table: Relaxation
database_id: 50
structure_field: structure_final

# example 1
structure={
    "database_table": "MatprojStructure",
    "database_id": "mp-123",
}

# example 2
structure={
    "database_table": "StaticEnergy",
    "database_id": 50,
}

# example 3
structure={
    "database_table": "Relaxation",
    "database_id": 50,
    "structure_field": "structure_final",
}

Note

instead of database_id, you can also use the run_id or directory to indicate which entry to load. Further, if the database table is linked to multiple structures (e.g. relaxations have a structure_start and structure_final), then you can also add the structure_field to specify which to choose.

a Structure object (best for advanced logic)

from simmate.toolkit import Structure

structure = Structure(
    lattice=[
        [2.846, 2.846, 0.000],
        [2.846, 0.000, 2.846],
        [0.000, 2.846, 2.846],
    ],
    species=["Na", "Cl"],
    coords=[
        [0.5, 0.5, 0.5],
        [0.0, 0.0, 0.0],
    ],
    coords_are_cartesian=False,
)

a Structure database object

structure = ExampleTable.objects.get(id=123)

json/dictionary serialization from pymatgen

subworkflow_kwargs

This parameter is a dictionary of parameters to pass to each subworkflow run. For example, the workflow will be ran as subworkflow.run(**subworkflow_kwargs). Note, many workflows that use this argument will automatically pass information that is unique to each call (such as structure).

subworkflow_kwargs:
    command: mpirun -n 4 vasp_std > vasp.out
    compress_output: true

[subworkflow_kwargs]
command = "mpirun -n 4 vasp_std > vasp.out"
compress_output = true

subworkflow_kwargs=dict(
    command="mpirun -n 4 vasp_std > vasp.out",
    compress_output=True,
)

subworkflow_name

This parameter is the name of workflow that used to evaluate structures generated. Any workflow that is registered and accessible via the get_workflow utility can be used instead. If you wish to submit extra arguments to each workflow run, you can use the subworkflow_kwargs parameter.

subworkflow_name: relaxation.vasp.staged

subworkflow_name = "relaxation.vasp.staged"

subworkflow_name = "relaxation.vasp.staged"

supercell_end

This parameter is the endpoint image supercell to use. This is really just a structure parameter under a different name, so everything about the structure parameter also applies here.

supercell_start

This parameter is the starting image supercell to use. This is really just a structure parameter under a different name, so everything about the structure parameter also applies here.

symmetry_precision

If standardize_structure=True, then this is the cutoff value used to determine if the sites are symmetrically equivalent. (in Angstroms)

symmetry_precision: 0.1

symmetry_precision = 0.1

tags

When submitting workflows via the run_cloud command, tags are 'labels' that help control which workers are allowed to pick up and run the submitted workflow. Workers should be started with matching tags in order for these scheduled flows to run.

When no tags are set, the following default tags will be used for a Simmate workflow:

  • simmate (this is the default worker tag as well)
  • the workflow's type name
  • the workflow's app name
  • the full workflow name

For example, the static-energy.vasp.matproj would have the following tags: 

- simmate
- static-energy
- vasp
- static-energy.vasp.matproj

To override these default tags, use the following:

tags:
    - my-tag-01
    - my-tag-02

tags = ["my-tag-01", "my-tag-02"]

tags = ["my-tag-01", "my-tag-02"]

Warning

When you have a workflow that is submitting many smaller workflows (such as structure-prediction workflows), make sure you set the tags in the subworkflow_kwargs settings: 

subworkflow_kwargs:
    tags:
        - my-tag-01
        - my-tag-02

Bug

Filtering tags does not always work as expected in SQLite3 because a worker with my-tag will incorrectly grab jobs like my-tag-01 and my-tag-02. This issue is known by both Django and SQLite3. Simmate addresses this issue by requiring all tags to be 7 characters long AND fully lowercase when using SQLite3.

temperature_end

For molecular dynamics simulations, this is the temperature to end the simulation at (in Kelvin). This temperature will be reached through a linear transition from the temperature_start parameter.

temperature_end: 1000

temperature_end = 1000

temperature_start

For molecular dynamics simulations, this is the temperature to begin the simulation at (in Kelvin).

temperature_start: 250

temperature_start = 250

temperature_start = 250

threads

For BadELF algorithms, determines how many threads will be used during pybader calculations. If None this will be automatically set to 90% of available threads.

threads: 8

threads = 8

threads = 8

time_step

For molecular dynamics simulations, this is time time between each ionic step (in femtoseconds).

time_step: 1.5

time_step = 1.5

time_step = 1.5

updated_settings

(experimental feature) Unique to customized.vasp.user-config. This is a list of parameters to update the workflow_base with. This often involves updating the base class attributes.

vacancy_mode

For NEB and diffusion workfows, this determines whether vacancy or interstitial diffusion is analyzed. Default of True corresponds to vacancy-based diffusion.

vacancy_mode: false

vacancy_mode = false

vacancy_mode = False

validator_kwargs

(advanced users only) This parameter is a dictionary of extra conditions to use when initializing the validator class. MyValidator(**validator_kwargs). This is closely tied with the validator_name parameter.

validator_name

(experimental feature; advanced users only) This parameter is the base validator class that should be used. The class will be initialized using MyValidator(**validator_kwargs). The input should be given as a string.

Warning

Currently, we only support CrystallNNFingerprint validation, so this should be left at its default value.

workflow_base

(experimental feature) Unique to customized.vasp.user-config. This is the base workflow to use when updating critical settings.

write_electride_files

This parameter is unique to BadELF workflows. If set to True and ELFCAR and CHGCAR will be written containing only the values where the volume belongs to an electride and zero elsewhere.

write_electride_files: false

write_electride_files = false

write_electride_files = False

write_ion_radii

This parameter is unique to BadELF workflows. If set to True, the ionic radii of each atom determined from the ELF will be written to a summary file.

write_ion_radii: true

write_ion_radii = true

write_ion_radii = True

write_labeled_structure

This parameter is unique to BadELF workflows. If set to True, the structure labeled with non-atomic ELF features (e.g. bare electrons, covalent bonds, metal bonds) will be written to a summary file.

write_labeled_structure: true

write_labeled_structure = true

write_labeled_structure = True

write_summary_files

This parameter determines whether or not to write output files. For some workflows, writing output files can cause excessive load on the database and possibly make the calculation IO bound. In cases such as this, you can set this to False.

write_summary_files: false

write_summary_files = false

write_summary_files = False

Tip

Beginners can often ignore this setting. This is typically only relevant in a setup where you have many computational resources and have many evolutionary searches (>10) running at the same time.