Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GAWPP - Generalised Adsorption Workflow Placeholder Project (Name pending) #90

Open
GabrielBram opened this issue Oct 26, 2022 · 0 comments
Assignees

Comments

@GabrielBram
Copy link
Collaborator

GAWPP - Generalised Adsorption Workflow Placeholder Project

The intention of this program is to generate a general workflow for exploring configurational space from a large number of candidate structures, whittling down the number of structures with less expensive methods, then using the most stable structures to carry out more sophisticated electronic structure calculations.

The intention of this software is to generate stable candidate structures for the time being (ie., placing an adsorbate on a sensible positions). However, the platform should be as extensible, allowing the user to select calculators, or easily letting developers add their own contributions to each stage of the processes below. Furthermore, allowing the user to define their own configurational space should open the software to a greater variety of applications, and enable future development.

However, the goal at present will be to accomplish something pretty simple - find the most stable adsorption site and run a DFT geometry optimization on it.


Code structure

The early work of this project is centred around making making a generalisable inputs and outputs of each stage of this process. At present this can be mapped out into roughly 4 stage:

  1. Top level Input: at the very basic level, reads in the adsorbate and adsorbate site. During development (where some features may not automate certain capabilities), the user (and developer) can input desired parameters for selecting the configurational space they wish to explore (ie., the atoms and positions to adsorb to, the range of angles the adsorbate should vary etc.), and whittle down the potential number of criteria to search over.

Input: Structure of adsorbate, structure of adsorbate site, user input configurational space vectors.
Output: Ditto to Stage 2).

  1. Configurational space define: defines the configurational space for the adsorption of molecule at a certain site. The configurational space vector includes the potential atoms which can be adsorbed to (ie., positions on the surface), angle with respect to the adsorption site. There are probably a lot of ways to structure this, but for now, I believe this should take the form of an overall Configurational Space object, containing other objects pertaining to other types of criteria (ie., angles, positions, species changes etc.), or one big messy object.

At first, this should probably accept some rigid user input (ie., the software is told a list of positions corresponding to the most stable sites known to the user) and crude automation procedures (ie., a big sweep over all the possible angles around a rotation point). However, methods can be added for specific structures which are commonly encountered, such as zeolites or metallic facets, where easily definable adsorption sites may be identified and incorporated in to the configurational space automatically.

Input: Structure, user input configurational space vectors and their desired scope.
Output: Complete list of configurational space and associated candidate structures.

  1. Filtering: A set of Filter objects designed to parse down the configurational space will be applied - these will take the form of simple heuristics (ie. hard sphere potentials which exclude overlap), to MM force-field simulations, or even GGA DFT. The Filter object should include the desired ASE Calculator (or internal calculator) and remaining candidate structures, where the least feasible configurations are excluded by cruder methods, and the more difficult to evaluate sections of the potential energy landscape are explored with more sophisticated techniques.

A further filter may be introduced based on 'similarity criteria' - which excludes certain structures which are provably identical of very similar to the point where they would converge to the same structural minima in a geometry optimisation calculation. Possibility of symmetry filters or distance methods.

Input: The filter accepts the current list of candidate structures and the configuration space.
Output: The filter should then output a set of energies (if available) and the accepted candidate structures (which may be accepted or rejected for further calculations with a certain set of criteria).

3a) Analysis: Outputs plots and energetic analysis of the landscape. Shows which stage certain configurations were rejected and allows the PES of different calculators to be compared. Enables later validation of the method by comparing cruder EMT/MM methods against DFT - ensures that the software isn't filtering out good guesses or including garbage.

  1. Final, high quality calculations: Using a desired calculator object, perform whatever calculation the user wants to perform (single-point/geometry optimization etc.) and outputs.

Scope

By having a rather stripped down core set of functionalities, the internal workflow should be fairly straightforward to implement. For the time being, this software should act as a platform to pass data from one part to another, while more complex automation should be handled by auxiliary functions to wrap around this routine. In particular, this applies to the definition of the desired configurational space for a given structure, and filters based on a set of system specific criteria. This will hopefully make it easy to extend the code, avoid breaking core functionality when new features are added, and make the initial implementation simpler.

Stage 3 can be skipped quite easily, and the raw set of the structures may be input into a calculator. This may be useful if a cheap method is being used to iterate over a large configurational space. This will also make testing significantly easier.


Plan

I will set up a branch and set-up the core modules. People can take up whatever they want, and feel free to get in touch! I know @PavelStishenko and @JackWarren23 were keen to contribute.

312893453_492829059436685_2249646250695668003_n
312903435_953237535637611_398049762134285629_n

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants