Closed mattwthompson closed 5 months ago
This is a bit more of a tricky one as it goes against the current philosophy that all attribute names in the spec can mapped into code, so while length_bondorder1
is valid python (/ C / javascript...), length_bondorder1.5
won't be and so cannot be directly accessed.
@j-wags will probably have more thoughts on this though.
Thanks for all the feedback - I think this is heading in the right direction but it'll take a bit more care to get it into a state that is ready for another review. In particular, this idea won't immediately work so cleanly for torsions - mostly because the current kN_bondorderM
approach squeezes the periodicity and bond order together in a way that could be confusing. Maybe kN_M
is fine, I'll don't want to decide now.
In particular, this idea won't immediately work so cleanly for torsions - mostly because the current kN_bondorderM approach squeezes the periodicity and bond order together in a way that could be confusing. Maybe kN_M is fine, I'll don't want to decide now.
I don't understand this. What is kN_bondorderM
and kN_M
?
For interpolated (periodic) torsions, there are different force constants for each periodicity and interpolation point. Like in the
<ProperTorsions ... >
<Proper ... k1_bondorder1="1.00*kilocalories_per_mole" k1_bondorder2="1.80*kilocalories_per_mole" idivf1="1.0"/>
...
It's a matter of picking the best variable name for encoding this. Above you suggested k_bondorder2
-> k2
for bonds, which doesn't work 1:1 as in torsions (k1_bondorder2
-> k1_2
would be confusing and somewhat ambiguous). k1_bondorder
is probably better.
This doesn't seem to be so important after all, but it's all laid out here if somebody wants to do it
Resolves #8