Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BespokeFit-client #339

Closed
jthorton opened this issue Apr 9, 2024 · 2 comments
Closed

BespokeFit-client #339

jthorton opened this issue Apr 9, 2024 · 2 comments
Assignees

Comments

@jthorton
Copy link
Contributor

jthorton commented Apr 9, 2024

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.

@jthorton jthorton self-assigned this Apr 9, 2024
@j-wags
Copy link
Member

j-wags commented Apr 15, 2024

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.

@jthorton
Copy link
Contributor Author

Done in #351

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants