TribChem: A Software for the First-Principles, High-Throughput Study of Solid Interfaces and Their Tribological Properties

High-throughput first-principles calculations, based on solving the quantum mechanical many-body problem for hundreds of materials in parallel, have been successfully applied to advance many materials-based technologies, from batteries to hydrogen storage. However, this approach has not yet been adopted to systematically study solid–solid interfaces and their tribological properties. To this aim, we developed TribChem, an advanced software program based on the FireWorks platform, which is here presented and released. TribChem is constructed in a modular way, allowing for the separate calculation of bulk, surface, and interface properties. At present, the calculated interfacial properties include adhesion, shear strength, and charge redistribution. Further properties can be easily added due to the general structure of the main workflow. TribChem contains a high-level interface class to store/retrieve results from its own database and connect to public databases.


INTRODUCTION
Integrating the experiments with computational tools and digital data is considered a key strategy to reduce the time and costs for materials discovery and deployment. In this context, first-principles high-throughput calculations, which allow for the density functional theory (DFT) description of many materials in parallel and in an automatized way, represent very powerful tools. 1−6 The calculated properties, usually highly accurate, are stored in databases and eventually analyzed with the aid of machine-learning algorithms, allowing for the identification of general trends and predictions. Moreover, raw data are also stored so that the calculation of further properties and rigorous validations are possible.
High-throughput calculations have been successfully applied to advance several materials-based technologies, including superconductivity, 7 catalysis, 4,8,9 and high-entropy alloying. 10 However, in this quickly developing framework, a systematic study of solid−solid interfaces and their tribological properties has not been addressed yet. Most probably, this is due to the inherent difficulties that this kind of system, composed of two different lattices matched together, poses and to the fact that the community of references (the tribology, metallurgy, and mechanics communities) traditionally relies on continuum macroscopic models.
Here, we present TribChem, a software program designed to perform the high-throughput study of solid interfaces. The software is composed of three main units for the study of bulks, surfaces, and interfaces. It is entirely written in Python and uses different packages from the Materials Project. 11 TribChem is based on FireWorks, 12 an open-source code for defining, managing, and executing workflows. Complex workflows can be defined using Python, JSON, or YAML and stored using MongoDB. For connecting to the Materials Project database, a high-level interface class named Navi-gatorMP has been developed. To perform the density functional theory (DFT) calculations, TribChem presently relies on the Vienna Ab initio Simulation Package (VASP). 13−16 The first workflow developed by our group, 17 based on the Aiida platform, 18 was used for studying the interfacial properties of homogeneous interfaces. 19 TribChem contains several technical advancements, with respect to this initial workflow, related to the creation of proper error handling and the possibility to store and retrieve the data through a publicly accessible database, and has been extended to perform the study of heterointerfaces, such as those forming grain boundaries and heterojunctions. Simulating two different surfaces in contact is computationally much more demanding than considering equivalent surfaces. A common cell should be, in fact, identified to accommodate the two different lattices with a reasonably small mismatch. This typically increases the size of the simulated system and its complexity. Indeed, we introduced a procedure based on the surface symmetries to calculate the potential energy surface (PES) that describes the interaction of the two surfaces in contact as a function of their relative lateral position. 17 We have successfully employed TribChem to systematically search for the optimal interface geometry and accurately determine adhesion energies of hundred metals relevant to technological applications. This allowed us to populate a database of accurate values, which can be used as input parameters for macroscopic models. 20 The aim of the present paper is to provide a technical description of the structure, main features, and an example of the use of TribChem to accompany its release. The first three sections are devoted to the technical description of the software infrastructure, workflows, and database. In the last two sections, the instructions for the workflow execution and an example of use are presented.

IMPLEMENTATION AND ARCHITECTURE
The TribChem package consists of three main elements: the physics and high-throughput modules and the database ( Figure  1).

Physics Module.
In the physics module, we implemented several functions to perform basic operations on solid-state physics, math, geometry, file manipulation, plotting, post-processing, and advanced operations on electronics, mechanical, and tribological properties. These functions are implemented in a highly modular way inside welldefined classes. Thanks to this design, it is possible to use these functions outside TribChem by importing them as external modules. The physics module relies on the Python Materials Genomics (Pymatgen) 21 package to manipulate bulk, slab, and interface structures and on the MPInterfaces 22 package, which implements the algorithm for geometrically matching two surfaces. This package is currently outdated and not maintained. Therefore, we are currently replacing it with similar functionalities present in Pymatgen.
Each submodule is briefly described below: • base: It contains a collection of functions for manipulating atomic structures with periodic boundary conditions. It enables the replication of crystalline cells, the translation or rotation of atomic clusters, and the creation of an orthorhombic-shaped base area for any cell. It also includes mathematical functions for calculating gradients on three-dimensional surfaces and fitting data to polynomials of any degree. There is also a converter between the various physical units and CSV tables of the elemental materials classified based on their properties. Moreover, this module has advanced classes that allow working on the atomic structures of bulks, slabs, and interfaces. • chembas: A class containing a set of functions useful for studying the adsorption of atoms on surfaces. • dft: I/O handlers for VASP, Quantum Espresso, 23 and Lammps 24 are available, allowing the user to load input files into versatile Python dictionaries for further processing or extract information of interest from output files. • dynamics: A set of tools for analyzing a dynamic simulation and calculating the positions, velocities, and forces acting on a single species or groups of atoms. It also includes many tools for plotting these properties. • electronics: A set of functions and classes helpful to combine the electronic charge densities of output files and plot the electronic structure's bands and density of states. • ml: An experimental submodule containing some functions for the generation of data sets suitable to train machine-learning models on them. • tribology: It includes tools for computing and analyzing the tribological properties of interfaces, such as functions for matching two surfaces and calculating the potential energy surface (PES), the minimum energy path (MEP), and shear strength by combining the highsymmetry points of the surfaces, as described in previous papers of our group. 20,25 2.2. High-Throughput Module. We implement the core classes necessary to create the building blocks of the custom workflows in the high-throughput module. Thanks to the modularity creating new custom workflows to perform new high-throughput calculations, also outside the field of tribology, is greatly simplified. Moreover, inside this module, we created some functions and custom classes to perform data analysis of the results. Finally, we added all of the functions necessary to communicate with the database, which is the central element of TribChem due to workflow management, and we stored in it all of the results.
One needs four different input files to run a VASP calculation: POTCAR, POSCAR, INCAR, and KPOINTS (for more information on the structure of these files, see the VASP manual). All of these files are generated automatically by TribChem according to the calculation one would like to execute. The creation of the POSCAR and the POTCAR files is relatively easy. The pymatgen library generates POSCAR by reading the pymatgen object from the database, while the same library also creates POTCAR by reading the pseudopotential files saved in a location specified during the installation of TribChem. Instead, for generating the INCAR and KPOINTS files, we created two classes, VaspInputSet and Mesh-FromDensity, that allow us to manipulate all possible setting options for file generation. Indeed, the INCAR and the KPOINTS files greatly differ from structure to structure. Hence, we developed custom classes that read from an external JSON file the parameters that should be passed as input.

WORKFLOWS
We briefly introduce the logic of the FireWorks library to understand how the high-throughput module works. Every workflow written in FireWorks has three fundamental The FireTask is the most basic component, which usually implements an indivisible task (e.g., launch a VASP calculation or save data in the database). At the FireTask level, the input parameters are passed through the class variables requir-ed_params and optional_params. The FireWork has an intermediate level of complexity and can comprise one or more FireTasks, which are executed consecutively based on a given order (e.g., run a VASP calculation and then save the results in the database). Moreover, a FireWork can initialize and communicate with one or more new FireWorks (which in turn contain other FireTasks), generating a complex hierarchical structure where several operations are executed in a given order, sequentially or in parallel. Finally, the workflow at the top level of the hierarchy groups several FireWorks to execute a complex calculation (e.g., relax an entire structure or calculate the adhesion energy of an interface). The workflow is the only unit that can be launched on a workstation. In practice, a FireTask is a class characterized by two class variables for dealing with the input parameters: requir-ed_params, optional_params, and method run_task to run the instructions of the FireTask. In addition, the tasks done by the FireTask are usually implemented inside the class as methods and then called inside run_task to be executed. Since all of the FireTasks share common operations, we developed a general FireTask class named Fire-TaksTribChem, in which we implemented all of the methods common to the different FireTasks. All of the custom FireTasks we developed inherit from the FireTaksTrib-Chem class and thus have direct access to all its methods. In this way, the development of new FireTasks is greatly simplified and typically only necessitates the creation of specific methods. Of course, it is always possible to override the parent methods in the child classes, creating specific methods for the occurrence.
In short, these methods are: • read_runtask: Read the optional and required parameters of a FireTask. The user passes these as input arguments when initializing the FireTask object. • read_params: Update the dictionary parameters with default values read from a JSON file. • set_filter: Create a filter to query the database to retrieve/store some data. • is_done: Check if a specific entry within a MongoDB 26 document matches the filter. It is useful to check whether a calculation is already done and decide whether to run or stop a job. • query_db: Retrieve data from a MongoDB database.
The database location and tables are specified with the keywords db_file, database, collection, and entry. • update_db: Update data in the matching field. Data are prepared to be stored in a database creating a dictionary according to the MongoDB guidelines. The database field to be updated is located by db_file, database, collection, and entry. • insert_db: Add a new field to a database. The precise position is identified by db_file, database, and collection. • query_mp: Query the Materials Project database, searching for a structure with a selected mp_id or searching for the lowest energy structure given a specific chemical formula. • save_files: Create the folders to save the output files on the local machine.

Workflow Creation.
Thanks to the FireWorks library structure, we can employ several strategies to create complex workflows by combining FireTasks and FireWorks. During the development of TribChem, we decided to implement the FireTasks first and then create FireWorks by employing just one FireTask to maintain the highest level of modularity. We followed this approach with some exceptions. In some situations, it is helpful to have several operations inside a FireWork. For example, every time we run a VASP simulation, all of the results must be saved in a proper location in the database. For this reason, we developed the function run_and_save, which returns a FireWork containing two FireTasks: one for running the simulation (FT_RunVas-pSimulation) and another one for saving the results (FT_MoveResults).
This approach allowed us to exploit as much as possible the modularity given by the FireWorks library by creating atomic operations we used as building blocks to construct complex workflows.
The following example shows how a workflow is built. In this case, the workflow is composed of three serial FireWorks, each of them containing just one FireTask: Each FireWork communicates with the next one, and the execution order is specified inside the workflow definition as a dictionary in the variable called links. Hence, the order is fw1, fw2, and fw3.
3.1.1. Slab Generator Workflow. To better clarify the role of the modular approach we used, in the following, we describe, as an example, how the workflow generates a slab with a given orientation by the convergence of its surface energy (schematically shown in Figure 2).

Initializing FireWork.
The workflow that calculates the optimal thickness is composed of two workflows: the main workflow, which starts the surface energy convergence (Converge slab thickness), and the internal workflow, which calculates the surface energy (Calculate surface energy). As shown in Figure 2, the internal workflow is called recursively until the convergence of the surface energy is reached. The Start Thickness Convergence! FireWork starts the whole workflow. During this step, the program first checks whether the requested slab has already been calculated. If it is not the case, the calculation is launched. In addition, an initial check is done to control which slab thicknesses have already been calculated. The simulation is launched only for the systems that have not been computed before. These checks allow us to save time and computational resources.
3.2.1. WF: Converge Slab Thickness. The Converge slab thickness! workflow consists of two FireWorks: • Start Surface Energy Convergence: Calls the internal workflow, which calculates the surface energy. • End Surface Energy Convergence: Checks if the convergence has been reached. We check the convergence by comparing the computed surface energies with the reference value defined as the energy of the maximum allowed thickness. When the relative difference in surface energy of one slab is lower than a certain threshold, the convergence is reached and the workflow finishes. If the convergence is not reached after the recursive calls, the convergence criterion is not satisfied, and the maximum thickness selected by the user is assumed to be optimized.

WF: Calculate the Surface Energy. This internal workflow calculates the surface energy and is composed of four different FireTasks:
• Generate Slabs: Generates a slab or a list of slabs starting from a bulk structure. The slab has the desired orientation, specified by the Miller indices, thickness, and vacuum to be included in the supercell for separating it from its replicas. • Relax Structure: The geometry optimization is performed using VASP. • Store Results: Saves the results of the first principle simulations in the database. • Surface Energy: Calculates the surface energy and saves the result in the database.

Workflows Available in TribChem.
The currently available workflows of the TribChem package are: • Query online databases to save data to an internal database. • Kinetic energy cutoff convergence.
• Cohesion energy, calculated as where E bulk is the energy of the bulk system, N is the number of atoms in the simulation cell, and E a is the energy of the isolated atom. Its unit is eV/atom. • Calculation of the optimal thickness for a slab by fitting with eq 2 the slab total energies E slab (N), where N is the number of layers in the slab system. • Surface energy E γ , calculated as a fitted parameter in the following formula: at bulk (2) where N at is the number of atoms per layer, E bulk is the bulk energy per atom, and A is the slab in-plane area. When the convergence of the optimal slab thickness is reached, E γ is returned as the surface energy of the system. Its unit is J/m 2 . • Matching and generation of a solid interface.
• Calculation of the PES.
• Evaluation of the adhesion energy. It is defined as where E 12 is the energy of the interface system, E 1 and E 2 are the energies of the isolated, relaxed slabs, and A is the in-plane area of the simulation cell. Its unit is J/m 2 . • Extraction of the MEP and shear strength.
• Calculation of the perpendicular potential energy surface (PPES). • Charge displacement analysis, defined as 27 where z 0 is half of the interface distance and ρ diff is the charge energy difference, and it is defined as interface system and ρ top (ρ bot ) is the charge density of the isolated top (bottom) slab. Its unit is e − /Å 3 . • Adsorption energies of atoms on surfaces, calculated as where E surf+a is the energy of the adsorbate system, E surf is the energy of the isolated, relaxed surface, N is the number of adatoms in the supercell, and E a is the energy of the adatom. The latter is calculated both by assuming the atom as isolated or interacting with its periodic replicas, i.e., by using the same supercell size adopted for simulating the adsorbate system. Its unit is eV/atom.

DATABASES
The database used by the FireWorks library is MongoDB, 26 a NoSQL database that uses JSON-like documents to store and manipulate data. When a new installation of TribChem is carried out, the user creates several databases. The most important and relevant ones are the FireWorks database, in which all of the data for the workflow execution are saved, as well as the simulation results and some relevant metadata such as the location of the VASP output files and the TribChem database. We designed this custom database to save, retrieve, and make it easier to share the results of the high-throughput calculations with the scientific community. When performing a high-throughput study, it is critical to have powerful tools to efficiently perform the input/output (I/ O) operations. Indeed, the amount of data generated is very high, and it is necessary to have the proper tools to manage them. To this end, we created several submodules containing Python tools for efficiently performing I/O operations. The class Navigator combines several low-level functions of the PyMongo 28 library. Starting from this class, we developed powerful functions to automatize the query operations inside all of the FireTasks of TribChem. Technically, we did this by implementing the functions as methods of the main FireTask FiretaskTribchem, which is used by all of the FireTasks of TribChem. This design greatly simplifies the structure of the software since it hides the implementations of all of the functions in just one class, making them more maintainable, less error-prone, and usable also by nontechnical users.
We also developed a high-level interface class named NavigatorMP for connecting to the Materials Project database.

TribChem Database.
We carefully designed the structure of the TribChem database to ensure the best usability, maintainability, and robustness of the data stored inside it. This database includes several collections divided into different structures and functionals used for performing the DFT calculations. In our case, we have three main collections classes about bulks, slabs, and interfaces. The notation we used to name these collections is functional.material. For example, the collection of the elemental bulks calculated with the Perdew−Burke−Ernzerhof (PBE) functional is named PBE.bulk_elements. The structure of the three main collections is shown in Figure 3.
The main problem when working with data stored in a database is uniquely identifying each element. For this reason, we defined a set of identifiers for each of the three main collections we created.
In the case of the bulk, the main identifier is the material identifier (mid), which usually corresponds to the Materials Project ID for a given material, but it could be any alphanumeric value. In the case of aluminum, mid corresponds to mp-134 ( Figure 3). We added two optional identifiers to the main one: formula and name. The former usually corresponds to the chemical formula of the material, and the latter is used as an additional identifier useful to speed up the search and avoid misinterpretations in some cases. For example, in case both diamond and graphene structures are saved in the bulk collection, setting the name to the structure name would avoid the conflict of having different elements with the same identifiers.
For identifying a slab, in addition to mid and formula identifiers, the crystalline orientation, defined by the Miller index, is used. The miller identifier is a Python list in the form [h, k, l] (e.g., [1,1,1]).
Finally, we defined the identifiers for an interface. Their name is the same for the bulk and slab collections, but their values are made up by combining the identifiers of the two slabs forming the interface. The resulting notation is: mid=mid1_mid2, formula=f1_f2, miller=[[h1, k,1 l1], [h2, k2, l2]], and name=f1m1-f2m2!. In this case, the miller identifier is a list containing two lists (each for the orientation of the slab components), and the name is the formula combination of the two materials with the string version of the Miller indices of the relative slab. For example, a homogeneous interface of aluminum is identified by (Figure 3): In addition to the consistent definition of identifiers, we also defined a coherent structure for saving the inputs, outputs, and computational parameters for running the VASP simulations. In every document, the fields structure, data, and comp_params can be found.
The field structure includes two other fields: init, which contains the primitive structure for the bulk downloaded from the Materials Project database, and for the slab and interface, created by our workflow, and opt, which contains the optimal structure obtained after the relaxation. Both these structures are saved as pymatgen objects.
The field data contains the results of the VASP calculations, such as the total energy, forces and stresses, band gap, and many others. All of the files produced by VASP are stored in the calculations folder, which is generated automatically in the same location as the TribChem installation folder that keeps the same hierarchical structure of the collections.
The field comp_params contains the computational parameters used by VASP. In this field, one can find the Kpoint density, the cutoff energy, whether the material is a metal or not, and many others. If this field does not sufficiently define all of the computational parameters, the user can introduce new ones. For example, we need information about the matching during interface formation. For this reason, we created the field inter_params.
Finally, other fields can be created to save the results of specific calculations. In the case of the interface, where there are many kinds of calculations and additional properties can be calculated, there are additional fields, such as highsym, pes, adhesion, ppes, and charge. These fields can store data concerning the high-symmetry points, the energies of the PES, the adhesion energy, the perpendicular potential energy surface (PPES), and the charge displacement calculation, respectively ( Figure 3).

EXECUTION OF A WORKFLOW
This section will explain the logic behind executing our highthroughput workflows. As shown in Figure 4, different components are involved during the execution of a workflow, with a continuous flow of data and instructions.
The first step in running a workflow consists of the selection of the desired material with its crystallographic information. The primitive structures can be stored in the TribChem database by downloading them from the Materials Project website, a local database, or directly from input files. Currently, only the Materials Project database can be used as an online resource. However, it is possible to add in the future the application programming interface (API) directives for the new database inside the TribChem project. Indeed, these new functions would write the new data into the unchanged TribChem database; hence, the same structure and functions remain the same.
Once the crystalline structures are loaded into TribChem, the workflows of interests can be executed. The execution of a workflow occurs in two steps: the first is to write the workflow in the database and the second is to run the calculations (for more information on how this can be done in practice, see the user manual of TribChem 29 ). Based on the high-throughput study the user would like to perform, several workflows can be generated and written in the database and then run. Based on the experience we gained in using TribChem, we suggest running the same type of workflow to avoid possible race conditions. For example, the workflow that generates the slab is much faster than the workflow that calculates the PES and the adhesion energy. Although it is possible to run these two workflows at the same time for many different materials and interfaces, what would happen is that the faster workflows would be blocked by the slower ones, slowing down the whole process of getting new results.
Our workflows are designed to be also used outside a highthroughput procedure. Indeed, they can take as input an atomic structure directly from a POSCAR file by loading it as a pymatgen object. In this way, it is also possible to use TribChem in simple scripts.
Once the workflows are completed, TribChem provides several data analysis tools.
For more information on the practical usage of TribChem, see the user manual. 29 5.1. Quality Control. We carried out the quality control of TribChem by using a set of dedicated functions present in the test folders of each module and submodule. The users can find more information on how to check if the installation process was successful and if the main functionalities are correctly working in the user manual. 29 5.2. Availability. We host the TribChem source code at the following GitLab repository https://gitlab.com/triboteam/ tribchem, where it is possible to find the complete installation procedure and the user manual. 29 5.2.1. Operating System. The Linux operating system is required for the execution of TribChem. It is possible to use TribChem on the most relevant operating systems (Windows, macOS, and Linux) to create the workflows and analyze the data. However, we suggest using Linux.

Additional System
Requirements. There are no particular requirements for using TribChem. The DFT calculations can usually be run on a high-performance computing system (HPC) to maximize computational efficiency, while the workflow creation and data analysis can also be done on an ordinary desktop system.

Dependencies.
TribChem uses the following dependencies. Besides VASP, 13−16 which is proprietary software and must be purchased from the official channels (see https:// www.vasp.at/), all of the other packages can be installed with conda or pip (see the installation guide of TribChem).
• atomate≥0.9.9: 30 A Python library containing a collection of FireWorks workflows, which make it easy to perform complex materials science computations. • ASE≥3. 21

EXAMPLE OF TRIBCHEM USE
In the following section, we show how Tribchem can be used to compute in an automatic and systematic fashion the adhesion energies of the K(110) surface interfaced with a set of 17 technologically relevant metal surfaces. All of the main workflow steps will be described starting from the bulk creation, slab thickness optimization, and surface energy calculations and ending with the heterointerface creation and computation of the adhesion energy. This example can be considered a further guide for using TribChem to study heterointerfaces and tribological properties. 6.1. Bulk Calculations. The first step in the study of any interface is bulk optimization: TribChem identifies the bulk structure equilibrium geometry and optimizes the computational parameters for the selected elements. In order to do so, the program selects the optimal kinetic energy cutoff by converging, with respect to this computational parameter, the bulk modulus and the cell volume. To perform this task and launch the calculations, the user has to execute the following command within a Python virtual environment (here applied to the case of the K bulk): More in detail: A Birch−Murnaghan equation of state 35 is used to fit the ab initio data for increasing cutoffs. The bulk modulus and the cell volume are extrapolated when the relative difference between two consecutive steps is below 1% for both quantities and convergence is reached. As an example, data obtained for K are reported in Table 1.
In bold, the converged value of the bulk modulus and lattice parameter and the optimal kinetic energy cutoff are highlighted. The computed values are remarkably close to the experimental values 36 (3.0 GPa for the bulk modulus and 5.328 Å for the lattice parameter), confirming the reliability of DFT and of our workflow in the determination of the bulk properties.
With the same TribChem command, it is also possible to identify the optimal K-point sampling. In this case, TribChem fixes the energy cutoff at the optimal value while varying the Kpoint density until convergence is reached. We fix the energy convergence of this sampling to 1 meV/atom. For K, an optimal K-point density of 5.4 Å −1 is identified.

Slab and Surface Energy Calculations.
The second step in the study of an interface is the generation and optimization of the two mating surfaces; as previously explained, TribChem creates a slab structure and then optimizes its thickness and computes the surface energy. To execute this workflow, the following command must be used (here, we consider the K(110) surface): tmin and tmax identify the range of slab thicknesses to be considered (4 to 12 layers in this case). For K(110), using eq 2, 4 layers are identified as the optimal slab thickness.
Correspondingly, the surface energy E γ is 0.11 J/m 2 , which matches precisely the value reported by the Materials Project. 37 6.3. Homogeneous Interface and PES Calculation. Homogeneous interfaces are the simplest interfaces that can be studied, as no cell matching is required. To generate and compute both the PES and adhesion energy of the K(110)/ K(110) interface, the following command must be used: The wf="[interface, pes, adhesion]" command indicates that the user wants to launch the interface, pes, and adhesion workflows altogether. First of all, the interface workflow is launched, and the interface structure of the required system is generated. A visual representation of the K−K interface is shown in Figure 5.
Second, the pes workflow begins. TribChem builds the PES landscape by mating the two slabs in different relative lateral positions and by collecting, for each displacement, the adhesion energy γ is calculated from eq 3. The relative lateral positions are identified by TribChem by pairing the highsymmetry points of the two surfaces. For the K(110) surface, four high-symmetry points (the on-top, hollow, long bridge, and short bridge sites) are found, generating six nonequivalent lateral displacements for the K(110)/K(110) interface. Collecting the adhesion energy in every lateral displacement and interpolating them through the radial basis function makes it possible to obtain a 2D representation of the PES, as shown in Figure 6.
The final interface adhesion energy is the PES minimum, a value that is identified and stored in the database with the command adhesion. For the K(110)/K(110) interface, we obtain an adhesion energy of 0.20 J/m 2 , almost twice the computed surface energy (0.11 J/m 2 ). This result validates the three interface workflows as, by definition of adhesion energy, its value in the homostructure should be twice the surface energy.
6.4. Heterogeneous Interface with Other Metals. Finally, we generated the heterostructures by mating the K(110) surface with the most stable faces of 17 different metals: Ag, Al, Au, Cr, Cu, Fe, Ir, Mg, Mo, Ni, Pt, Rh, Sc, Ti, V, W, and Zn. The surfaces are matched by MPInterface, 22 which makes use of the Zur algorithm. 38 Such a procedure allows the optimization of the in-plane supercell area within the allowed mismatch for the cell sides and angles. An example of the result

Journal of Chemical Theory and Computation
pubs.acs.org/JCTC Article of this matching procedure is shown in Figure 7 for the K(110)/Al(111) interface case. Using the same command shown for the homogeneous interface, TribChem generates the interfaces in different relative lateral positions to identify the energy minimum and compute the adhesion energy of the system. The results of these calculations are reported in Figure 8.
K has the largest adhesion with Pt, whereas the lowest interaction is with Al. In ref 20, more than a hundred heterogeneous interfaces have been studied employing this workflow. A large amount of data, in that case, allowed for the use of a machine-learning algorithm to determine predictive models of adhesion energies in terms of the properties of single slabs.

SUMMARY
We present TribChem, an advanced high-throughput software to study solid interfaces through first-principles calculations. The program is based on the Atomate and FireWorks workflow managers and relies on MongoDB for database communication.
TribChem presents a modular structure, which allows for the execution of different types of calculations and can be easily extended to include new features.
At present, the first unit of TribChem is devoted to bulk calculations, which are used to set the optimal computational parameters for studying a selected element. Moreover, bulk properties, such as the cohesion energy and the bulk modulus, are calculated. In the second unit, an accurate model for the surface is automatically constructed by converging the   calculated surface energy as a function of the slab thickness. In the third TribChem unit, the interface is constructed by mating two different surfaces within a common cell able to accommodate the two different lattices with a small mismatch. The potential energy surface that describes how the interaction energy of the two mated surfaces changes as a function of their relative lateral position is calculated in a smart way using the surface's high-symmetry points. The PES absolute minimum is used to define the adhesion energy between the two surfaces, while the sliding path with the highest statistical weight is used to calculate the interfacial shear strength.
The implementation of the above features has been technically described in the present manuscript, where an example for potassium bulk, surface, and 17 heterointerfaces have been presented.
TribChem represents a significant step forward in the study of solid−solid interfaces, where a systematic high-throughput analysis was still lacking. For the foreseeable future, we plan to expand TribChem to include lubricant additives, contaminants, and rough surfaces for a more realistic description of the tribological interfaces.