| 3:44:27 AM PDT - Thu, Mar 27th 2014 |
|
Alright, I've done some more digging.
Looking through the source, it looks like:
-> The python scripting allows calls to routines in NWChem with simple wrapping.
-> A call to set the gradients is not available (only the documented calls in the user manual are available, basically all the task directives).
-> To set the gradients, you can call rtdb_put? In the file gradients/grad_inp.F it looks like it calls this function a few times. I'm not sure what rtdb stands for, but I assume "Real time database"? Fortran is not my strong point, I'm more comfortable with Python and C.
So, my idea of how to proceed would be:
-> Wrap the function rtdb_put in the Python scripting module. Or the higher-level function "gradients_input" from grad_inp.F could be wrapped as well. But wrapping the database input function seems like it could be useful for other things as well.
-> Create an optimization routine (in the nwchem input file) that only runs through one cycle of relaxation, and calculates the new gradients. A user-generated python script (in the input file) would then calculate the false gradients (by adding our linear-slant term) based on the new positions of the two atoms being pulled on, and add that onto the returned gradients.
-> Repeat until convergence. It seems that custom convergence criteria would have to be coded into the python script - that is put in the nwchem input file.
The other approach would be to add a way to specify a false-gradient function in the NWChem input file, to be added onto the gradient at the end of each optimization cycle. This may be easier - but seems to offer less flexibility when it comes to future custom routines. And then we would have to code multiple ways to input gradients based on user-need: mine is a constant force between two atoms in the geometry, but others could have other needs.
If there are any devs who could give me an idea of how hard this would be to implement, or the feasibility, that would be great. I would also like to know how the nwchem dev-team feels about pull requests from the community. I think a more general interface to the NWChem internals via a high-level python interface could be beneficial for many projects.
|