interfacemethod 2.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- interfacemethod-2.0/.gitignore +218 -0
- interfacemethod-2.0/LICENSE +29 -0
- interfacemethod-2.0/PKG-INFO +183 -0
- interfacemethod-2.0/README.md +123 -0
- interfacemethod-2.0/pyproject.toml +120 -0
- interfacemethod-2.0/src/interfacemethod/__init__.py +29 -0
- interfacemethod-2.0/src/interfacemethod/_version.py +24 -0
- interfacemethod-2.0/src/interfacemethod/helper.py +88 -0
- interfacemethod-2.0/src/interfacemethod/lammps.py +379 -0
- interfacemethod-2.0/src/interfacemethod/plot.py +310 -0
- interfacemethod-2.0/src/interfacemethod/result.py +16 -0
- interfacemethod-2.0/src/interfacemethod/structure.py +115 -0
- interfacemethod-2.0/src/interfacemethod/workflow.py +205 -0
|
@@ -0,0 +1,218 @@
|
|
|
1
|
+
# Byte-compiled / optimized / DLL files
|
|
2
|
+
__pycache__/
|
|
3
|
+
*.py[codz]
|
|
4
|
+
*$py.class
|
|
5
|
+
|
|
6
|
+
# C extensions
|
|
7
|
+
*.so
|
|
8
|
+
|
|
9
|
+
# Distribution / packaging
|
|
10
|
+
.Python
|
|
11
|
+
build/
|
|
12
|
+
develop-eggs/
|
|
13
|
+
dist/
|
|
14
|
+
downloads/
|
|
15
|
+
eggs/
|
|
16
|
+
.eggs/
|
|
17
|
+
lib/
|
|
18
|
+
lib64/
|
|
19
|
+
parts/
|
|
20
|
+
sdist/
|
|
21
|
+
var/
|
|
22
|
+
wheels/
|
|
23
|
+
share/python-wheels/
|
|
24
|
+
*.egg-info/
|
|
25
|
+
.installed.cfg
|
|
26
|
+
*.egg
|
|
27
|
+
MANIFEST
|
|
28
|
+
|
|
29
|
+
# PyInstaller
|
|
30
|
+
# Usually these files are written by a python script from a template
|
|
31
|
+
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
|
32
|
+
*.manifest
|
|
33
|
+
*.spec
|
|
34
|
+
|
|
35
|
+
# Installer logs
|
|
36
|
+
pip-log.txt
|
|
37
|
+
pip-delete-this-directory.txt
|
|
38
|
+
|
|
39
|
+
# Unit test / coverage reports
|
|
40
|
+
htmlcov/
|
|
41
|
+
.tox/
|
|
42
|
+
.nox/
|
|
43
|
+
.coverage
|
|
44
|
+
.coverage.*
|
|
45
|
+
.cache
|
|
46
|
+
nosetests.xml
|
|
47
|
+
coverage.xml
|
|
48
|
+
*.cover
|
|
49
|
+
*.py.cover
|
|
50
|
+
.hypothesis/
|
|
51
|
+
.pytest_cache/
|
|
52
|
+
cover/
|
|
53
|
+
|
|
54
|
+
# Translations
|
|
55
|
+
*.mo
|
|
56
|
+
*.pot
|
|
57
|
+
|
|
58
|
+
# Django stuff:
|
|
59
|
+
*.log
|
|
60
|
+
local_settings.py
|
|
61
|
+
db.sqlite3
|
|
62
|
+
db.sqlite3-journal
|
|
63
|
+
|
|
64
|
+
# Flask stuff:
|
|
65
|
+
instance/
|
|
66
|
+
.webassets-cache
|
|
67
|
+
|
|
68
|
+
# Scrapy stuff:
|
|
69
|
+
.scrapy
|
|
70
|
+
|
|
71
|
+
# Sphinx documentation
|
|
72
|
+
docs/_build/
|
|
73
|
+
|
|
74
|
+
# PyBuilder
|
|
75
|
+
.pybuilder/
|
|
76
|
+
target/
|
|
77
|
+
|
|
78
|
+
# Jupyter Notebook
|
|
79
|
+
.ipynb_checkpoints
|
|
80
|
+
|
|
81
|
+
# IPython
|
|
82
|
+
profile_default/
|
|
83
|
+
ipython_config.py
|
|
84
|
+
|
|
85
|
+
# pyenv
|
|
86
|
+
# For a library or package, you might want to ignore these files since the code is
|
|
87
|
+
# intended to run in multiple environments; otherwise, check them in:
|
|
88
|
+
# .python-version
|
|
89
|
+
|
|
90
|
+
# pipenv
|
|
91
|
+
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
|
92
|
+
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
|
93
|
+
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
|
94
|
+
# install all needed dependencies.
|
|
95
|
+
# Pipfile.lock
|
|
96
|
+
|
|
97
|
+
# UV
|
|
98
|
+
# Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
|
|
99
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
100
|
+
# commonly ignored for libraries.
|
|
101
|
+
# uv.lock
|
|
102
|
+
|
|
103
|
+
# poetry
|
|
104
|
+
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
|
|
105
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
106
|
+
# commonly ignored for libraries.
|
|
107
|
+
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
|
|
108
|
+
# poetry.lock
|
|
109
|
+
# poetry.toml
|
|
110
|
+
|
|
111
|
+
# pdm
|
|
112
|
+
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
|
|
113
|
+
# pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
|
|
114
|
+
# https://pdm-project.org/en/latest/usage/project/#working-with-version-control
|
|
115
|
+
# pdm.lock
|
|
116
|
+
# pdm.toml
|
|
117
|
+
.pdm-python
|
|
118
|
+
.pdm-build/
|
|
119
|
+
|
|
120
|
+
# pixi
|
|
121
|
+
# Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
|
|
122
|
+
# pixi.lock
|
|
123
|
+
# Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
|
|
124
|
+
# in the .venv directory. It is recommended not to include this directory in version control.
|
|
125
|
+
.pixi
|
|
126
|
+
|
|
127
|
+
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
|
|
128
|
+
__pypackages__/
|
|
129
|
+
|
|
130
|
+
# Celery stuff
|
|
131
|
+
celerybeat-schedule
|
|
132
|
+
celerybeat.pid
|
|
133
|
+
|
|
134
|
+
# Redis
|
|
135
|
+
*.rdb
|
|
136
|
+
*.aof
|
|
137
|
+
*.pid
|
|
138
|
+
|
|
139
|
+
# RabbitMQ
|
|
140
|
+
mnesia/
|
|
141
|
+
rabbitmq/
|
|
142
|
+
rabbitmq-data/
|
|
143
|
+
|
|
144
|
+
# ActiveMQ
|
|
145
|
+
activemq-data/
|
|
146
|
+
|
|
147
|
+
# SageMath parsed files
|
|
148
|
+
*.sage.py
|
|
149
|
+
|
|
150
|
+
# Environments
|
|
151
|
+
.env
|
|
152
|
+
.envrc
|
|
153
|
+
.venv
|
|
154
|
+
env/
|
|
155
|
+
venv/
|
|
156
|
+
ENV/
|
|
157
|
+
env.bak/
|
|
158
|
+
venv.bak/
|
|
159
|
+
|
|
160
|
+
# Spyder project settings
|
|
161
|
+
.spyderproject
|
|
162
|
+
.spyproject
|
|
163
|
+
|
|
164
|
+
# Rope project settings
|
|
165
|
+
.ropeproject
|
|
166
|
+
|
|
167
|
+
# mkdocs documentation
|
|
168
|
+
/site
|
|
169
|
+
|
|
170
|
+
# mypy
|
|
171
|
+
.mypy_cache/
|
|
172
|
+
.dmypy.json
|
|
173
|
+
dmypy.json
|
|
174
|
+
|
|
175
|
+
# Pyre type checker
|
|
176
|
+
.pyre/
|
|
177
|
+
|
|
178
|
+
# pytype static type analyzer
|
|
179
|
+
.pytype/
|
|
180
|
+
|
|
181
|
+
# Cython debug symbols
|
|
182
|
+
cython_debug/
|
|
183
|
+
|
|
184
|
+
# PyCharm
|
|
185
|
+
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
|
|
186
|
+
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
|
187
|
+
# and can be added to the global gitignore or merged into this file. For a more nuclear
|
|
188
|
+
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
|
|
189
|
+
# .idea/
|
|
190
|
+
|
|
191
|
+
# Abstra
|
|
192
|
+
# Abstra is an AI-powered process automation framework.
|
|
193
|
+
# Ignore directories containing user credentials, local state, and settings.
|
|
194
|
+
# Learn more at https://abstra.io/docs
|
|
195
|
+
.abstra/
|
|
196
|
+
|
|
197
|
+
# Visual Studio Code
|
|
198
|
+
# Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
|
|
199
|
+
# that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
|
|
200
|
+
# and can be added to the global gitignore or merged into this file. However, if you prefer,
|
|
201
|
+
# you could uncomment the following to ignore the entire vscode folder
|
|
202
|
+
# .vscode/
|
|
203
|
+
# Temporary file for partial code execution
|
|
204
|
+
tempCodeRunnerFile.py
|
|
205
|
+
|
|
206
|
+
# Ruff stuff:
|
|
207
|
+
.ruff_cache/
|
|
208
|
+
|
|
209
|
+
# PyPI configuration file
|
|
210
|
+
.pypirc
|
|
211
|
+
|
|
212
|
+
# Marimo
|
|
213
|
+
marimo/_static/
|
|
214
|
+
marimo/_lsp/
|
|
215
|
+
__marimo__/
|
|
216
|
+
|
|
217
|
+
# Streamlit
|
|
218
|
+
.streamlit/secrets.toml
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
BSD 3-Clause License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2020, Max-Planck-Institut für Eisenforschung GmbH - Computational Materials Design (CM) Department
|
|
4
|
+
All rights reserved.
|
|
5
|
+
|
|
6
|
+
Redistribution and use in source and binary forms, with or without
|
|
7
|
+
modification, are permitted provided that the following conditions are met:
|
|
8
|
+
|
|
9
|
+
* Redistributions of source code must retain the above copyright notice, this
|
|
10
|
+
list of conditions and the following disclaimer.
|
|
11
|
+
|
|
12
|
+
* Redistributions in binary form must reproduce the above copyright notice,
|
|
13
|
+
this list of conditions and the following disclaimer in the documentation
|
|
14
|
+
and/or other materials provided with the distribution.
|
|
15
|
+
|
|
16
|
+
* Neither the name of the copyright holder nor the names of its
|
|
17
|
+
contributors may be used to endorse or promote products derived from
|
|
18
|
+
this software without specific prior written permission.
|
|
19
|
+
|
|
20
|
+
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
21
|
+
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
22
|
+
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
23
|
+
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
|
|
24
|
+
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
25
|
+
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
26
|
+
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
|
27
|
+
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
28
|
+
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
29
|
+
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
@@ -0,0 +1,183 @@
|
|
|
1
|
+
Metadata-Version: 2.5
|
|
2
|
+
Name: interfacemethod
|
|
3
|
+
Version: 2.0
|
|
4
|
+
Summary: A fully automated approach to determine the melting temperature of crystalline materials.
|
|
5
|
+
Project-URL: Homepage, http://pyiron.org/pyiron_meltingpoint/
|
|
6
|
+
Project-URL: Documentation, http://pyiron.org/pyiron_meltingpoint/
|
|
7
|
+
Project-URL: Repository, https://github.com/pyiron/pyiron_meltingpoint
|
|
8
|
+
Author-email: Jan Janssen <janssen@mpi-susmat.de>
|
|
9
|
+
License: BSD 3-Clause License
|
|
10
|
+
|
|
11
|
+
Copyright (c) 2020, Max-Planck-Institut für Eisenforschung GmbH - Computational Materials Design (CM) Department
|
|
12
|
+
All rights reserved.
|
|
13
|
+
|
|
14
|
+
Redistribution and use in source and binary forms, with or without
|
|
15
|
+
modification, are permitted provided that the following conditions are met:
|
|
16
|
+
|
|
17
|
+
* Redistributions of source code must retain the above copyright notice, this
|
|
18
|
+
list of conditions and the following disclaimer.
|
|
19
|
+
|
|
20
|
+
* Redistributions in binary form must reproduce the above copyright notice,
|
|
21
|
+
this list of conditions and the following disclaimer in the documentation
|
|
22
|
+
and/or other materials provided with the distribution.
|
|
23
|
+
|
|
24
|
+
* Neither the name of the copyright holder nor the names of its
|
|
25
|
+
contributors may be used to endorse or promote products derived from
|
|
26
|
+
this software without specific prior written permission.
|
|
27
|
+
|
|
28
|
+
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
29
|
+
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
30
|
+
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
31
|
+
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
|
|
32
|
+
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
33
|
+
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
34
|
+
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
|
35
|
+
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
36
|
+
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
37
|
+
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
38
|
+
License-File: LICENSE
|
|
39
|
+
Keywords: atomistic,interface method,lammps,melting
|
|
40
|
+
Classifier: Development Status :: 5 - Production/Stable
|
|
41
|
+
Classifier: Intended Audience :: Science/Research
|
|
42
|
+
Classifier: License :: OSI Approved :: BSD License
|
|
43
|
+
Classifier: Operating System :: OS Independent
|
|
44
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
45
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
46
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
47
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
48
|
+
Classifier: Programming Language :: Python :: 3.14
|
|
49
|
+
Classifier: Topic :: Scientific/Engineering :: Physics
|
|
50
|
+
Requires-Python: <3.15,>3.9
|
|
51
|
+
Requires-Dist: ase<=3.29.0,>=3.23.0
|
|
52
|
+
Requires-Dist: lammpsparser<=0.0.9,>=0.0.1
|
|
53
|
+
Requires-Dist: matplotlib==3.11.1
|
|
54
|
+
Requires-Dist: numpy<=2.5.3,>=2.2.1
|
|
55
|
+
Requires-Dist: pandas<=3.0.5,>=2.2.3
|
|
56
|
+
Requires-Dist: pyscal3<=3.3.2,>=3.2.5
|
|
57
|
+
Requires-Dist: scikit-learn==1.9.0
|
|
58
|
+
Requires-Dist: structuretoolkit<=0.0.46,>=0.0.39
|
|
59
|
+
Description-Content-Type: text/markdown
|
|
60
|
+
|
|
61
|
+
# Introduction
|
|
62
|
+
The *Melting* Jupyter notebook allows the fully automated computation of melting points of unary crystals for arbitrary interatomic potentials that are compatible with the molecular dynamics engine [LAMMPS](https://lammps.sandia.gov). It is based on the interface method where the evolution of the solid and the liquid phase are monitored as function of temperature. The only mandatory input parameters required are the chemical element and the interatomic potential file. The melting point protocol itself is implemented in the standalone [`interfacemethod`](https://github.com/pyiron/pyiron_meltingpoint) Python package located in the `src` directory of this repository, the notebook in the `scripts` directory is merely a thin driver around it.
|
|
63
|
+
|
|
64
|
+
# Different Versions
|
|
65
|
+
The melting point simulation protocol is continously improved based on the feedback from different users. This [repository](https://github.com/pyiron/pyiron_meltingpoint) always includes the latest version, older versions are available as tagged releases.
|
|
66
|
+
|
|
67
|
+
* **Version 1.0** - This version was originally published in Computational Materials Science. It uses [ovito](https://www.ovito.org) for structure analysis and supports bcc, fcc and hcp structures.
|
|
68
|
+
* **Version 1.1** - Adds support for diamond structures. In addition [pyscal](https://pyscal.org) is used for structure analysis, python 3.9 support is added as well as support for Mac OS X. On windows it is recommended to use the linux subsystem for windows.
|
|
69
|
+
* **Version 1.2** - Fix numpy Version to 1.19.5.
|
|
70
|
+
* **Version 1.3** - Update dependencies to use `pyiron_atomistics` rather than `pyiron`
|
|
71
|
+
* **Version 2.0** - Modern modular software stack: the [pyiron](http://pyiron.org)- and `snakemake`-based workflow is replaced by [`interfacemethod`](https://github.com/pyiron/pyiron_meltingpoint), a lightweight standalone package. LAMMPS is now driven directly via [lammpsparser](https://github.com/pyiron/lammpsparser), structure analysis uses [structuretoolkit](https://github.com/pyiron/structuretoolkit) and parallel as well as HPC queue execution is handled by [executorlib](https://github.com/pyiron/executorlib). The `interfacemethod` package is published on [PyPI](https://pypi.org) and [conda-forge](https://conda-forge.org), so the melting point protocol can now be installed and used without pyiron.
|
|
72
|
+
|
|
73
|
+
# Installation
|
|
74
|
+
`interfacemethod` and all its dependencies - including LAMMPS - are available on conda-forge and are pinned in the [`environment.yml`](environment.yml) file of this repository. There is no separate installation step for the package itself, installing the environment is sufficient to run the notebooks in the `scripts` folder directly.
|
|
75
|
+
|
|
76
|
+
Either create a new, dedicated environment (the `environment.yml` file does not set a name, so pick one with `-n`):
|
|
77
|
+
```
|
|
78
|
+
conda env create -n pyiron_meltingpoint -f environment.yml
|
|
79
|
+
conda activate pyiron_meltingpoint
|
|
80
|
+
```
|
|
81
|
+
or install the dependencies into an environment you already have activated:
|
|
82
|
+
```
|
|
83
|
+
conda env update -f environment.yml
|
|
84
|
+
```
|
|
85
|
+
`interfacemethod` is also available on PyPI (`pip install interfacemethod`), but LAMMPS itself and a number of the other dependencies are not pure Python packages, so installing via conda/`environment.yml` is the recommended and tested way to get a working setup.
|
|
86
|
+
|
|
87
|
+
This repository is developed and continuously tested primarily on Linux, in addition the unit tests are also tested on macOS; Windows users are recommended to use the Linux subsystem for Windows (WSL).
|
|
88
|
+
|
|
89
|
+
## Run the Jupyter Notebook
|
|
90
|
+
The melting point protocol is executed from [*script.ipynb*](scripts/script.ipynb). Copy the notebook to the directory you want to run the calculation in - typically next to an `input.json` file and the corresponding potential file, for example one of the [examples](examples) discussed below - and start Jupyter there.
|
|
91
|
+
|
|
92
|
+
The first cells of the notebook define the calculation:
|
|
93
|
+
* `project_path` - working directory the individual LAMMPS calculations are executed in.
|
|
94
|
+
* `input_file` / `output_file` - the `input.json` file the calculation is loaded from (if it exists) and the `output.json` file the final melting point prediction as well as the intermediate results are written to.
|
|
95
|
+
* `lmp_command` - the command used to call LAMMPS, by default `lmp -in lmp.in`. To parallelise the individual LAMMPS calls with MPI prefix it accordingly, e.g. `mpirun -n 4 lmp -in lmp.in`.
|
|
96
|
+
* `max_workers` - the number of LAMMPS calculations [executorlib](https://github.com/pyiron/executorlib) is allowed to run concurrently on the local machine.
|
|
97
|
+
* `project_parameter` - the numerical settings of the melting point protocol (number of atoms, run lengths, convergence criteria, ...) together with default values which can be overwritten via the `input.json` file.
|
|
98
|
+
|
|
99
|
+
The content of the `input.json` file is:
|
|
100
|
+
```json
|
|
101
|
+
{
|
|
102
|
+
"config": [
|
|
103
|
+
"pair_style eam/alloy \n",
|
|
104
|
+
"pair_coeff * * Fe-C-Bec07.eam Fe C\n"
|
|
105
|
+
],
|
|
106
|
+
"filename": "Fe-C-Bec07.eam",
|
|
107
|
+
"species": ["Fe", "C"],
|
|
108
|
+
"element": "Fe"
|
|
109
|
+
}
|
|
110
|
+
```
|
|
111
|
+
All remaining cells of the notebook - marked with *"From here on the notebook is automated - no change required"* - execute the interface method fully automatically: an initial melting temperature bracket is estimated, a solid-liquid interface is built and iterated on, and the iteration is repeated until the convergence criterion is reached or a maximum number of iterations is exceeded. The `output.json` file is updated after every step, so an interrupted calculation can be continued by simply rerunning the notebook in the same directory. The last cells of the notebook plot the convergence of the predicted melting temperature over the iterations, no separate analysis notebook is required any more.
|
|
112
|
+
|
|
113
|
+
## Examples
|
|
114
|
+
The [examples](examples) directory contains ready to use `input.json` files and interatomic potentials for a bcc ([Fe](examples/bccFe)), fcc ([Al](examples/fccAl)), hcp ([Mg](examples/hcpMg)) and diamond ([Si](examples/diaSi)) structure, together with a short `README.md` describing the source of each potential. To run one of them, copy `scripts/script.ipynb` into the corresponding example folder and start Jupyter there, so the relative paths in `input.json` resolve correctly:
|
|
115
|
+
```
|
|
116
|
+
cp scripts/script.ipynb examples/bccFe/
|
|
117
|
+
cd examples/bccFe
|
|
118
|
+
jupyter notebook script.ipynb
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
# FAQ
|
|
122
|
+
## How to run in parallel?
|
|
123
|
+
A single melting point calculation takes 50-100 CPU hours, so it makes a lot of sense to run the code in parallel. There are two independent levers:
|
|
124
|
+
* `max_workers` in the notebook controls how many LAMMPS calculations [executorlib](https://github.com/pyiron/executorlib)'s `SingleNodeExecutor` is allowed to dispatch concurrently, e.g. the individual strain points of the interface method are embarrassingly parallel and are submitted at once.
|
|
125
|
+
* `lmp_command` controls how each individual LAMMPS call itself is parallelised, e.g. set it to `"mpirun -n 4 lmp -in lmp.in"` to run every LAMMPS calculation on 4 MPI ranks.
|
|
126
|
+
|
|
127
|
+
## How to submit a melting point calculation to an HPC queue?
|
|
128
|
+
[executorlib](https://github.com/pyiron/executorlib) also provides cluster executors which submit each task as its own job to a queuing system instead of running it on the local machine. Replace `executorlib.SingleNodeExecutor` in the notebook with `executorlib.SlurmClusterExecutor` (for SLURM) or `executorlib.FluxClusterExecutor` (for the [flux](https://flux-framework.org) framework) to submit every LAMMPS run individually to the queue, including the requested number of cores per task via the `resource_dict` argument. See the [executorlib documentation](https://github.com/pyiron/executorlib) for the full list of available executors and their configuration options.
|
|
129
|
+
|
|
130
|
+
# Acknowledgments
|
|
131
|
+
If you use the melting point protocol in your scientific work, please consider citing:
|
|
132
|
+
```
|
|
133
|
+
@article{melting,
|
|
134
|
+
title = {A fully automated approach to calculate the melting temperature of elemental crystals},
|
|
135
|
+
journal = {Computational Materials Science}
|
|
136
|
+
volume = {187},
|
|
137
|
+
pages = {110065},
|
|
138
|
+
year = {2021},
|
|
139
|
+
doi = {https://doi.org/10.1016/j.commatsci.2020.110065},
|
|
140
|
+
url = {https://www.sciencedirect.com/science/article/pii/S0927025620305565},
|
|
141
|
+
author = {Li-Fang Zhu and Jan Janssen and Shoji Ishibashi and Fritz Körmann and Blazej Grabowski and Jörg Neugebauer},
|
|
142
|
+
keywords = {Interface method, Melting point, Arbitrary potential, pyiron},
|
|
143
|
+
}
|
|
144
|
+
|
|
145
|
+
@article{pyiron,
|
|
146
|
+
title = {pyiron: An integrated development environment for computational materials science},
|
|
147
|
+
journal = {Computational Materials Science},
|
|
148
|
+
volume = {163},
|
|
149
|
+
pages = {24 - 36},
|
|
150
|
+
year = {2019},
|
|
151
|
+
issn = {0927-0256},
|
|
152
|
+
doi = {https://doi.org/10.1016/j.commatsci.2018.07.043},
|
|
153
|
+
url = {http://www.sciencedirect.com/science/article/pii/S0927025618304786},
|
|
154
|
+
author = {Jan Janssen and Sudarsan Surendralal and Yury Lysogorskiy and Mira Todorova and Tilmann Hickel and Ralf Drautz and Jörg Neugebauer},
|
|
155
|
+
keywords = {Modelling workflow, Integrated development environment, Complex simulation protocols},
|
|
156
|
+
}
|
|
157
|
+
|
|
158
|
+
@article{pyscal,
|
|
159
|
+
author = {Sarath Menon and Grisell Díaz Leines and Jutta Rogal},
|
|
160
|
+
title = {{pyscal: A python module for structural analysis of atomic environments}},
|
|
161
|
+
year = 2019,
|
|
162
|
+
journal = {Journal of Open Source Software},
|
|
163
|
+
doi = {10.21105/joss.01824},
|
|
164
|
+
url = {https://doi.org/10.21105/joss.01824},
|
|
165
|
+
volume = {4},
|
|
166
|
+
number = {43},
|
|
167
|
+
page = {1824}
|
|
168
|
+
}
|
|
169
|
+
|
|
170
|
+
@article{executorlib,
|
|
171
|
+
title = {Executorlib -- Up-scaling Python workflows for hierarchical heterogenous high-performance computing},
|
|
172
|
+
journal = {Journal of Open Source Software},
|
|
173
|
+
volume = {10},
|
|
174
|
+
number = {108},
|
|
175
|
+
pages = {7782},
|
|
176
|
+
year = {2025},
|
|
177
|
+
issn = {2475-9066},
|
|
178
|
+
doi = {10.21105/joss.07782},
|
|
179
|
+
url = {https://joss.theoj.org/papers/10.21105/joss.07782},
|
|
180
|
+
author = {Jan Janssen and Michael Gilbert Taylor and Ping Yang and Joerg Neugebauer and Danny Perez},
|
|
181
|
+
keywords = {High-performance computing, Workflow management, Python},
|
|
182
|
+
}
|
|
183
|
+
```
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
# Introduction
|
|
2
|
+
The *Melting* Jupyter notebook allows the fully automated computation of melting points of unary crystals for arbitrary interatomic potentials that are compatible with the molecular dynamics engine [LAMMPS](https://lammps.sandia.gov). It is based on the interface method where the evolution of the solid and the liquid phase are monitored as function of temperature. The only mandatory input parameters required are the chemical element and the interatomic potential file. The melting point protocol itself is implemented in the standalone [`interfacemethod`](https://github.com/pyiron/pyiron_meltingpoint) Python package located in the `src` directory of this repository, the notebook in the `scripts` directory is merely a thin driver around it.
|
|
3
|
+
|
|
4
|
+
# Different Versions
|
|
5
|
+
The melting point simulation protocol is continously improved based on the feedback from different users. This [repository](https://github.com/pyiron/pyiron_meltingpoint) always includes the latest version, older versions are available as tagged releases.
|
|
6
|
+
|
|
7
|
+
* **Version 1.0** - This version was originally published in Computational Materials Science. It uses [ovito](https://www.ovito.org) for structure analysis and supports bcc, fcc and hcp structures.
|
|
8
|
+
* **Version 1.1** - Adds support for diamond structures. In addition [pyscal](https://pyscal.org) is used for structure analysis, python 3.9 support is added as well as support for Mac OS X. On windows it is recommended to use the linux subsystem for windows.
|
|
9
|
+
* **Version 1.2** - Fix numpy Version to 1.19.5.
|
|
10
|
+
* **Version 1.3** - Update dependencies to use `pyiron_atomistics` rather than `pyiron`
|
|
11
|
+
* **Version 2.0** - Modern modular software stack: the [pyiron](http://pyiron.org)- and `snakemake`-based workflow is replaced by [`interfacemethod`](https://github.com/pyiron/pyiron_meltingpoint), a lightweight standalone package. LAMMPS is now driven directly via [lammpsparser](https://github.com/pyiron/lammpsparser), structure analysis uses [structuretoolkit](https://github.com/pyiron/structuretoolkit) and parallel as well as HPC queue execution is handled by [executorlib](https://github.com/pyiron/executorlib). The `interfacemethod` package is published on [PyPI](https://pypi.org) and [conda-forge](https://conda-forge.org), so the melting point protocol can now be installed and used without pyiron.
|
|
12
|
+
|
|
13
|
+
# Installation
|
|
14
|
+
`interfacemethod` and all its dependencies - including LAMMPS - are available on conda-forge and are pinned in the [`environment.yml`](environment.yml) file of this repository. There is no separate installation step for the package itself, installing the environment is sufficient to run the notebooks in the `scripts` folder directly.
|
|
15
|
+
|
|
16
|
+
Either create a new, dedicated environment (the `environment.yml` file does not set a name, so pick one with `-n`):
|
|
17
|
+
```
|
|
18
|
+
conda env create -n pyiron_meltingpoint -f environment.yml
|
|
19
|
+
conda activate pyiron_meltingpoint
|
|
20
|
+
```
|
|
21
|
+
or install the dependencies into an environment you already have activated:
|
|
22
|
+
```
|
|
23
|
+
conda env update -f environment.yml
|
|
24
|
+
```
|
|
25
|
+
`interfacemethod` is also available on PyPI (`pip install interfacemethod`), but LAMMPS itself and a number of the other dependencies are not pure Python packages, so installing via conda/`environment.yml` is the recommended and tested way to get a working setup.
|
|
26
|
+
|
|
27
|
+
This repository is developed and continuously tested primarily on Linux, in addition the unit tests are also tested on macOS; Windows users are recommended to use the Linux subsystem for Windows (WSL).
|
|
28
|
+
|
|
29
|
+
## Run the Jupyter Notebook
|
|
30
|
+
The melting point protocol is executed from [*script.ipynb*](scripts/script.ipynb). Copy the notebook to the directory you want to run the calculation in - typically next to an `input.json` file and the corresponding potential file, for example one of the [examples](examples) discussed below - and start Jupyter there.
|
|
31
|
+
|
|
32
|
+
The first cells of the notebook define the calculation:
|
|
33
|
+
* `project_path` - working directory the individual LAMMPS calculations are executed in.
|
|
34
|
+
* `input_file` / `output_file` - the `input.json` file the calculation is loaded from (if it exists) and the `output.json` file the final melting point prediction as well as the intermediate results are written to.
|
|
35
|
+
* `lmp_command` - the command used to call LAMMPS, by default `lmp -in lmp.in`. To parallelise the individual LAMMPS calls with MPI prefix it accordingly, e.g. `mpirun -n 4 lmp -in lmp.in`.
|
|
36
|
+
* `max_workers` - the number of LAMMPS calculations [executorlib](https://github.com/pyiron/executorlib) is allowed to run concurrently on the local machine.
|
|
37
|
+
* `project_parameter` - the numerical settings of the melting point protocol (number of atoms, run lengths, convergence criteria, ...) together with default values which can be overwritten via the `input.json` file.
|
|
38
|
+
|
|
39
|
+
The content of the `input.json` file is:
|
|
40
|
+
```json
|
|
41
|
+
{
|
|
42
|
+
"config": [
|
|
43
|
+
"pair_style eam/alloy \n",
|
|
44
|
+
"pair_coeff * * Fe-C-Bec07.eam Fe C\n"
|
|
45
|
+
],
|
|
46
|
+
"filename": "Fe-C-Bec07.eam",
|
|
47
|
+
"species": ["Fe", "C"],
|
|
48
|
+
"element": "Fe"
|
|
49
|
+
}
|
|
50
|
+
```
|
|
51
|
+
All remaining cells of the notebook - marked with *"From here on the notebook is automated - no change required"* - execute the interface method fully automatically: an initial melting temperature bracket is estimated, a solid-liquid interface is built and iterated on, and the iteration is repeated until the convergence criterion is reached or a maximum number of iterations is exceeded. The `output.json` file is updated after every step, so an interrupted calculation can be continued by simply rerunning the notebook in the same directory. The last cells of the notebook plot the convergence of the predicted melting temperature over the iterations, no separate analysis notebook is required any more.
|
|
52
|
+
|
|
53
|
+
## Examples
|
|
54
|
+
The [examples](examples) directory contains ready to use `input.json` files and interatomic potentials for a bcc ([Fe](examples/bccFe)), fcc ([Al](examples/fccAl)), hcp ([Mg](examples/hcpMg)) and diamond ([Si](examples/diaSi)) structure, together with a short `README.md` describing the source of each potential. To run one of them, copy `scripts/script.ipynb` into the corresponding example folder and start Jupyter there, so the relative paths in `input.json` resolve correctly:
|
|
55
|
+
```
|
|
56
|
+
cp scripts/script.ipynb examples/bccFe/
|
|
57
|
+
cd examples/bccFe
|
|
58
|
+
jupyter notebook script.ipynb
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
# FAQ
|
|
62
|
+
## How to run in parallel?
|
|
63
|
+
A single melting point calculation takes 50-100 CPU hours, so it makes a lot of sense to run the code in parallel. There are two independent levers:
|
|
64
|
+
* `max_workers` in the notebook controls how many LAMMPS calculations [executorlib](https://github.com/pyiron/executorlib)'s `SingleNodeExecutor` is allowed to dispatch concurrently, e.g. the individual strain points of the interface method are embarrassingly parallel and are submitted at once.
|
|
65
|
+
* `lmp_command` controls how each individual LAMMPS call itself is parallelised, e.g. set it to `"mpirun -n 4 lmp -in lmp.in"` to run every LAMMPS calculation on 4 MPI ranks.
|
|
66
|
+
|
|
67
|
+
## How to submit a melting point calculation to an HPC queue?
|
|
68
|
+
[executorlib](https://github.com/pyiron/executorlib) also provides cluster executors which submit each task as its own job to a queuing system instead of running it on the local machine. Replace `executorlib.SingleNodeExecutor` in the notebook with `executorlib.SlurmClusterExecutor` (for SLURM) or `executorlib.FluxClusterExecutor` (for the [flux](https://flux-framework.org) framework) to submit every LAMMPS run individually to the queue, including the requested number of cores per task via the `resource_dict` argument. See the [executorlib documentation](https://github.com/pyiron/executorlib) for the full list of available executors and their configuration options.
|
|
69
|
+
|
|
70
|
+
# Acknowledgments
|
|
71
|
+
If you use the melting point protocol in your scientific work, please consider citing:
|
|
72
|
+
```
|
|
73
|
+
@article{melting,
|
|
74
|
+
title = {A fully automated approach to calculate the melting temperature of elemental crystals},
|
|
75
|
+
journal = {Computational Materials Science}
|
|
76
|
+
volume = {187},
|
|
77
|
+
pages = {110065},
|
|
78
|
+
year = {2021},
|
|
79
|
+
doi = {https://doi.org/10.1016/j.commatsci.2020.110065},
|
|
80
|
+
url = {https://www.sciencedirect.com/science/article/pii/S0927025620305565},
|
|
81
|
+
author = {Li-Fang Zhu and Jan Janssen and Shoji Ishibashi and Fritz Körmann and Blazej Grabowski and Jörg Neugebauer},
|
|
82
|
+
keywords = {Interface method, Melting point, Arbitrary potential, pyiron},
|
|
83
|
+
}
|
|
84
|
+
|
|
85
|
+
@article{pyiron,
|
|
86
|
+
title = {pyiron: An integrated development environment for computational materials science},
|
|
87
|
+
journal = {Computational Materials Science},
|
|
88
|
+
volume = {163},
|
|
89
|
+
pages = {24 - 36},
|
|
90
|
+
year = {2019},
|
|
91
|
+
issn = {0927-0256},
|
|
92
|
+
doi = {https://doi.org/10.1016/j.commatsci.2018.07.043},
|
|
93
|
+
url = {http://www.sciencedirect.com/science/article/pii/S0927025618304786},
|
|
94
|
+
author = {Jan Janssen and Sudarsan Surendralal and Yury Lysogorskiy and Mira Todorova and Tilmann Hickel and Ralf Drautz and Jörg Neugebauer},
|
|
95
|
+
keywords = {Modelling workflow, Integrated development environment, Complex simulation protocols},
|
|
96
|
+
}
|
|
97
|
+
|
|
98
|
+
@article{pyscal,
|
|
99
|
+
author = {Sarath Menon and Grisell Díaz Leines and Jutta Rogal},
|
|
100
|
+
title = {{pyscal: A python module for structural analysis of atomic environments}},
|
|
101
|
+
year = 2019,
|
|
102
|
+
journal = {Journal of Open Source Software},
|
|
103
|
+
doi = {10.21105/joss.01824},
|
|
104
|
+
url = {https://doi.org/10.21105/joss.01824},
|
|
105
|
+
volume = {4},
|
|
106
|
+
number = {43},
|
|
107
|
+
page = {1824}
|
|
108
|
+
}
|
|
109
|
+
|
|
110
|
+
@article{executorlib,
|
|
111
|
+
title = {Executorlib -- Up-scaling Python workflows for hierarchical heterogenous high-performance computing},
|
|
112
|
+
journal = {Journal of Open Source Software},
|
|
113
|
+
volume = {10},
|
|
114
|
+
number = {108},
|
|
115
|
+
pages = {7782},
|
|
116
|
+
year = {2025},
|
|
117
|
+
issn = {2475-9066},
|
|
118
|
+
doi = {10.21105/joss.07782},
|
|
119
|
+
url = {https://joss.theoj.org/papers/10.21105/joss.07782},
|
|
120
|
+
author = {Jan Janssen and Michael Gilbert Taylor and Ping Yang and Joerg Neugebauer and Danny Perez},
|
|
121
|
+
keywords = {High-performance computing, Workflow management, Python},
|
|
122
|
+
}
|
|
123
|
+
```
|
|
@@ -0,0 +1,120 @@
|
|
|
1
|
+
[build-system]
|
|
2
|
+
requires = [
|
|
3
|
+
"hatchling==1.32.0",
|
|
4
|
+
"hatch-vcs==0.5.0",
|
|
5
|
+
"ase",
|
|
6
|
+
"lammpsparser",
|
|
7
|
+
"matplotlib",
|
|
8
|
+
"numpy",
|
|
9
|
+
"pandas",
|
|
10
|
+
"pyscal3",
|
|
11
|
+
"scikit-learn",
|
|
12
|
+
"structuretoolkit",
|
|
13
|
+
]
|
|
14
|
+
build-backend = "hatchling.build"
|
|
15
|
+
|
|
16
|
+
[project]
|
|
17
|
+
name = "interfacemethod"
|
|
18
|
+
description = "A fully automated approach to determine the melting temperature of crystalline materials."
|
|
19
|
+
authors = [
|
|
20
|
+
{ name = "Jan Janssen", email = "janssen@mpi-susmat.de" },
|
|
21
|
+
]
|
|
22
|
+
readme = "README.md"
|
|
23
|
+
license = { file = "LICENSE" }
|
|
24
|
+
keywords = ["atomistic", "melting", "interface method", "lammps"]
|
|
25
|
+
requires-python = ">3.9, <3.15"
|
|
26
|
+
classifiers = [
|
|
27
|
+
"Development Status :: 5 - Production/Stable",
|
|
28
|
+
"Topic :: Scientific/Engineering :: Physics",
|
|
29
|
+
"License :: OSI Approved :: BSD License",
|
|
30
|
+
"Intended Audience :: Science/Research",
|
|
31
|
+
"Operating System :: OS Independent",
|
|
32
|
+
"Programming Language :: Python :: 3.10",
|
|
33
|
+
"Programming Language :: Python :: 3.11",
|
|
34
|
+
"Programming Language :: Python :: 3.12",
|
|
35
|
+
"Programming Language :: Python :: 3.13",
|
|
36
|
+
"Programming Language :: Python :: 3.14",
|
|
37
|
+
]
|
|
38
|
+
dependencies = [
|
|
39
|
+
"ase>=3.23.0,<=3.29.0",
|
|
40
|
+
"lammpsparser>=0.0.1,<=0.0.9",
|
|
41
|
+
"matplotlib==3.11.1",
|
|
42
|
+
"numpy>=2.2.1,<=2.5.3",
|
|
43
|
+
"pandas>=2.2.3,<=3.0.5",
|
|
44
|
+
"pyscal3>=3.2.5,<=3.3.2",
|
|
45
|
+
"scikit-learn==1.9.0",
|
|
46
|
+
"structuretoolkit>=0.0.39,<=0.0.46",
|
|
47
|
+
]
|
|
48
|
+
dynamic = ["version"]
|
|
49
|
+
|
|
50
|
+
[project.urls]
|
|
51
|
+
Homepage = "http://pyiron.org/pyiron_meltingpoint/"
|
|
52
|
+
Documentation = "http://pyiron.org/pyiron_meltingpoint/"
|
|
53
|
+
Repository = "https://github.com/pyiron/pyiron_meltingpoint"
|
|
54
|
+
|
|
55
|
+
[tool.ruff]
|
|
56
|
+
exclude = [".ci_support", "examples", "scripts", "tests", "_version.py"]
|
|
57
|
+
|
|
58
|
+
[tool.ruff.lint]
|
|
59
|
+
select = [
|
|
60
|
+
# pycodestyle
|
|
61
|
+
"E",
|
|
62
|
+
# Pyflakes
|
|
63
|
+
"F",
|
|
64
|
+
# pyupgrade
|
|
65
|
+
"UP",
|
|
66
|
+
# flake8-bugbear
|
|
67
|
+
"B",
|
|
68
|
+
# flake8-simplify
|
|
69
|
+
"SIM",
|
|
70
|
+
# isort
|
|
71
|
+
"I",
|
|
72
|
+
# flake8-comprehensions
|
|
73
|
+
"C4",
|
|
74
|
+
# eradicate
|
|
75
|
+
"ERA",
|
|
76
|
+
# pylint
|
|
77
|
+
"PL",
|
|
78
|
+
]
|
|
79
|
+
ignore = [
|
|
80
|
+
# ignore line-length violations
|
|
81
|
+
"E501",
|
|
82
|
+
# ignore imports which are not at the top of a module
|
|
83
|
+
"PLC0415",
|
|
84
|
+
# Too many branches
|
|
85
|
+
"PLR0912",
|
|
86
|
+
# Too many arguments in function definition
|
|
87
|
+
"PLR0913",
|
|
88
|
+
# Too many statements
|
|
89
|
+
"PLR0915",
|
|
90
|
+
# Too many not-keyword-only arguments,
|
|
91
|
+
"PLR0917",
|
|
92
|
+
# Magic value used in comparison
|
|
93
|
+
"PLR2004",
|
|
94
|
+
]
|
|
95
|
+
|
|
96
|
+
[tool.hatch.build]
|
|
97
|
+
include = [
|
|
98
|
+
"src/interfacemethod"
|
|
99
|
+
]
|
|
100
|
+
|
|
101
|
+
[tool.hatch.build.hooks.vcs]
|
|
102
|
+
version-file = "src/interfacemethod/_version.py"
|
|
103
|
+
|
|
104
|
+
[tool.hatch.build.targets.sdist]
|
|
105
|
+
include = [
|
|
106
|
+
"src/interfacemethod"
|
|
107
|
+
]
|
|
108
|
+
|
|
109
|
+
[tool.hatch.build.targets.wheel]
|
|
110
|
+
packages = [
|
|
111
|
+
"src/interfacemethod"
|
|
112
|
+
]
|
|
113
|
+
|
|
114
|
+
[tool.hatch.version]
|
|
115
|
+
source = "vcs"
|
|
116
|
+
path = "src/interfacemethod/_version.py"
|
|
117
|
+
|
|
118
|
+
[tool.coverage.run]
|
|
119
|
+
source = ["interfacemethod"]
|
|
120
|
+
command_line = "-m unittest discover tests"
|