Hi, Stephen, I heard about this project in Prof. Hennig's talk yesterday. I'm wondering is the present version able to train the uf3 potentials with the VASP's forces and energies data? Thank you very much!

Yuewen

Hi, I am trying to fit a UF2 model for SiC, based on Formation energies and forces, the dataset generated by annealing MD calculation 200~ snapshot configurations. Here is the splines curve I got for 5/200, 20/200, 40/200, and 80/200 training datasets, respectively.

Where, ridge_1b=1e-6, curvature_2b=1e-4, batch_size=5, weight=0.5

Besides, I also tested smaller curvature_2b values, eg. 1e-2, even 1e-1, unfortunately, as shown below (Training:80/200, curvature_2b=1e-1, batch_size=5), it's also the same case. I would appreciate it if you have any clue about that!!

However, the prediction looks perfect, I kinda confused by this.

Problem description

When calculating three-body energy and force contributions, results change depending on whether interactions are computed across periodic boundaries or not.

To reproduce, I have created a 10x10x10 cell with four atoms. When the atoms are placed in the middle of the cell, such that activating or deactivating PBC does not change results, contributions are computed correctly. However, if atoms are moved towards a boundary and one atom moves to the top of the box (no atoms have positions outside the box), contributions are incorrect, possibly added multiple times.

The potential file only contains coefficients for three-body, one- and two-body coefficients are 0. All coefficients for three-body contributions are the same.

Potential file: https://pastebin.com/bfD8R0Rb

4    atoms 
2  atom types
0.0      10  xlo xhi
0.0      10  ylo yhi
0.0      10  zlo zhi

Atoms 

   1   2      0 4 5
   2   1      0 4 6
   3   2      0 5 5
   4   1      0 4 4
   

4    atoms 
2  atom types
0.0      10  xlo xhi
0.0      10  ylo yhi
0.0      10  zlo zhi

Atoms 

   1   2      0 4 0.5
   2   1      0 4 1.5
   3   2      0 5 0.5
   4   1      0 4 9.5
        

To reproduce the problem, use the files above and run:

# Imports
from uf3.representation import bspline
from uf3.representation import process
from uf3.util import json_io
from uf3.regression import least_squares
from uf3.forcefield import calculator
from uf3.forcefield import lammps
from uf3.util import plotting
from uf3.data import io
from uf3.data import composition
import ase

model = least_squares.WeightedLinearModel.from_json("model.json")
calc = calculator.UFCalculator(model)

test = ase.io.lammpsdata.read_lammps_data("test_m.data", style="atomic")
test.symbols = "OZrOZr"
test.pbc=True
test.wrap()
test.set_calculator(calc)
print(test.get_potential_energy())

test = ase.io.lammpsdata.read_lammps_data("test_b.data", style="atomic")
test.symbols = "OZrOZr"
test.pbc=True
test.wrap()
test.set_calculator(calc)
print(test.get_potential_energy())

The energies should match, since the atoms are simply moved by 5 units in z-direction, but don't:

-43168.42282486064
-37056.21139709316

While this only demonstrates the issue for the UFCalculator, it could potentially affect training if the same issue occurs when generating supercells there.

Possible causes could be symmetries, there was a fix that ensures symmetry when j and k are switched, or interactions that select the wrong central atom, but those are a shot in the dark.

Problem description

After loading a model from a json file, the model's performance is significantly decreased:

| | MAE Energies | MAE Forces | RMSE Energies | RMSE Forces | |----------------------|--------------|------------|---------------|-------------| | Model after training | 0.005 | 0.184 | 0.006 | 0.250 | | Model after loading | 0.026 | 0.245 | 0.027 | 0.317 |

This behavior appears to be because of the compress_3B and decompress_3B methods in bspline.py.

Decompressing coefficients from a model and compressing them again results in different arrays of coefficients and cause different results after loading.

Solution

Changing the decompress method to work correctly results in wrong coefficients for the UFCalculator and the LAMMPS implementation. A possible fix could, therefore, be a distinction between loading coefficients that had flat_weights applied to them during decompressing and multiplying all coefficients by 0.5 and applying the flat_weights in all other cases when compressing coefficients.

This results in correct model loading, but I cannot assess possible side effects, so input on this is appreciated.

When training with a single image in the database, we get an error because the standard deviation is 0. While training with a single image is rare, I believe this should be considered a base case.

"Custom" is an option for knot strategy. However, its implementation is currently broken. That is, it will result in an error when used. The problem seems to be that it has "pass" on the get_spacer function so we get the following error: UnboundLocalError: local variable 'spacing_function' referenced before assignment

Problem description

When exporting a trained model using WeightedLinearModel.save, floats are formatted using Python's format with the "g" parameter that has a default precision of 6.

The class that handles this is CompactJSONEncoder:

https://github.com/uf3/uf3/blob/f2ad1a23f5b38695894378803dc54f25139b1a3d/uf3/util/json_io.py#L138-L140

For a model I trained, this precision is too small, resulting in prediction errors when loading the model from the .json file.

Example

I attached the solutions of the model here. The first output shows the solutions directly after training, and the second output shows the solutions after saving and loading.

{'solution': {'Zr': -20560.33609234794,
'O': -41120.412798809746,
('O',
 'O'): array([ 5.26435439e+00,  5.20311465e+00,  5.08063516e+00,  4.89691593e+00,
        4.65195696e+00,  4.34575824e+00,  3.97831977e+00,  3.54964157e+00,
        3.05972362e+00,  2.50856592e+00,  1.89616849e+00,  1.22868659e+00,
        7.30053245e-01,  4.31556715e-01,  2.46165334e-01,  1.24437004e-01,
        5.93001720e-02,  2.74566934e-02,  1.30984740e-02,  3.16545758e-03,
        8.15071387e-04,  1.64258524e-04, -6.46071392e-03, -9.32398478e-03,
       -1.06880467e-02,  0.00000000e+00,  0.00000000e+00,  0.00000000e+00]),
('Zr',
 'O'): array([ 2.57773141,  2.48379049,  2.29590865,  2.01408589,  1.63832222,
        1.16861763,  0.60497211, -0.05261432, -0.80414166, -1.64960993,
       -2.08524704, -1.9352091 , -1.61253899, -1.27462536, -0.97011593,
       -0.72222357, -0.53059997, -0.37511157, -0.26761948, -0.19630742,
       -0.1364386 , -0.08911125, -0.05464061, -0.02995521, -0.0185196 ,
        0.        ,  0.        ,  0.        ]),
('Zr',
 'Zr'): array([7.63423726, 7.59087987, 7.50416508, 7.37409289, 7.20066331,
       6.98387633, 6.72373196, 6.42023019, 6.07337103, 5.68315447,
       5.24958052, 4.77264917, 4.25236043, 3.68871429, 3.08171076,
       2.43142205, 1.77394657, 1.3332101 , 0.99423793, 0.73174477,
       0.51741219, 0.35220643, 0.2297151 , 0.13608243, 0.05597425,
       0.        , 0.        , 0.        ])},
'knots': {('O',
 'O'): array([1.0e-06, 1.0e-06, 1.0e-06, 1.0e-06, 2.0e-01, 4.0e-01, 6.0e-01,
       8.0e-01, 1.0e+00, 1.2e+00, 1.4e+00, 1.6e+00, 1.8e+00, 2.0e+00,
       2.2e+00, 2.4e+00, 2.6e+00, 2.8e+00, 3.0e+00, 3.2e+00, 3.4e+00,
       3.6e+00, 3.8e+00, 4.0e+00, 4.2e+00, 4.4e+00, 4.6e+00, 4.8e+00,
       5.0e+00, 5.0e+00, 5.0e+00, 5.0e+00]),
('Zr',
 'O'): array([1.0e-06, 1.0e-06, 1.0e-06, 1.0e-06, 2.0e-01, 4.0e-01, 6.0e-01,
       8.0e-01, 1.0e+00, 1.2e+00, 1.4e+00, 1.6e+00, 1.8e+00, 2.0e+00,
       2.2e+00, 2.4e+00, 2.6e+00, 2.8e+00, 3.0e+00, 3.2e+00, 3.4e+00,
       3.6e+00, 3.8e+00, 4.0e+00, 4.2e+00, 4.4e+00, 4.6e+00, 4.8e+00,
       5.0e+00, 5.0e+00, 5.0e+00, 5.0e+00]),
('Zr',
 'Zr'): array([1.0e-06, 1.0e-06, 1.0e-06, 1.0e-06, 2.0e-01, 4.0e-01, 6.0e-01,
       8.0e-01, 1.0e+00, 1.2e+00, 1.4e+00, 1.6e+00, 1.8e+00, 2.0e+00,
       2.2e+00, 2.4e+00, 2.6e+00, 2.8e+00, 3.0e+00, 3.2e+00, 3.4e+00,
       3.6e+00, 3.8e+00, 4.0e+00, 4.2e+00, 4.4e+00, 4.6e+00, 4.8e+00,
       5.0e+00, 5.0e+00, 5.0e+00, 5.0e+00])}}

{'solution': {'Zr': -20560.3,
 'O': -41120.4,
 ('O',
  'O'): array([ 5.26435e+00,  5.20311e+00,  5.08064e+00,  4.89692e+00,
         4.65196e+00,  4.34576e+00,  3.97832e+00,  3.54964e+00,
         3.05972e+00,  2.50857e+00,  1.89617e+00,  1.22869e+00,
         7.30053e-01,  4.31557e-01,  2.46165e-01,  1.24437e-01,
         5.93001e-02,  2.74567e-02,  1.30984e-02,  3.16543e-03,
         8.15054e-04,  1.64246e-04, -6.46072e-03, -9.32399e-03,
        -1.06880e-02,  0.00000e+00,  0.00000e+00,  0.00000e+00]),
 ('Zr',
  'O'): array([ 2.57773  ,  2.48379  ,  2.29591  ,  2.01409  ,  1.63832  ,
         1.16862  ,  0.604972 , -0.0526146, -0.804142 , -1.64961  ,
        -2.08525  , -1.93521  , -1.61254  , -1.27463  , -0.970116 ,
        -0.722224 , -0.5306   , -0.375112 , -0.26762  , -0.196307 ,
        -0.136439 , -0.0891113, -0.0546406, -0.0299552, -0.0185196,
         0.       ,  0.       ,  0.       ]),
 ('Zr',
  'Zr'): array([7.63424  , 7.59088  , 7.50417  , 7.37409  , 7.20066  , 6.98388  ,
        6.72373  , 6.42023  , 6.07337  , 5.68316  , 5.24958  , 4.77265  ,
        4.25236  , 3.68872  , 3.08171  , 2.43142  , 1.77395  , 1.33321  ,
        0.994238 , 0.731745 , 0.517412 , 0.352207 , 0.229715 , 0.136083 ,
        0.0559743, 0.       , 0.       , 0.       ])},
'knots': {('O',
  'O'): array([1.0e-06, 1.0e-06, 1.0e-06, 1.0e-06, 2.0e-01, 4.0e-01, 6.0e-01,
        8.0e-01, 1.0e+00, 1.2e+00, 1.4e+00, 1.6e+00, 1.8e+00, 2.0e+00,
        2.2e+00, 2.4e+00, 2.6e+00, 2.8e+00, 3.0e+00, 3.2e+00, 3.4e+00,
        3.6e+00, 3.8e+00, 4.0e+00, 4.2e+00, 4.4e+00, 4.6e+00, 4.8e+00,
        5.0e+00, 5.0e+00, 5.0e+00, 5.0e+00]),
 ('Zr',
  'O'): array([1.0e-06, 1.0e-06, 1.0e-06, 1.0e-06, 2.0e-01, 4.0e-01, 6.0e-01,
        8.0e-01, 1.0e+00, 1.2e+00, 1.4e+00, 1.6e+00, 1.8e+00, 2.0e+00,
        2.2e+00, 2.4e+00, 2.6e+00, 2.8e+00, 3.0e+00, 3.2e+00, 3.4e+00,
        3.6e+00, 3.8e+00, 4.0e+00, 4.2e+00, 4.4e+00, 4.6e+00, 4.8e+00,
        5.0e+00, 5.0e+00, 5.0e+00, 5.0e+00]),
 ('Zr',
  'Zr'): array([1.0e-06, 1.0e-06, 1.0e-06, 1.0e-06, 2.0e-01, 4.0e-01, 6.0e-01,
        8.0e-01, 1.0e+00, 1.2e+00, 1.4e+00, 1.6e+00, 1.8e+00, 2.0e+00,
        2.2e+00, 2.4e+00, 2.6e+00, 2.8e+00, 3.0e+00, 3.2e+00, 3.4e+00,
        3.6e+00, 3.8e+00, 4.0e+00, 4.2e+00, 4.4e+00, 4.6e+00, 4.8e+00,
        5.0e+00, 5.0e+00, 5.0e+00, 5.0e+00])}}

The most apparent difference is in the one-body offsets: After training: 'Zr': -20560.33609234794 After loading: 'Zr': -20560.3

Impact on prediction accuracy

This decreased precision noticeably affects the model's performance:

Model with original precision:

Loaded model with 6 digit precision:

Solution

Increasing the accuracy to 20 digits, using format(0, ".20g") instead of format(0, "g"), solves the issue for my model. However, I cannot assess whether this precision is large enough for other models or if other issues arise from this. Maybe someone has input on this so that this issue can be resolved.

• [WIP] Three-body contributions for UFCalculator for multicomponent systems are experiencing some minor bugs
• Three-body contributions for UFLammps will require a tensor-product spline evaluator in C++ for LAMMPS

This PR introduces the required changes to publish the package automatically to PyPi:

1. Gather all the modules and submodules correctly in setup.py
2. Link this repository as the project website
3. Add __init__py to uf3.forcefield.properties
4. Add MANIFEST.in to upload requirements.txt and readme.rst correctly
5. Update requirements.txt to include all required and optional dependencies. This breaks pip install -r requirement.txt, but this step can be omitted as pip install . installs requirements automatically.
6. Update tests to use new install mechanism (No more manual dependency installing)
7. Add script to automatically publish to PyPi. This step can be extended to fetch the release number from the GitHub release if the pipeline works correctly.

To complete the setup, a PyPi account secret needs to be configured in GitHub. This secret needs to have full account privileges for the first release, but can then be adapted to only allow access to the correct package.

A demo of the pipeline has been tested in https://github.com/henk789/uf3 and is available at https://test.pypi.org/project/uf3/.

Prepare a new release to fix critical issues with model loading and multi-component systems:

• #28 Models were not correctly loaded from json files
• #30 Interactions across PBCs were assigned wrong element types, causing the model to learn on wrong interactions

Issue description

The current element sorting method returns lists and sorts every element. This leads to runtime exceptions when loading models and incorrect three-body interactions. This issue is fixed by using the sort_interaction_symbols method that returns tuples and fixes central elements.

This PR addresses #4 and adds a functional CLI.

Added Features

The following functionalities are implemented:

Generating initial config with specified atoms

• [x] Create initial config with degree and atoms

Collecting DFT data

• [x] Collecting DFT data from single '.xyz' file/list of '.xyz' files
• [x] Automatically searching working directory for '.xyz' files
• [x] Converting '.xyz' files to data frame and storing as pickled file
• [ ] Loading different DFT files
• [ ] Split into train-test-validation
• [ ] Adjusting column prefix

Featurization

• [x] Loading pickled files
• [x] Loading '.xyz' files
• [x] Automatic core count detection
• [x] Specifying r_min/r_max/res_map as dict
• [x] Specifying r_min/r_max/res_map as int/float and apply to all interactions
• [x] Exporting features to file
• [ ] Exporting features to data frame
• [ ] Knot strategies
• [ ] Loading and dumping knots
• [ ] Only training on energies

Fitting

• [x] Same parameters as with Python featurization
• [x] Exporting model to json file
• [x] Predict with fitted model
• [x] Test errors (RMSE and MAE)
• [x] Train on subset of featurized data
• [x] Predict on subset of featurized data

Misc

• [x] Automatic installation for easy use
• [ ] Default settings file
• [ ] Settings file from bspline_config

YAML parameters not yet used:

• seed
• data
  • db_path
  • max_per_file
  • min_diff
  • generate_stats
  • vasp_pressure
  • sources
    • pattern
• basis
  • fit_offsets
  • mask_trim
  • knot_strategy
  • knots_path
  • load_knots
  • dump_knots
• features
  • db_path
  • fit_forces
  • column_prefix
• learning
  • splits_path

YAML parameters added:

• verbose
• data
  • pickle_path
  • train_pickle
  • test_pickle
• features
  • batch_size
  • table_template
• learning
  • batch_size

Usage

The CLI enables quick generation of models. The tungsten example can be executed in three lines:

> uf3_cli config 3 W
> uf3_cli collect options.yaml
> uf3_cli featurize options.yaml
> uf3_cli fit options.yaml

with the required file names and training settings specified in options.yaml

The code is robust towards errors and performs type conversion where possible.

Problem description

When loading a model that has knot resolution 0 for an interaction, using UFCalculator results in an error message:

Traceback (most recent call last):
  File "/home/***/***/***/.conda/envs/uf3_env/lib/python3.8/concurrent/futures/process.py", line 239, in _process_worker
    r = call_item.fn(*call_item.args, **call_item.kwargs)
  File "/scratch/slurm_tmpdir/job_21050829/ipykernel_1790295/233011300.py", line 22, in eval
    p_f = np.append(p_f, geom.get_forces())
  File "/home/***/***/***/.conda/envs/uf3_env/lib/python3.8/site-packages/ase/atoms.py", line 788, in get_forces
    forces = self._calc.get_forces(self)
  File "/pfs/data5/home/***/***/***/ba/uf3/uf3/forcefield/calculator.py", line 215, in get_forces
    f_3b = self.forces_3b(atoms, supercell)
  File "/pfs/data5/home/***/***/***/ba/uf3/uf3/forcefield/calculator.py", line 288, in forces_3b
    val_l = spline(triangles, nus=np.array([1, 0, 0]))
  File "/home/***/***/***/.conda/envs/uf3_env/lib/python3.8/site-packages/ndsplines/ndsplines.py", line 220, in __call__
    self.compute_basis_coefficient_selector(x, nus)
  File "/home/***/***/***/.conda/envs/uf3_env/lib/python3.8/site-packages/ndsplines/ndsplines.py", line 172, in compute_basis_coefficient_selector
    impl.evaluate_spline(t, k, x[:,i], nu, extrapolate_flag, self.interval_workspace[i], self.basis_workspace[i],)
  File "ndsplines/_bspl.pyx", line 96, in ndsplines._bspl.evaluate_spline
ValueError: Buffer dtype mismatch, expected 'const double' but got 'long'

Solution

The issue arises due to the JSON parsing used when loading models. Since the seven knot positions are all 0, they are loaded as integers. However, the ndspline package requires double. Therefore, the issue can be avoided when converting integer knot positions to doubles.

Currently, parsed data from VASP, LAMMPS, etc is organized into a pandas dataframe by io.DataCoordinator with separate columns for energies (E), force-components (Fx, Fy, and Fz), and atoms per unit cell ("Size")

We can have three additional user-parameters and a function to remove rows from the dataframe that exceed these constraints:

1. Maximum energy (eV/atom)
2. Maximum force (eV/angstrom)
3. Maximum number of atoms per unit cell

Note: force magnitudes should probably be considered per-atom rather than component-wise.

• Standalone scripts from the alpha version are currently incompatible with the latest refactor. They need to be rewritten, preferably with additional support for argparse.
• Documentation for options and the input yaml are already complete.

• [WIP] Three-body contributions for UFCalculator for multicomponent systems are experiencing some minor bugs
• Three-body contributions for UFLammps will require a tensor-product spline evaluator in C++ for LAMMPS