xtb_step package#

Submodules#

xtb_step.energy module#

Non-graphical part of the Energy step in an xTB flowchart.

class xtb_step.energy.Energy(flowchart=None, title='Energy', extension=None, logger=<Logger xtb_step.energy (WARNING)>)[source]#

Bases: Substep

Run an xTB single-point energy.

See also

Substep, EnergyParameters, TkEnergy

analyze(indent='', data=None, table=None, P=None)[source]#

Print the results as a tabulated summary in step.out.

Follows the Gaussian step pattern: subclasses build up a single table dict and pass it to super().analyze(). The base Energy class adds the basic energy/HOMO/LUMO/dipole rows and prints the table at the end. This way, an Optimization or Frequencies substep can prepend its own rows (e.g. converged- energy, ZPE) in a single, ordered table.

Parameters:

indent (str) – Extra indentation (currently unused; self.indent controls the final wrap indent).
data (dict) – Results from _collect_results and any subclass extensions.
table (dict, optional) – A dict with three lists – "Property", "Value", "Units" – that subclasses have already populated. If None, a fresh empty table is created here.
P (dict, optional) – The current parameter values. Not directly used in this base implementation but accepted so subclasses can pass it.

description_text(P=None, calculation_type='single-point energy')[source]#

Create the text description of what this step will do.

Note: charge and spin multiplicity are NOT mentioned here. They are properties of the system, not of the calculation, and the SEAMM convention is to not echo them at the step level.

property git_revision#: The git version of this module.

run(extra_args=None)[source]#

Run the Energy step.

Parameters:: extra_args (list of str, optional) – Additional xtb command-line arguments to append after the base arguments. Used by Optimization and Frequencies subclasses to inject --opt / --ohess flags. Defaults to none.
Returns:: The next node object in the flowchart.
Return type:: seamm.Node

property version#: The semantic version of this module.

xtb_step.energy_parameters module#

Control parameters for the xTB Energy step in a SEAMM flowchart.

class xtb_step.energy_parameters.EnergyParameters(defaults={}, data=None)[source]#

Bases: Parameters

The control parameters for an xTB Energy substep.

These parameters are inherited by Optimization (which adds optimizer controls) and Frequencies (which adds Hessian controls). Anything that is common to all substeps – method, accuracy, solvation – lives here.

Note that net charge and spin multiplicity are NOT parameters of this step. They are properties of the configuration, accessed at run time via configuration.charge and configuration.spin_multiplicity. This matches the convention throughout SEAMM: O2 (S=0), O2 triplet, and O2+ are different chemical species, not different parameter settings on the same calculation.

parameters = {'accuracy': {'default': 1.0, 'default_units': '', 'description': 'Accuracy:', 'enumeration': (), 'format_string': '.3f', 'help_text': 'The xTB accuracy multiplier (xtb --acc). Lower values give tighter integral and SCC convergence; the default 1.0 is appropriate for most calculations. Useful range: roughly 0.0001 to 1000.', 'kind': 'float'}, 'extra keywords': {'default': [], 'default_units': '', 'description': 'Extra keywords', 'enumeration': (), 'format_string': '', 'help_text': 'Extra keywords to append to those from the GUI. This allows you to add to and override the GUI.', 'kind': 'list'}, 'method': {'default': 'GFN2-xTB', 'default_units': '', 'description': 'xTB method:', 'enumeration': ('GFN2-xTB', 'GFN1-xTB', 'GFN0-xTB', 'GFN-FF'), 'format_string': 's', 'help_text': 'The xTB Hamiltonian or force-field to use. GFN2-xTB is the default, recommended self-consistent method (Bannwarth, Ehlert, Grimme, JCTC 2019). GFN1-xTB is the earlier self-consistent method. GFN0-xTB is non-SCF and useful for rough screening or as a robust starting point. GFN-FF is a generic force field automatically parameterized by xTB.', 'kind': 'enum'}, 'results': {'default': {}, 'default_units': '', 'description': 'results', 'enumeration': (), 'format_string': '', 'help_text': 'The results to save to variables or in tables.', 'kind': 'dictionary'}, 'solvation model': {'default': 'none', 'default_units': '', 'description': 'Implicit solvation:', 'enumeration': ('none', 'ALPB', 'GBSA', 'CPCM-X'), 'format_string': 's', 'help_text': 'Implicit solvation model. ALPB (analytical linearized Poisson-Boltzmann, Ehlert et al. JCTC 2021) is the current recommended default and is parametrized for GFN1-xTB, GFN2-xTB, and GFN-FF (not GFN0-xTB). GBSA is the legacy generalized-Born model. CPCM-X uses the Minnesota Solvation Database.', 'kind': 'enum'}, 'solvent': {'default': 'H2O', 'default_units': '', 'description': 'Solvent:', 'enumeration': ('acetone', 'acetonitrile', 'benzene', 'CH2Cl2', 'CHCl3', 'CS2', 'DMF', 'DMSO', 'ether', 'H2O', 'methanol', 'n-hexane', 'THF', 'toluene'), 'format_string': 's', 'help_text': 'The solvent for implicit solvation. Available solvents depend on the solvation model. Some solvents are method-specific in xTB (e.g. DMF and n-hexane are GFN2-only, benzene is GFN1-only); xtb will issue a warning at runtime if an unsupported combination is selected.', 'kind': 'enum'}}#

xtb_step.energy_step module#

class xtb_step.energy_step.EnergyStep(flowchart=None, gui=None)[source]#

Bases: object

Helper class needed for the stevedore integration.

This must provide a description() method that returns a dict containing a description of this node, and create_node() and create_tk_node() methods for creating the graphical and non-graphical nodes.

The dictionary for the description is the class variable just below these comments. The felds are as follows:

my_description{str, str}
A human-readable description of this step. It can be several lines long, and needs to be clear to non-expert users. It contains the following keys: description, group, name.

my_description[“description”]tuple
A description of the Energy step. It must be clear to non-experts.

my_description[“group”]str
Which group in the menus to put this step. If the group does not exist it will be created. Common groups are “Building”, “Control”, “Custom”, “Data”, and “Simulations”.

my_description[“name”]str
The name of this step, to be displayed in the menus.

create_node(flowchart=None, **kwargs)[source]#

Create and return the new node object.

Parameters:

flowchart (seamm.Node) – A non-graphical SEAMM node
**kwargs (keyword arguments) – Various keyword arguments such as title, namespace or extension representing the title displayed in the flowchart, the namespace for the plugins of a subflowchart and the extension, respectively.

Return type:

Energy

create_tk_node(canvas=None, **kwargs)[source]#

Create and return the graphical Tk node object.

Parameters:

canvas (tk.Canvas) – The Tk Canvas widget
**kwargs (keyword arguments) – Various keyword arguments such as tk_flowchart, node, x, y, w, h representing a graphical flowchart object, a non-graphical node for a step, and dimensions of the graphical node.

Return type:

TkEnergy

description()[source]#

Return a description of what this step does.

Returns:: description
Return type:: dict(str, str)

my_description = {'description': 'An interface for Energy', 'group': 'Calculations', 'name': 'Energy'}#

xtb_step.frequencies module#

Non-graphical part of the Frequencies step in an xTB flowchart.

class xtb_step.frequencies.Frequencies(flowchart=None, title='Frequencies', extension=None, logger=<Logger xtb_step.frequencies (WARNING)>)[source]#

Bases: Optimization

Run an xTB Hessian / vibrational frequency calculation.

By default this uses --ohess <level> (optimize-then-Hessian), which is what xtb’s documentation recommends since Hessians on unoptimized geometries are not physically meaningful. The user can disable the initial optimization, in which case --hess is used and the input geometry is assumed to be at a stationary point.

See also

Optimization, Energy, Substep, FrequenciesParameters, TkFrequencies

analyze(indent='', data=None, table=None, P=None)[source]#

Augment the data dict with thermo / freq results, then defer to Energy.analyze() which formats the table.

Energy.run() calls self.analyze(data=..., P=...) BEFORE we have parsed the thermo block from xtb.out. We re-parse here so the thermo rows are available when the table is built.

description_text(P=None, calculation_type=None)[source]#: Override with frequency-specific text.

run(extra_args=None)[source]#

Run the Frequencies step.

We bypass Optimization.run() (which always inserts --opt) and go straight to Energy.run() with the appropriate Hessian flag.

xtb_step.frequencies_parameters module#

Control parameters for the xTB Frequencies step in a SEAMM flowchart.

class xtb_step.frequencies_parameters.FrequenciesParameters(defaults={}, data=None)[source]#

Bases: OptimizationParameters

The control parameters for an xTB Frequencies substep.

Inherits everything from OptimizationParameters because xtb’s --ohess (the recommended frequency runtype) is an optimize-then- Hessian. When the user disables the initial optimization, the optimization-level and structure-handling parameters are simply ignored by the run() method.

Adds:

optimize first – whether to optimize the geometry before the Hessian (--ohess if yes, --hess if no).
temperature – the temperature for the thermochemistry table.
pressure – the pressure for the thermochemistry table.

parameters = {'optimize first': {'default': 'yes', 'default_units': '', 'description': 'Optimize first:', 'enumeration': ('yes', 'no'), 'format_string': 's', 'help_text': "Whether to optimize the geometry before computing the Hessian. 'yes' uses xtb's --ohess (recommended -- Hessians on unoptimized geometries are not physically meaningful). 'no' uses --hess and assumes the input geometry is already at a stationary point.", 'kind': 'enum'}, 'pressure': {'default': 1.0, 'default_units': 'atm', 'description': 'Pressure:', 'enumeration': (), 'format_string': '.3f', 'help_text': "Pressure for the thermochemistry table. Default 1 atm. Note that xtb's thermo treatment uses the ideal-gas approximation; pressure enters only via the standard-state correction.", 'kind': 'float'}, 'temperature': {'default': 298.15, 'default_units': 'K', 'description': 'Temperature:', 'enumeration': (), 'format_string': '.2f', 'help_text': 'Temperature for the thermochemistry table. Default 298.15 K (standard conditions).', 'kind': 'float'}}#: Local parameters added on top of OptimizationParameters.parameters.

xtb_step.frequencies_step module#

class xtb_step.frequencies_step.FrequenciesStep(flowchart=None, gui=None)[source]#

Bases: object

Helper class needed for the stevedore integration.

This must provide a description() method that returns a dict containing a description of this node, and create_node() and create_tk_node() methods for creating the graphical and non-graphical nodes.

The dictionary for the description is the class variable just below these comments. The felds are as follows:

my_description{str, str}
A human-readable description of this step. It can be several lines long, and needs to be clear to non-expert users. It contains the following keys: description, group, name.

my_description[“description”]tuple
A description of the Frequencies step. It must be clear to non-experts.

my_description[“group”]str
Which group in the menus to put this step. If the group does not exist it will be created. Common groups are “Building”, “Control”, “Custom”, “Data”, and “Simulations”.

my_description[“name”]str
The name of this step, to be displayed in the menus.

create_node(flowchart=None, **kwargs)[source]#

Create and return the new node object.

Parameters:

flowchart (seamm.Node) – A non-graphical SEAMM node
**kwargs (keyword arguments) – Various keyword arguments such as title, namespace or extension representing the title displayed in the flowchart, the namespace for the plugins of a subflowchart and the extension, respectively.

Return type:

Frequencies

create_tk_node(canvas=None, **kwargs)[source]#

Create and return the graphical Tk node object.

Parameters:

canvas (tk.Canvas) – The Tk Canvas widget
**kwargs (keyword arguments) – Various keyword arguments such as tk_flowchart, node, x, y, w, h representing a graphical flowchart object, a non-graphical node for a step, and dimensions of the graphical node.

Return type:

TkFrequencies

description()[source]#

Return a description of what this step does.

Returns:: description
Return type:: dict(str, str)

my_description = {'description': 'An interface for Frequencies', 'group': 'Calculations', 'name': 'Frequencies'}#

xtb_step.installer module#

xtb_step.metadata module#

This file contains metadata describing the results from xTB.

The dictionary metadata is consumed by SEAMM’s store_results machinery on seamm.Node to:

describe the computational models (Hamiltonians) the plug-in supports;
enumerate any keywords the plug-in defines (xTB is controlled almost entirely by command-line flags, so this section is small);
enumerate the results the plug-in can produce, with their dimensionality, units, the property name in the SEAMM database, and which sub-step (calculation) generates them.

xtb_step.optimization module#

Non-graphical part of the Optimization step in an xTB flowchart.

class xtb_step.optimization.Optimization(flowchart=None, title='Optimization', extension=None, logger=<Logger xtb_step.optimization (WARNING)>)[source]#

Bases: Energy

Run an xTB geometry optimization (ANCopt).

Inherits from Energy; reuses the parameter set, the executor invocation, the JSON parsing, and the citation logic. Adds the --opt LEVEL flag and post-processing of the optimized geometry.

See also

Energy, Substep, OptimizationParameters, TkOptimization

description_text(P=None, calculation_type=None)[source]#: Override Energy’s description with optimization-specific text.

run(extra_args=None)[source]#: Run the Optimization step.

xtb_step.optimization_parameters module#

Control parameters for the xTB Optimization step in a SEAMM flowchart.

class xtb_step.optimization_parameters.OptimizationParameters(defaults={}, data=None)[source]#

Bases: EnergyParameters

The control parameters for an xTB Optimization substep.

Inherits the method/charge/multiplicity/accuracy/solvation parameters from EnergyParameters and adds the optimizer-specific knobs.

OPT_LEVELS = ('crude', 'sloppy', 'loose', 'lax', 'normal', 'tight', 'vtight', 'extreme')#: Optimization level enumeration. xtb’s --opt LEVEL accepts these predefined criterion sets (energy and gradient convergence thresholds), per the xTB documentation https://xtb-docs.readthedocs.io/en/latest/optimization.html

parameters = {'max iterations': {'default': 'default', 'default_units': '', 'description': 'Maximum iterations:', 'enumeration': ('default',), 'format_string': 'd', 'help_text': "Maximum number of optimization iterations. Use 'default' to let xtb decide (typically scales with system size).", 'kind': 'integer'}, 'optimization level': {'default': 'normal', 'default_units': '', 'description': 'Optimization level:', 'enumeration': ('crude', 'sloppy', 'loose', 'lax', 'normal', 'tight', 'vtight', 'extreme'), 'format_string': 's', 'help_text': "The convergence criteria preset for xtb's ANCopt geometry optimizer. 'normal' is the default. 'tight' or tighter is recommended before a frequency calculation.", 'kind': 'enum'}, 'structure handling': {'default': 'Overwrite the current configuration', 'default_units': '', 'description': 'Optimized structure:', 'enumeration': ('Overwrite the current configuration', 'Add a new configuration', 'Add a new system', 'Discard the optimized structure'), 'format_string': 's', 'help_text': "What to do with the optimized geometry. 'Overwrite' replaces the current configuration's coordinates in place. 'Add a new configuration' keeps the input geometry and stores the optimized one as a new configuration in the same system. 'Add a new system' creates a fresh system entirely. 'Discard' keeps the input unchanged and just records the energy.", 'kind': 'enum'}}#: Local parameters added on top of EnergyParameters.parameters.

xtb_step.optimization_step module#

class xtb_step.optimization_step.OptimizationStep(flowchart=None, gui=None)[source]#

Bases: object

Helper class needed for the stevedore integration.

This must provide a description() method that returns a dict containing a description of this node, and create_node() and create_tk_node() methods for creating the graphical and non-graphical nodes.

The dictionary for the description is the class variable just below these comments. The felds are as follows:

my_description{str, str}
A human-readable description of this step. It can be several lines long, and needs to be clear to non-expert users. It contains the following keys: description, group, name.

my_description[“description”]tuple
A description of the Optimization step. It must be clear to non-experts.

my_description[“group”]str
Which group in the menus to put this step. If the group does not exist it will be created. Common groups are “Building”, “Control”, “Custom”, “Data”, and “Simulations”.

my_description[“name”]str
The name of this step, to be displayed in the menus.

create_node(flowchart=None, **kwargs)[source]#

Create and return the new node object.

Parameters:

flowchart (seamm.Node) – A non-graphical SEAMM node
**kwargs (keyword arguments) – Various keyword arguments such as title, namespace or extension representing the title displayed in the flowchart, the namespace for the plugins of a subflowchart and the extension, respectively.

Return type:

Optimization

create_tk_node(canvas=None, **kwargs)[source]#

Create and return the graphical Tk node object.

Parameters:

canvas (tk.Canvas) – The Tk Canvas widget
**kwargs (keyword arguments) – Various keyword arguments such as tk_flowchart, node, x, y, w, h representing a graphical flowchart object, a non-graphical node for a step, and dimensions of the graphical node.

Return type:

TkOptimization

description()[source]#

Return a description of what this step does.

Returns:: description
Return type:: dict(str, str)

my_description = {'description': 'An interface for Optimization', 'group': 'Calculations', 'name': 'Optimization'}#

xtb_step.substep module#

A base class for substeps of the xTB plug-in.

All substeps (Energy, Optimization, Frequencies, and any future substeps such as MD or metadynamics) inherit from Substep. This base class holds the machinery that is genuinely common across substeps:

Module-level constants for method <-> CLI flag mapping and the supported solvent list per solvation model.
A periodicity check that refuses periodic input with a clear message.
A writer for the coord.xyz input file consumed by xtb.
A builder for the common parts of the xtb command line (method, charge, multiplicity, accuracy, solvation, JSON output).
A wrapper around the SEAMM executor for invoking the xtb binary.
A JSON-output parser for xtbout.json.
A text parser for the few quantities not exposed in the JSON (notably the thermochemistry block from Hessian runs).

It deliberately does NOT bake in any assumption that a substep is energy-related, so an MD substep, for example, can inherit directly from Substep without going through Energy.

xtb_step.substep.METHODS = ('GFN2-xTB', 'GFN1-xTB', 'GFN0-xTB', 'GFN-FF')#: All methods we expose. Used as the parameter enumeration.

xtb_step.substep.METHOD_TO_CLI = {'GFN-FF': ['--gfnff'], 'GFN0-xTB': ['--gfn', '0'], 'GFN1-xTB': ['--gfn', '1'], 'GFN2-xTB': ['--gfn', '2']}#: User-facing method label -> list of xtb CLI arguments.

xtb_step.substep.SOLVATION_MODELS = ('none', 'ALPB', 'GBSA', 'CPCM-X')#: Solvation models we expose. "none" means no implicit solvation.

xtb_step.substep.SOLVATION_MODEL_TO_FLAG = {'ALPB': '--alpb', 'CPCM-X': '--cpcmx', 'GBSA': '--gbsa', 'none': None}#: Solvation model labels -> CLI flag.

class xtb_step.substep.Substep(flowchart=None, title='no title', extension=None, logger=<Logger xtb_step.substep (WARNING)>, module='xtb_step.substep')[source]#

Bases: Node

Common base class for substeps of the xTB plug-in.

Subclasses are expected to:

Set self._calculation to a short identifier (e.g. "Energy").
Set self._model once the active xTB Hamiltonian is known (e.g. "GFN2-xTB").
Provide their own parameters, description_text, run, and analyze methods.

The helpers below are available to all subclasses:

check_periodicity() – raise on periodic input.
write_coord_xyz() – write the molecule to coord.xyz.
base_xtb_args() – build the common part of the xtb CLI.
run_xtb() – invoke xtb via the SEAMM executor.
read_xtbout_json() – parse xtbout.json.
parse_thermo_block() – pull the thermochemistry table from the text output.

base_xtb_args(P, configuration)[source]#

Build the parts of the xtb CLI common to all substeps.

Charge and spin multiplicity are read from the configuration, not from P. This matches the SEAMM convention (charge and spin are properties of the chemical system, not of the calculation) and lets high-throughput flowcharts loop over systems without per- system parameter editing.

Parameters:

P (dict) – The current parameter values (from parameters.current_values_to_dict()). Expected keys include method, accuracy, solvation model, solvent.
configuration (molsystem.Configuration) – Provides the net charge and spin multiplicity for the system.

Returns:

The argument list to prepend to the substep-specific arguments. Always begins with the coordinate filename (coord.xyz).

Return type:

list of str

check_periodicity(configuration)[source]#

Refuse periodic input with a clear, user-visible message.

xTB’s PBC support is limited and is out of scope for v1 of this plug-in. If the configuration is periodic, this method prints a message via the step printer and raises RuntimeError so the flowchart stops cleanly.

property global_options#: Pass-through to the parent (top-level xTB step)’s global options.

property header#: A printable header for this section of output.

property input_only#: Whether to write the input only, not run xtb.

property is_runable#: Indicate whether this substep runs xtb or just adds input.

property options#: Pass-through to the parent (top-level xTB step)’s options.

parse_thermo_block(stdout)[source]#

Pull thermochemistry quantities from xtb stdout.

xtb’s Hessian runs print a :: THERMODYNAMIC :: summary block and a per-temperature table. We extract the key scalars at a single temperature here. The format is:

:: total free energy   -41.971849822766 Eh ::
:: total energy        -42.153937303642 Eh ::
:: zero point energy     0.182087480876 Eh ::
:: G(RRHO) w/o ZPVE      0.000000000000 Eh ::
:: G(RRHO) contrib.      0.182087480876 Eh ::

and a temperature line like:

T/K   H(0)-H(T)+PV   H(T)/Eh   T*S/Eh   G(T)/Eh
298.15  ...   ...   ...   ...

Energies are converted from E_h (xtb’s native unit) to kJ/mol so the values returned here are chemist-friendly. The entropy contribution is reported both as entropy_term (T*S in kJ/mol, the form xtb prints) and as entropy (S in J/mol/K, the form that appears in standard tables and chemistry papers).

Parameters:: stdout (str) – The captured stdout (or contents of an xtb.out file) from a Hessian run.
Returns:: Possibly containing keys: total_free_energy, zero_point_energy, temperature, enthalpy, entropy_term, entropy, gibbs_free_energy. All energies in kJ/mol, entropy in J/mol/K, temperature in K. Missing entries indicate parsing failed for that quantity; callers should handle absence gracefully.
Return type:: dict

read_xtbout_json(directory=None, filename='xtbout.json')[source]#

Read the xtb JSON output produced by --json.

xTB writes xtbout.json in the working directory when invoked with --json. The schema includes (at least, in recent releases): "total energy", "HOMO-LUMO gap / eV", "electronic energy", "dipole / a.u.", "partial charges", plus method-specific fields. The exact set varies between xtb versions; callers should treat the returned dict as best-effort.

Parameters:

directory (pathlib.Path, optional) – The directory containing the file. Defaults to self.directory.
filename (str) – The JSON filename to read. Defaults to xtbout.json.

Returns:

The parsed JSON data, or an empty dict if the file is missing or unreadable.

Return type:

dict

run_xtb(args, return_files=None, env=None)[source]#

Run xtb via the SEAMM executor.

Reads the per-plug-in xtb.ini from the SEAMM root directory, falling back to the bundled data/xtb.ini template if the user does not yet have one. Then dispatches the run through the flowchart’s executor (which handles conda/local/modules/docker transparently).

write_coord_xyz(directory, configuration, filename='coord.xyz')[source]#: Write the configuration to a standard XYZ file for xtb.

xtb_step.substep.solvent_choices_for(model)[source]#

Return the supported solvent enumeration for a solvation model.

Parameters:: model (str) – The solvation-model label (one of SOLVATION_MODELS).
Returns:: The list of solvent names we expose to the user. Empty for “none”.
Return type:: tuple of str

xtb_step.tk_energy module#

The graphical part of an xTB Energy step.

This class is also the base class for TkOptimization and TkFrequencies. It owns the “energy frame”, which holds the energy / Hamiltonian / solvation widgets common to all xTB substeps. Subclasses inherit create_dialog, reset_dialog, and reset_energy_frame unchanged, and just add their own frames below the energy frame – exactly the MOPAC TkEnergy / TkOptimization pattern.

The dialog hides the solvent widget when solvation model is "none" and indents it under the solvation row when shown.

class xtb_step.tk_energy.TkEnergy(tk_flowchart=None, node=None, canvas=None, x=None, y=None, w=200, h=50)[source]#

Bases: TkNode

The graphical part of an Energy step in a flowchart.

Subclasses (TkOptimization, TkFrequencies, …) inherit the energy-frame layout and the conditional solvent display, and add their own frames in their own create_dialog / reset_dialog.

create_dialog(title='xTB Energy')[source]#

Create the dialog and the energy frame.

Subclasses should call super().create_dialog(title=...) first and then add their own frames into self["frame"].

reset_dialog(widget=None)[source]#

Top-level layout. Subclasses override and call super().

Returns:: The next free row in self["frame"], so subclasses can grid their additional frames below the energy frame.
Return type:: int

reset_energy_frame(widget=None)[source]#

Layout the widgets inside the energy frame.

The solvent widget is shown only when solvation model is not "none". To get the indentation right despite the varying widths of the main-column labels, we use the Gaussian-step pattern: layout column 0 widgets and column 1 (indented) widgets separately, align_labels on each, and then size column 0 to w1 - w2 + 30 so the column-1 label starts at roughly the position of the column-0 value.

right_click(event)[source]#: Right-click context menu.

xtb_step.tk_frequencies module#

The graphical part of an xTB Frequencies step.

Inherits from TkOptimization to reuse the energy frame and the optimization frame, since xtb’s recommended frequency invocation is --ohess (optimize-then-Hessian). Adds its own “frequencies frame” below for the frequency / thermochemistry-specific parameters.

class xtb_step.tk_frequencies.TkFrequencies(tk_flowchart=None, node=None, canvas=None, x=None, y=None, w=200, h=50)[source]#

Bases: TkOptimization

The graphical part of a Frequencies step in a flowchart.

See also

TkOptimization, TkEnergy, Frequencies, FrequenciesParameters

create_dialog(title='xTB Frequencies')[source]#: Create the dialog: energy + optimization frames from parents, plus a frequencies frame.

reset_dialog(widget=None)[source]#: Layout: energy frame, optimization frame (parents), then ours.

reset_frequencies_frame(widget=None)[source]#: Layout the widgets inside the frequencies frame.

xtb_step.tk_optimization module#

The graphical part of an xTB Optimization step.

Inherits from TkEnergy to reuse the energy frame and the dynamic solvation/solvent visibility. Adds its own “optimization frame” below the energy frame, holding the optimizer-specific parameters.

class xtb_step.tk_optimization.TkOptimization(tk_flowchart=None, node=None, canvas=None, x=None, y=None, w=200, h=50)[source]#

Bases: TkEnergy

The graphical part of an Optimization step in a flowchart.

See also

TkEnergy, Optimization, OptimizationParameters

create_dialog(title='xTB Optimization')[source]#: Create the dialog: energy frame from parent, plus opt frame.

reset_dialog(widget=None)[source]#: Layout the energy frame (parent) then the optimization frame.

reset_optimization_frame(widget=None)[source]#: Layout the widgets inside the optimization frame.

xtb_step.tk_xtb module#

The graphical part of a xTB step

class xtb_step.tk_xtb.TkxTB(tk_flowchart=None, node=None, namespace='org.molssi.seamm.xtb.tk', canvas=None, x=None, y=None, w=200, h=50)[source]#

Bases: TkNode

The graphical part of a xTB step in a flowchart.

tk_flowchart#

The flowchart that we belong to.

Type:: TkFlowchart = None

node#

The corresponding node of the non-graphical flowchart

Type:: Node = None

canvas#

The Tk Canvas to draw on

Type:: tkCanvas = None

dialog#

The Pmw dialog object

Type:: Dialog

x#

The x-coordinate of the center of the picture of the node

Type:: int = None

y#

The y-coordinate of the center of the picture of the node

Type:: int = None

w#

The width in pixels of the picture of the node

Type:: int = 200

h#

The height in pixels of the picture of the node

Type:: int = 50

self[widget]#

A dictionary of tk widgets built using the information contained in xTB_parameters.py

Type:: dict

See also

xTB, TkxTB, xTBParameters

create_dialog()[source]#

Create the dialog. A set of widgets will be chosen by default based on what is specified in the xTB_parameters module.

Parameters:: None
Return type:: None

See also

TkxTB.reset_dialog

right_click(event)[source]#

Handles the right click event on the node.

Parameters:: event (Tk Event)
Return type:: None

See also

TkxTB.edit

xtb_step.xtb module#

Non-graphical part of the xTB step in a SEAMM flowchart

class xtb_step.xtb.xTB(flowchart=None, title='xTB', namespace='org.molssi.seamm.xtb', extension=None, logger=<Logger xtb_step.xtb (WARNING)>)[source]#

Bases: Node

The non-graphical part of a xTB step in a flowchart.

parser#

The parser object.

Type:: configargparse.ArgParser

options#

It contains a two item tuple containing the populated namespace and the list of remaining argument strings.

Type:: tuple

subflowchart#

A SEAMM Flowchart object that represents a subflowchart, if needed.

Type:: seamm.Flowchart

parameters#

The control parameters for xTB.

Type:: xTBParameters

See also

TkxTB, xTB, xTBParameters

analyze(indent='', **kwargs)[source]#

Do any analysis of the output from this step.

Also print important results to the local step.out file using “printer”.

Parameters:: indent (str) – An extra indentation for the output

description_text(P=None)[source]#

Create the text description of what this step will do. The dictionary of control values is passed in as P so that the code can test values, etc.

Parameters:: P (dict) – An optional dictionary of the current values of the control parameters.
Returns:: A description of the current step.
Return type:: str

property git_revision#: The git version of this module.

run()[source]#

Run the xTB step.

This iterates over the substeps in the subflowchart, asking each one to run itself. Each substep is responsible for invoking the xtb executable with its own command line. This is the FHI-aims pattern, not the LAMMPS/MOPAC pattern of building a single combined input file and invoking the binary once.

Parameters:: None
Returns:: The next node in the flowchart, after this xTB step.
Return type:: seamm.Node

set_id(node_id)[source]#: Set the id for node to a given tuple

property version#: The semantic version of this module.

xtb_step.xtb_step module#

class xtb_step.xtb_step.xTBStep(flowchart=None, gui=None)[source]#

Bases: object

Helper class needed for the stevedore integration.

This must provide a description() method that returns a dict containing a description of this node, and create_node() and create_tk_node() methods for creating the graphical and non-graphical nodes.

The dictionary for the description is the class variable just below these comments. The felds are as follows:

my_description{str, str}
A human-readable description of this step. It can be several lines long, and needs to be clear to non-expert users. It contains the following keys: description, group, name.

my_description[“description”]tuple
A description of the xTB step. It must be clear to non-experts.

my_description[“group”]str
Which group in the menus to put this step. If the group does not exist it will be created. Common groups are “Building”, “Control”, “Custom”, “Data”, and “Simulations”.

my_description[“name”]str
The name of this step, to be displayed in the menus.

create_node(flowchart=None, **kwargs)[source]#

Create and return the new node object.

Parameters:

flowchart (seamm.Node) – A non-graphical SEAMM node
**kwargs (keyword arguments) – Various keyword arguments such as title, namespace or extension representing the title displayed in the flowchart, the namespace for the plugins of a subflowchart and the extension, respectively.

Return type:

xTB

create_tk_node(canvas=None, **kwargs)[source]#

Create and return the graphical Tk node object.

Parameters:

canvas (tk.Canvas) – The Tk Canvas widget
**kwargs (keyword arguments) – Various keyword arguments such as tk_flowchart, node, x, y, w, h representing a graphical flowchart object, a non-graphical node for a step, and dimensions of the graphical node.

Return type:

TkxTB

description()[source]#

Return a description of what this step does.

Returns:: description
Return type:: dict(str, str)

my_description = {'description': 'An interface for xTB', 'group': 'Simulations', 'name': 'xTB'}#

Module contents#

xtb_step A SEAMM plug-in for xTB