ESP (wavefunction?) planning | Store grids or wavefunctions? BP – Wavefunction should be interpretable by any program, but that’s not true in practice. Would need psi4 to reliably make grid. Not sure how wavefunction is stored with basis set.
BP – Saved wavefns should be correctly interpretable by the SAME version of psi4, but not DIFFERENT version. Size comparison of wafefunctions vs. grids? HJ will try the wavefunction calculation on a small number of molecules and see if the output is usable. What is stored if we request the wavefunction to be saved? Just the final geometry, or wavefunctions for all? Do we need this to be calculated as a second step (for example, to keep from storing wavefunctions for opt trajectory?)
SB – Keeping wavefunctions as a second step should help us update if we need to redo them for any reason. BP – Most of the time, you’ll compute wavefunctions at geometry that was optimized in that basis set. So if the basis set changed, then we’d need to redo the entire geometry optimization. SB – Splitting into two steps would let us calculate wavefunctions WITHOUT doing a geometry optimizatio BP – I can look into doing this as a procedure.
HJ – I tried passing numpy array to psi4 to get ESP values and E field. I could get ESP from a numpy array, but not E field. (It is possible to get E field from psi4 CLI , just not Python)
import psi4.core as p4c
myepc = p4c.ESPPropCalc(wfn)
psi4_matrix = p4c.Matrix.from_array(grids)
esps_psi4 = numpy.array(myepc.compute_esp_over_grid_in_memory(psi4_matrix))SB – Above example uses the term “in_memory”. Is the E field functionality not here because it can’t be performed in memory? JH – Header file shows a “compute_field_in_memory” method, but it doesn’t take in a grid. SB – The non “in-memory” variants of these methods don’t take in a grid, but there may be another way to set this.
“Most functions currently require a file "grid.dat" to be present.” – line 339 of file above SB – Variant of methods that perform in-memory vs. from file are only about 2 lines different, so we could open a PR with the desired change.
SB – Grid gen stuff could go into openff-recharge, once we decide on the scheme that we want here.
|
User questions | JW – MM energies of all final molecules? What about connectivity rearrangements? JH – In the future, SMILES will be carried through to the final molecule. JH – Previous jobs only have SMILES stored on the entry level. BP – Could create a new dataset, submitting all the same molecules, with with SMILES string. JH will try submitting the MM energy jobs as a new dataset, and see if QCA will accept it, or prevent the submission due to the molecules being identical.
Wavefunctions of all final molecules? (pending Hyesu’s report on whether they’re usable+everything we need) basis_set_exchange conda package?
Was originally on molssi conda channel. JW will ask MT to open a basis_set_exchange PR for conda forge. BP will accept maintainership of c-f package.
|
