Nested loops #26
Comments
|
I understand what you're saying, but until we're very sure about the workflow, I think it's actually advantageous to have a look at the set after a finished loop before you go back. An alternative would simply be to have a number of sequential loops, where the last one is global with tethering to current values of all parameters. Only need tethering to implement that. Yet another version is to do the sets in parallel, but in a block-diagonal sense, so that the reference lenghts don't see the Hessian data and the force constants don't see the structural data. This would be exactly equivalent to running two optimizations in parallel, one step only each from the same starting point, and merging before restarting the cycle. Of the three options, I think I'd prefer the tethering solution; the others can risk oscillation. An alternative to tethering COULD be to run a final, global optimization with ONLY SVD, now that it's working as it should. We can do that today. Anyone want to give it a try? I might. |
* ESP RMS for a charge scheme This is code that was borrowed from Anna Tomberg and modified to fit the Q2MM organization. Simply put I added two new commands "-mgESP" and "-mjESP" which take two files filename.mae,filename.chk and filename.mae,filename.in, respectively. I have not finished coding the "-mjESP" section, as I do not know of anyone who really wants the Jaguar end of this. For a loop, use the following syntax: RDAT -r some_ref_text_file.txt CDAT -mgESP filename.mae,filename.chk This will take filename.mae and determine the partial charges from the force field and then write them into a gaussian com file (filename.ESP.q2mm.com) which will calculate the RMS when compared to the ESP found in filename.chk. I added a few things into constants.py that should be expanded. 1) Gaussian methods with just a few common functions that we have used in the lab 2) CHELPG radii that are used. This is important for metals that do not have built in radii. A GaussCom class was added to filetypes, and the GaussLog class was modified to read in the RMS from the resulting filename.ESP.q2mm.log file. I have not yet checked to see how compatible this code is with more data types. I imagine there is probably some sorting errors that happen. * Bug: Early Return in GaussLog class After adding in the ESP_fit commit previously I included an early return argument in the read_out function of the GaussLog class. This had been remedied so it shouldn't be a problem anymore. * Will add comments later. * Minor bug fixes There were bugs where atom objects would not have consistent properties, such as an atom type corresponding to Ru but still contained old information from the merging process such as the atomic number.
* ESP RMS for a charge scheme This is code that was borrowed from Anna Tomberg and modified to fit the Q2MM organization. Simply put I added two new commands "-mgESP" and "-mjESP" which take two files filename.mae,filename.chk and filename.mae,filename.in, respectively. I have not finished coding the "-mjESP" section, as I do not know of anyone who really wants the Jaguar end of this. For a loop, use the following syntax: RDAT -r some_ref_text_file.txt CDAT -mgESP filename.mae,filename.chk This will take filename.mae and determine the partial charges from the force field and then write them into a gaussian com file (filename.ESP.q2mm.com) which will calculate the RMS when compared to the ESP found in filename.chk. I added a few things into constants.py that should be expanded. 1) Gaussian methods with just a few common functions that we have used in the lab 2) CHELPG radii that are used. This is important for metals that do not have built in radii. A GaussCom class was added to filetypes, and the GaussLog class was modified to read in the RMS from the resulting filename.ESP.q2mm.log file. I have not yet checked to see how compatible this code is with more data types. I imagine there is probably some sorting errors that happen. * Bug: Early Return in GaussLog class After adding in the ESP_fit commit previously I included an early return argument in the read_out function of the GaussLog class. This had been remedied so it shouldn't be a problem anymore. * Will add comments later. * Minor bug fixes There were bugs where atom objects would not have consistent properties, such as an atom type corresponding to Ru but still contained old information from the merging process such as the atomic number.
It would be nice to do nested loop cycles. For example, optimizing the bond force constants to set of data, then the reference lengths to another set of data, and cycling back and forth between the two.
The text was updated successfully, but these errors were encountered: