...
I also plotted a CDF for these, but there wasn’t much to gain from it. The old force field increases slightly faster than the new, as expected.
Charge Models
Tom Potter reported an issue when running the Sage 2.1.0 refit with AmberTools/RDKit instead of OpenEye where the initial objective function value was “1.67619e+04, compared to 1.09618e+04 for the original Sage 2.1 run.” Initially he was using versions of the toolkit affected by the charge caching bug, but even after updating to the new versions, he “found it gave essentially the same results.” This was somewhat in line with what I had observed with my own Sage 2.1.0 reproduction runs before the charge caching fix, with some example objective function values from a single run below:
| Code Block |
|---|
Total 1.61326e+04
Total 1.54131e+04 ( -7.195e+02 )
Total 1.53246e+04 ( -8.856e+01 )
Total 1.51405e+04 ( -1.841e+02 )
Total 1.46718e+04 ( -4.687e+02 )
Total 1.46120e+04 ( -5.973e+01 )
Total 1.43540e+04 ( -2.581e+02 )
Total 1.42554e+04 ( -9.860e+01 )
Total 1.41504e+04 ( -1.049e+02 )
Total 1.41092e+04 ( -4.120e+01 )
Total 1.42160e+04 ( +1.067e+02 ) |
These are somewhat similar to what Tom observed.
Still, we wanted to see what difference the charge model itself would cause (OpenEye AM1-BCC ELF10 vs AmberTools/RDKit AM1-BCC), so I started another Sage 2.1.0 refit starting from the targets and input file from the Sage 2.1.0 repo but with my OpenEye license unexported. I only gave it 6 days of walltime, so it died after iteration 4, but I think that gives us most of the data we wanted to see:
| Code Block |
|---|
| Iter | Total Obj. |
|------+-------------|
| 0 | 1.14056e+04 |
| 1 | 1.00536e+04 |
| 2 | 9.25233e+03 |
| 3 | 9.17668e+03 |
| 4 | 8.85820e+03 | |
Overall these seem a bit closer to the original Sage 2.1.0 values, both initially and as they converge, than what Tom was observing or what I saw with the charge caching issue.
In case we want to follow up on this in the future, here are my input (and main output) files for the run:
| View file | ||
|---|---|---|
|
/dfs9/dmobley-lab/bwestbr1/refits/ambertools/new. The targets therein are the same as those used by Tom, which in turn are the same as those used for Sage 2.1.0 minus these targets:| Code Block |
|---|
opt-geo-batch-175/2003384-18.pdb
opt-geo-batch-175/2003385-19.pdb
opt-geo-batch-178/2003481-3.pdb
opt-geo-batch-178/2003482-4.pdb
opt-geo-batch-178/2003484-7.pdb
opt-geo-batch-178/2003486-10.pdb
opt-geo-batch-9/18433500-29.pdb
torsion-18886452/
torsion-2703523/
torsion-2703524/
torsion-2703525/
torsion-2703526/
torsion-2703603/
torsion-2703604/
torsion-2703606/ |
which cause conformer generation errors in RDKit when running ForceBalance. I also found that I had to remove opt-geo-batch-51/18438154-19 for the same reason, and torsion-18537145 also failed 6 times in the initial iteration before finally succeeding, but it didn’t cause any further problems.