Fitting certain parameters in Tersoff potential returns RuntimeError: the model does not provide an Extension routine

[dengtq]

When fitting certain parameters in Tersoff potential from openkim, the following RuntimeError is returned:

File ***/.conda/envs/kliff/lib/python3.9/site-packages/kliff/models/kim.py", line 352, in compute
    raise kimpy.KimPyError("Calling `kim_model.compute()` failed.")
kimpy.err.KimPyError:
ERROR(@compute): Calling `kim_model.compute()` failed.
Traceback (most recent call last):
  File "***/.conda/envs/kliff/lib/python3.9/site-packages/kliff/models/kim.py", line 350, in compute
    kim_model.compute(self.kim_ca)
RuntimeError: the model does not provide an Extension routine!  or
the model's Extension routine returns error!

What is the cause of this error? Does that mean certain parameters cannot be optimized using kliff? Thank you for kind reply.

Environment:
Linux+Conda+python3.9
kim-api 2.3.0
kimpy 2.1.1
kliff 0.4.3

Tersoff potential from openkim: Tersoff_LAMMPS_Tersoff_1989_SiC__MO_171585019474_004

[mjwen]

@ilia-nikiforov-umn @ellio167 any idea?

Does this mean the Tersoff driver does not expose parameters?

[dengtq]

I'd clarify that this only happens for some of the parameters (Rc and Dc for example), while optimization of some other parameters like A and B works normally.

[ellio167]

This error message comes from here (in kimpy):

https://github.com/openkim/kimpy/blob/75c8287d9c92cd3e1f86ceeeab32f6fa93f02319/kimpy/KIM_Model_bind.cpp#L191

I don't understand the error message text about an "Extension routine". It seems to just be the case that the compute routine has returned and error.

My next step would be to look for error messages in the kim.log file to see if more information about the compute() error is provided.

[dengtq]

Thank you @ellio167 for the suggestion!

I have tested all parameters in Tersoff potential and looked into the kim.log file of failed ones.

For beta, the kim.log mentioned that Parameter beta (Si-Si) may not be smaller than zero.. So this is due to the parameter constraint and is resolved after I transform beta into logscale by defining a custom ParameterTransform class.

The case for Rc and Dc are different though. They return the following error:

2025-03-06:12:09:27CST * 0 * error * 0x5564613aff90_0x5564612ff790 * KIM_ComputeArgumentsImplementation.cpp:886 * Simulator supplied GetNeighborList() routine returned error.
2025-03-06:12:09:27CST * 0 * error * 0x5564613aff90 * model_driver_Tersoff.cpp:211 * compute: Error in KIM::ModelComputeArguments.GetNeighborList
2025-03-06:12:09:27CST * 1 * error * 0x5564613aff90 * KIM_ModelImplementation.cpp:2664 * Model supplied Compute() routine returned error.

And it cannot be resolved if I keep Rc and Dc positive using log transformation.

I thought this originates from the change in cutoff radius. However, even if I keep Rc and Dc fixed to the original or a different value using the 'fix' option in set_opt_params while optimizing other parameters, the same error still appears. So I cannot tune the Rc and Dc values manually using the 'fix' option in set_opt_params.

Any suggestions will be greatly appreciated.

[mjwen]

Hi @dengtq , great observations!

Yes, parameters related to the cutoff distance should not be optimized. This is because, to speed up the fitting, KLIFF and many other fitting codes only generate the neighborlist once at the beginning and re-use it for later calculations. So, if params related to cutoff are optimized, there can be problems related to the neighborlist.

You are on the right track to use fix to manually set cutoff-related parameters. I think set_opt_params should work for this purpose. It might be ParameterTransform has transformed Rc and Dc to some incorrect values. I'd suggest first not using ParameterTransform to ensure you can get the fitting running OK and then adding it back. You can also try this tutorial to ensure it can run ok, where set_opt_params and fix are used together https://kliff.readthedocs.io/en/latest/tutorials/kim_SW_Si.html

[dengtq]

@mjwen Thank you for the suggestion! So I just ran a few tests according to your suggestion and here's the observation.

I tried to fix Rc to the original value while optimizing A. This optimization succeeded without error. I then fixed Rc to an increased value while optimizing A. This run returned the same GetNeighborList error.

I then switched to the SW test, and it is identical to the case of Tersoff. If I fix cutoff to its original value while optimizing other parameters, no error is thrown. But if the cutoff is increased, it again fails with GetNeighborList error.

Interestingly, if the cutoff is reduced, there is no error, either.

My guess is that the neighbor list is calculated when initializing KIMModel, so if I change it with set_opt_params, the neighbor list remains unchanged. Thus an increased cutoff will cause error. Is that correct?

[mjwen]

It makes sense that a smaller cutoff works fine, seems the previous larger cutoff should contain enough atoms.

It is unexpected that setting to a larger value leads to a failing run. Here is how it works internally:

• KIMModel will only initialize the model and parameters, including cutoff. A call of set_opt_params will update these parameters.
• KIMModel will not create neighborlist.
• The neighborlist will be created in Calculator. It takes model (i.e. KIMModel) as an argument, and will a) get the cutoff from model and b) create the neighborlist.
  So, if we call set_opt_params before creating Calculator, everything should be OK, since Calculator should get the updated cutoff.

There seems to be something fishy going on. I will need some time to figure out the reason. Will update here.

[dengtq]

Thank you for the prompted response! I also checked my script and confirmed that Calculator is indeed created after set_opt_params.

The behavior can be reproduced using the SW test script and training set by adding cutoff to set_opt_params.

Look forward to your update.

[dengtq]

Hi @mjwen , I think I've found some clues.

I print model.kim_model.get_influence_distance() and model.get_influence_distance()} at every step and notice that after model.set_opt_params, the return of model.kim_model.get_influence_distance() is updated but model.get_influence_distance()} is not. And Calculator uses model.get_influence_distance()} directly.

Meanwhile, KIMModel does not have its own get_influence_distance() and the method in parent class Model simply return self.influence_distance which I guess was not updated.

My current fix is to add the following method to KIMModel:

    def get_influence_distance(self) -> float:
        return self.kim_model.get_influence_distance()

And it is now working with an increased cutoff!

If it is not breaking anything, I guess I'll use this fix for now. Please kindly help confirm that this is a valid fix.

UPDATE some additional observations:

After employing the above fix, the optimization will fail again with any params_transform set in KIMModel. Even if params_transform=ParameterTransform() which does not perform any transformation at all. Without params_transform it works alright both for SW and Tersoff.

And both model.kim_model.get_influence_distance() and model.get_influence_distance()} return the original unchanged value despite any setting in model.set_opt_params. So I guess the update of cutoff/influence_distance is somehow incorrect with self.params_transform is not None.

[mjwen]

Hi @dengtq, sorry for the late response.

Your correction is totally OK. I took a closer look, and found that we intended to update the influence distance after parameter changes in the original code (see here); however, there is a bug, and the line actually should be: self.influence_distance = self.init_influence_distance(), like it is here.

Do you mind creating a PR for this?

Regarding your additional observations, I will need more time to delve into it and see what's going on. Will report back.

[dengtq]

@mjwen Thank you for the response. I have tried correcting the lines self.influence_distance = self.init_influence_distance() which works alright. And the problem with transformation still remains, unfortunately.

Sure I will create a PR later. And look forward to your thoughts on the transformation issue.