You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suggested that the signature for the function for legacy atom typing frameworks as well as NN atom typing / parametrization should be the same, i.e. graph -> graph.
Nonetheless, this would mean that we'd have to carry the molecule (RDKit, OpenEye, or OpenForceField) object with the homogeneous graph. This wouldn't be very efficient.
If we have the function for legacy typing to have the signature molecule object -> graph, we need to think more about the bookkeeping efforts to make sure that the indices won't be messed up after batching, training, and debatching.
The text was updated successfully, but these errors were encountered:
Related to discussions we have here #9
I suggested that the signature for the function for legacy atom typing frameworks as well as NN atom typing / parametrization should be the same, i.e. graph -> graph.
Nonetheless, this would mean that we'd have to carry the molecule (RDKit, OpenEye, or OpenForceField) object with the homogeneous graph. This wouldn't be very efficient.
If we have the function for legacy typing to have the signature molecule object -> graph, we need to think more about the bookkeeping efforts to make sure that the indices won't be messed up after batching, training, and debatching.
The text was updated successfully, but these errors were encountered: