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
Description
At ASAP we are looking into deploying a bespokefit server on AWS and workers on a HPC and I think a few small changes are needed to make this work and improve the interface.
I think the executor currently assumes you are on the same machine as the server when submitting tasks as the address of the server is hard-coded to be the localhost this should be exposed as a setting which is respected when launching the server.
I also think it would make sense to split out the server and submission logic to create a client which interacts with the server similar to Alchemiscale or QCFractal. Following this we could then have lightweight conda packages like openff-bespokefit-client which just handle interfacing with the server via the client and don't require all of the fitting dependencies like ForceBalance, geometric, torsiondrive etc.
Are there any other missing parts to making this happen or any features users would like to see in the client? my idea is to expand the capabilities of the client to make it easier to inspect all parts of the workflow.
The text was updated successfully, but these errors were encountered:
I think the executor currently assumes you are on the same machine as the server when submitting tasks as the address of the server is hard-coded to be the localhost this should be exposed as a setting which is respected when launching the server.
I think could be a nice feature. How would this be tested?
I also think it would make sense to split out the server and submission logic to create a client which interacts with the server similar to Alchemiscale or QCFractal. Following this we could then have lightweight conda packages like openff-bespokefit-client which just handle interfacing with the server via the client and don't require all of the fitting dependencies like ForceBalance, geometric, torsiondrive etc.
What would be the plan for testing this? AFAICT the value add here is shaving a minute or two off mamba installs, and the cost is maintaining and testing a second package deployment. So I'm slightly against this.
Description
At ASAP we are looking into deploying a bespokefit server on AWS and workers on a HPC and I think a few small changes are needed to make this work and improve the interface.
I think the executor currently assumes you are on the same machine as the server when submitting tasks as the address of the server is hard-coded to be the localhost this should be exposed as a setting which is respected when launching the server.
I also think it would make sense to split out the server and submission logic to create a client which interacts with the server similar to Alchemiscale or QCFractal. Following this we could then have lightweight conda packages like
openff-bespokefit-client
which just handle interfacing with the server via the client and don't require all of the fitting dependencies like ForceBalance, geometric, torsiondrive etc.Are there any other missing parts to making this happen or any features users would like to see in the client? my idea is to expand the capabilities of the client to make it easier to inspect all parts of the workflow.
The text was updated successfully, but these errors were encountered: