Open faridf opened 2 years ago
faridf
commented
2 years ago Basically, I want to understand why this step exists in a dimer run and how is it not undoing what the dimer algorithm has done by bringing back the system to the local minimum?
Thanks again!
eljost
commented
2 years ago Hi faridf,
please post a link to the example or a code/input-snippet, so I know what you are referring to.
All the best Johannes
faridf
commented
2 years ago This is the Link to the script: https://github.com/eljost/pysisyphus/blob/afe18d9c5f29a41e33fe3022d35e652e597b5a33/tests/test_dimer/test_dimer.py
On two occasions on lines 46,47 and 90,91 we have: opt = PreconLBFGS(geom, **opt_kwargs) opt.run()
eljost
commented
2 years ago These are two separate tests. Each dimer-run consists of repeated application of dimer rotation into the most negative curvature mode and a subsequent translation. The translation steps for the dimer are calculated by PLBFGS in these tests. Please have a look at the respective papers: 10.1063/1.480097, 10.1063/1.2815812 for the dimer method and 10.1038/s41598-018-32105-x regarding the preconditioning.
faridf
commented
2 years ago Thanks very much for this clarification. The usage of PLBFGS sounds very interesting. I wanted to know your opinion on the dimer algorithm and how it should interface with engines such as VASP for instance.
What I have in my mind is a naive way and that is running static runs with VASP (for instance) and introducing energy and positions to the Dimer algorithm and introducing the new step produced by Dimer back to the VASP engine.
I wanted to know your opinion on this and whether running static runs is a good idea.
Thanks!
eljost
commented
2 years ago I have no experience with solid-state codes on my on but what you want to achieve is certainly possible. I don't want to drive you away from pysisyphus, but it appears as if VASP already supports the dimer method?!
Regarding interfacing: pysisyphus supports the IPI-Protocol to exchange energies and gradients, as well as positions (see here). Similarly, the central Geometry object in pysisyphus can be converted to an ASE Atoms object
and pysisyphus calculators can be wrapped using the FakeASE calculator.
Maybe this can help you interfacing pysisyphus and VAPS (maybe via ASE).
Personally, I can't give you any support regarding VASP. Also, pysisyphus currently does not handle periodic boundary conditions and/or cell vectors.
All the best Johannes
eljost
commented
2 years ago If the capabilities of the ASE Vasp calculator are sufficient for you, you could just write a wrapper that exposes ASEs VASP calculator with a suitable interface to pysisyphus.
I could provide you a suitable template next week, if you're interested.
faridf
commented
2 years ago Thanks very much! I am thinking of using pysisyphus. Prior to now, I had my own code and I am testing it currently. I am trying to mix Dimer with Gaussian process regression. I was not aware of pysisyphus and that it included the Dimer algorithm as well. The capabilities of the ASE Vasp calculator would clear things up for me actually and would help me use pysisyphus.
But right now I am getting massive forces from Dimer and it doesn't really approach saddle point. It moves up on the potential but I think it is out of the convex somehow that it doesn't approach saddle point. I should mention I used the algorithm for dimer from this paper: https://aip.scitation.org/doi/10.1063/1.4798344
eljost
commented
2 years ago Without knowing the paper you mentioned. Do you try to recreate a example from the paper? Did you already test your implementation for the most simplest case, e.g., HCN isomerization or even better, on a 2d potential? Pysisyphus implements several 2d-potentials for fast evaluation of the energy and its derivatives.
faridf
commented
2 years ago Well, I have tried toy models like Muller-Brown before and it was successful. I'll look into the 2d-potentials of Pysisyphus. Thanks for the suggestions!
faridf
commented
2 years ago I wanted to know if perhaps I wanted to code something that would handle periodic boundary conditions with Pysisyphus, how would I start to modify things in this code?
eljost
commented
2 years ago I fear this would not be an easy task. Regardless of the employed coordinate system, e.g., for an optimization, all calculators (ORCA, Gaussian etc.) are called with plain Cartesian coordinates, which are assumed to be a vector with 3N entries (N == number of atoms).
Codes using PBCs also require the cell vectors as input, don't they? This would require the cell vectors to be also part of the "underyling" Cartesian coordinates, from which coordinates in other coordinate systems could be derived, e.g., primitive internals and/or DLCs.
Currently, there are probably many place in the code, where the Cartesian coordinates are expected to be 3N and not 3N + 9 (including the cell vectors). So I guess just appending the 3 cell vectors to the Cartesian coordinate vector could lead to unexpected problems/behavior.
Overall, I guess support for PBCs could be implemented, but not in the near future by myself, because I basically never use PBCs and have no personal usecase for them.
If you are willing to try to implement them I could try to give you some support. My first guess would be to add them as additional argument to the Geometry base-class and to pass the cell vectors to the calculator at the appropriate places:
and
and
This would then support calculation of energy/forces/Hessian using PBC.
The you would probably have to implement a new coordinate System or extend CartesianCoords. CartesianCoords conforms to the CoordSys-Protocol as specified in CoordSys. The correct implementation of a subclass can be verified using mypy.
The correct types etc. in Coords.CoordSys are currently only implemented in the dev branch.
Hello
I am not reporting any issue and I only wanted to why a dimer run requires optimization before and after the dimer run. In your examples, I see you have used PreconLBFGS as your optimizer for dimer run. I was curious as to why this is necessary to have.
Thanks!