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 https://github.com/MolSSI/QCElemental/issues/264 as one could more easily define an optimisation specification for a torsion drive input without needing to a priori provide a molecule instance.
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 toTorsionDrivethe 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 https://github.com/MolSSI/QCElemental/issues/264 as one could more easily define an optimisation specification for a torsion drive input without needing to a priori provide a molecule instance.