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
Is your feature request related to a problem? Please describe.
It would be useful to be able to run torsion drives using TorsionDrive via QCEngine directly rather than needing to spin-up a snowflake instance. Use cases include:
running one-off / small batches of torsion drives that don't require the full QCF machinery, including avoiding the need to spin-up postgre background services which can occasionally fail to spawn in certain compute environments (e.g. on a locked down HPC cluster)
debugging failed torsion drives - it would be good to be able to validate that a torsion drive can run outside of the QCF machinery to isolate whether a TD is problematic or if there is an issue with the QCF machinery itself (i.e. the dreaded INCOMPLETE status)
Describe the solution you'd like
It would be useful to have a new TorsionDriveProcedure (referring to TorsionDrive the program, not torsion drive the process) that can be called via compute_procedure(input_data, procedure="torsiondrive"), and that under the hood calls out to the main optimisation procedures (e.g. geometric) via nested calls to compute_procedure.
I have a proof of concept implementation working in PR #305 if people have any thoughts on this. (cc @dotsdl@bennybp@loriab)
Describe alternatives you've considered
Add this functionality to a separate package, however QCEngine would seem to be a better home for it.
Additional context
Implementing this feature would likely benefit from the discussion in MolSSI/QCElemental#264 as one could more easily define an optimisation specification for a torsion drive input without needing to a priori provide a molecule instance.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
It would be useful to be able to run torsion drives using TorsionDrive via QCEngine directly rather than needing to spin-up a snowflake instance. Use cases include:
running one-off / small batches of torsion drives that don't require the full QCF machinery, including avoiding the need to spin-up postgre background services which can occasionally fail to spawn in certain compute environments (e.g. on a locked down HPC cluster)
debugging failed torsion drives - it would be good to be able to validate that a torsion drive can run outside of the QCF machinery to isolate whether a TD is problematic or if there is an issue with the QCF machinery itself (i.e. the dreaded INCOMPLETE status)
Describe the solution you'd like
It would be useful to have a new
TorsionDriveProcedure
(referring toTorsionDrive
the program, not torsion drive the process) that can be called viacompute_procedure(input_data, procedure="torsiondrive")
, and that under the hood calls out to the main optimisation procedures (e.g. geometric) via nested calls tocompute_procedure
.I have a proof of concept implementation working in PR #305 if people have any thoughts on this. (cc @dotsdl @bennybp @loriab)
Describe alternatives you've considered
Add this functionality to a separate package, however QCEngine would seem to be a better home for it.
Additional context
Implementing this feature would likely benefit from the discussion in MolSSI/QCElemental#264 as one could more easily define an optimisation specification for a torsion drive input without needing to a priori provide a molecule instance.
The text was updated successfully, but these errors were encountered: