The system class is a convenience wrapper for easily defining all the necessary information about a given system in one place. It also makes using the tools in pele very simple.
The class BaseSystem defines the base class from which all other system classes are derived. To construct a class for a new system you must derive from BaseSystem and overload several functions. BaseSystem also defines several functions (e.g. BaseSystem.get_basinhopping(), BaseSystem.get_double_ended_connect()) which uses other functions to create high level objects. Depending on what calculations you want to perform, different functions are required.
landscape exploration and transition state searches
- BaseSystem.get_potential() : required
- BaseSystem.get_mindist() : required
- BaseSystem.get_orthogonalize_to_zero_eigenvectors() : required
- BaseSystem.get_compare_exact() : optional, recommended
- BaseSystem.get_random_configuration() : optional
The optional methods have default implementations which will be adequate for many uses, but you may need or want to overload them anyway. Follow the methods links for more details about what each of them do. See Potentials for more information about how to implement get_potential(). See Structure Alignment for more information about how to implement get_mindist(). See Global Optimization for more information about how to implement get_takestep().
|BaseSystem(*args, **kwargs)||The base class for a System object|
These are groups of system types that have common features (e.g. the same symmetries). Thus some of the required functions can be defined here and inherited by specific systems.
|AtomicCluster(*args, **kwargs)||Define an atomic cluster.|
Here we list the existing systems.
|LJCluster(natoms)||define the System class for a Lennard-Jones cluster|
|BLJCluster(natoms[, ntypeA])||define the System class for a binary Lennard-Jones cluster|
The parameter class is what the system class uses for holding and maintaining global defaults for all the many adjustable parameters in pele.
If, in your new system class you want to change the default number of double ended connect iterations, you can do it by adding this line to __init__():
self.params.double_ended_connect.niter = 50
then, when you create the double ended connect object it will use this new value:
connect = mysys.get_double_ended_connect(min1, min2, database)
The top level functions often use multiple levels of algorithms. E.g. DoubleEndedConnect calls LocalConnect which calls FindTransitionState. If you want to change a parameter in one of these low level algorithm you must use the parameter tree. the parameter tree looks like this:
-params -----double_ended_connect ---------local_connect_params -------------NEBparams -----------------NEBquenchParams -------------tsSearchParams -----------------lowestEigenvectorQuenchParams -----------------tangentSpaceQuenchParams -------------pushoff_params -----------------quenchParams
All of the these listed above are dictionaries that are passed to the appropriate functions or classes. For simplification, they can be accessed either by keyword or attribute. The maximum uphill step in the transition state search can be modified in either of these two equivalent ways:
mysys.params.double_ended_connect.local_connect_params.tsSearchParams.max_uphill_step = 0.2 mysys.params["double_ended_connect"]["local_connect_params"]["tsSearchParams"]["max_uphill_step"] = 0.2
The logic is that the system class passes the dictionary double_ended_connect as kwargs (key word arguments) to DoubleEndedConnect. One of those keyword argemnts is local_connect_params, which is then passed by DoubleEndedConnect as kwargs to LocalConnect. LocalConnect then passes tsSearchParams to FindTransitionState and so on. Each parameter dictionary holds keyword arguments for the following function
|parameter dictionary||passed as parameters to|
|NEBquenchParams||the optimizer called by NEB|
|lowestEigenvectorQuenchParams||the optimizer called by findLowestEigenVector|
|pushoff_params||the routine which finds the minima on either side of a transition state|
Note that the Parameters class doesn’t hold the pele default values for each algorithm. These are defined in the algorithms themselves. Instead, the Parameters class keeps track only of what has been overridden.
|BaseParameters||define a dictionary who’s values can be accessed like attributes|
|Parameters()||Define the parameter tree for use with BaseSystem class|
For a translation between an OPTIM odata file and the pele Parameter tree, see here