logsdail / carmm Goto Github PK

Need to get someone willing to rewrite the Fortran code in Python, so we can actually use it.

Bare in mind we don't want to reinvent functionality of ASE or PyMatGen, but we do want to make it easy to use these...?

Can be coupled to curvature (e.g. around adsorption?) or just kept linear with respect to bulk changes. (two possible approaches)

Tidying and integration of bond lengths/angles so they are generic

This may already be feasible with JMol - if so can be closed but we need someone to test ideas.

Issues include:

• socket calculator
• interpolation for NEB.

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).

2. 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.

3. 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.

4. 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.

what ? to define layers in a slab, specially high index surface and to calculate the average distance between the atoms of each layer

github_issue.docx

@ikowalec @PavelStishenko @GabrielBram

Current implementation of the get_aims_calculator code always supplies FHI-aims with a k_grid argument. This causes a conflict if a user wants to use a k_grid_density instead.

As the 'output' key word is a dictionary key, it only maps to one value. However, this option can be invoked several times.. ASE has a separate optional argument for 'output' for the Aims calculator object, so implementing this option similarly would likely resolve this.

Integrate ability to assess dihedral angles into bond length/angle analysis.

@owainbeynon this is a holder for you to incorporate Corey's code into the mainline. What have we got that can be used sensibly in the scripts he wrote?

Can we measure changes around an adsorption site for surfaces/molecules/zeolites?

Convert input structures -> traj. Comapre structure to make sure e.g. indices are commensurate with correct pathway

We need a notebook to help people with TS calculations. @ikowalec this has been on your in-tray for some time - can I put you on this issue to resolve at some point? It doesn't need to be pretty, but we should get a first draft going.

Are there progressions beyond linear and IDPP to use, e.g. by interpolating bond lengths (Dave Willock's idea?)

@ikowalec I think most of these relate to NEB and symmetry routines - just flagging for us to resolve, shouldn't take long.

The supercell for the rdf function doesn't work correctly with long tall cells, as used in the regression tests. Currently for a bulk material it returns only 22 interactions, but this seems very small (!) within a 10 angstrom radius so needs double-checking.

@owainbeynon I think it is because the cell for cutouts is only a 2x2x2 - does this need to be checked against the radius requested? @ikowalec the alternative is cutout_sphere checks the cell size against the incoming radius requests, and increments the cell size if inappropriately small? Thoughts?

Can we setup a method to coordinate e.g. pi stacking complexes, or large molecules preferentially over adsorption sites, in a manner that is chemically sane rather than brute force?

• Make more user-friendly
• pull out angular contributions from specific orbitals on atoms (currently can do angular or specific atoms, but not both)

The problem

Several ASE workflows are overly optimistic about capabilities of calculators to converge for any geometry. So when a calculators fails to converge for some geometry generated by Dynamics, Optimization, or NEB algorithms, there is no way to recover and the whole calculation fails.

Suggestion

It looks possible to implement a Calculator class that would wrap another Calculator. The wrapper should be capable to catch exceptions raised by the wrapped calculator, and to recreate it with slightly tuned parameters, that should give better chance for convergence. Possible targets for parameters tuning are initial spins, mixer parameters, initial density matrix, etc.

Wrapper implementation details

Wrapper constructor arguments

The Wrapper Calculator should be created using two parameters: a list of tuned parameters for restarts and a function (or callable object) that creates an instance of the wrapped calculator with tuned parameters.

Using the information we have for bulks, can we derive an easy Pythonic workflow with e.g. ASE for managing the creation of alloy or segregated surfaces?

This probably needs to go into ASE, where old scripts can be ported for generic structure creation. Can this also be coupled with Wulff construction with bulk models?

This protocol seeks to automate the transfer and submission of calculations from local machines to the desired HPC. The long term aim of this subproject is to enable users to submit and run calculations entirely from a local Python interface, and call back the files for analysis. This should enable the simple generation of systematic and high-throughput without some of the more fiddly aspects of transferring files and parameters through the terminal.

I currently have a crude version in Jupyter Notebook which just about works. This version simply calls bash commands from the IPython shell. Furthermore, an interface is implemented to automatically generate the submission script, with function calls to change appropriate parameters. Sensible defaults for the most commonly used packages will be added in future. The intended calculation (in the form of a Python script) is transferred from the Notebook to a .py script, which in turn is copied to the desired file and transferred via. SCP. The submission can then be invoked by a call function, which submits the calculation via. SSH. In future, a suite of functions designed to recall files to the local machine will be implemented, which should make data analysis and backing up data more convenient.

However, this version is not as automated as desired - setting a range of calculations which require subtly different inputs but different initialisations still involves manually changing the parameters rather than something more sophisticated (like looping through a list of options). Furthermore, the code needs to be outfitted with appropriate warnings and crashes, and I imagine there are a substantial number of pitfalls one can fall into without them.

Furthermore, where initial structures need reorienting (especially relevant for adsorption studies), there is still the rather laborious process of manipulating the structure to give an appropriate starting guess. As such, structures still need to be supplied on an individual basis if they cannot be generated through ASE or other Python interfaces. Automating this is beyond the scope of this subproject, but this may be remedied by future work in adsorbate rotator, or another tool I am not yet aware of.

Could build on bond angle/dihedral approach, averaging over all values?

Can we automate the procedure of solvating a molecule/system, say e.g. whole system is space available (molecule) or maybe just around an adsorbate (surface, zeolite)?

Can we exchange all the external examples into fully explained Jupyter examples? That'd make it much more accessible for new users! Let's start with ASE.