search

ulissigroup / vasp-interactive

GNU Lesser General Public License v2.1
53 stars 11 forks source link

Questions about Socket Interface Usage #50

Closed yinkaaiwu closed 8 months ago

yinkaaiwu commented 10 months ago

I currently have a GPU server and a CPU server, which are located in different places. Since the GPU server has fewer cpu cores, I intend to deploy a VASP computation service on the CPU server. This way, when experimenting with the combination of FINETUNA and VaspInteractive, I can perform large-scale parallel relaxation jobs. However, communication between the two servers needs to occur over the internet, and I'm unsure if the socket calculator provided by VaspInteractive can meet my requirements.

I have reviewed the examples ex16_client.py and ex16_socketio.py , but neither of them demonstrates how to pass VASP calculation parameters. Additionally, the server defines an Atoms object before starting the service, which is confusing to me. Can't the client send coordinate, force, and energy data to the server?

It's also possible that I haven't fully understood the purpose of setting up the socket calculator.

Looking forward to your response.

P.S.: A fantastic tool indeed.

alchem0x2A commented 10 months ago

Hi @yinkaai sorry for the late reply. That's a good question indeed. This is the actual intended use case of the socket io mode for VaspInteractive, though I haven't tested it extensively. Let me answer by what works now and what don't (won't) 1) the parameter passing is tricky. When running in separated server / client mode, the vasp parameters will need to be (at least) provided on the client side. Check https://github.com/ulissigroup/vasp-interactive/blob/main/vasp_interactive/socketio.py for a cli wraper that can start the client with a dumped pkl file containing the parameter sets.

2) The socket-io protocol is inherited from i-PI (https://ipi-code.org), and the philosophy is that the main logic (optimization, sampling, ML fine-tuning, etc) is performed on the server, while the clients are just workers to receive the workload. But of course you can let the "client" send instructions to the server, with some additional scripts.

3) On the server-client communication, you may need some sort of workflow tool to manage the data passing on top of VaspInteractive. Fireworks (https://materialsproject.github.io/fireworks/) may be one solution but I'm sure you'll find more suitable ones. Or, you can simply write some scripts using rsync to transfer the .vpi_params.pkl file as mentioned in 1). Or maybe simply just open a ssh connection on the GPU server to start a client on CPU server with --params option, whichever you like

yinkaaiwu commented 8 months ago

Hi @yinkaai sorry for the late reply. That's a good question indeed. This is the actual intended use case of the socket io mode for VaspInteractive, though I haven't tested it extensively. Let me answer by what works now and what don't (won't)

  1. the parameter passing is tricky. When running in separated server / client mode, the vasp parameters will need to be (at least) provided on the client side. Check https://github.com/ulissigroup/vasp-interactive/blob/main/vasp_interactive/socketio.py for a cli wraper that can start the client with a dumped pkl file containing the parameter sets.
  2. The socket-io protocol is inherited from i-PI (https://ipi-code.org), and the philosophy is that the main logic (optimization, sampling, ML fine-tuning, etc) is performed on the server, while the clients are just workers to receive the workload. But of course you can let the "client" send instructions to the server, with some additional scripts.
  3. On the server-client communication, you may need some sort of workflow tool to manage the data passing on top of VaspInteractive. Fireworks (https://materialsproject.github.io/fireworks/) may be one solution but I'm sure you'll find more suitable ones. Or, you can simply write some scripts using rsync to transfer the .vpi_params.pkl file as mentioned in 1). Or maybe simply just open a ssh connection on the GPU server to start a client on CPU server with --params option, whichever you like

thank you for your advices!