verdi setup could automatically set up localhost

[ltalirz]

trafficstars

When using verdi setup, why not automatically set up the 'localhost' computer with the 'direct' scheduler?

This saves a few steps for new users getting started with AiiDA.

[ramirezfranciscof]

@ltalirz would it be good enough to have all the defaults for the interactive prompt be the ones that set up localhost?

[ltalirz]

@ramirezfranciscof I'm not quite sure we are talking about the same thing here. To elaborate a bit more:

The idea would be that setting up a profile with verdi quicksetup or verdi setup automatically adds a localhost computer to the AiiDA database (just like it already adds a default user, for example). Both commands currently have no command line options for this and I'm not sure any are needed - they could simply do it.

[ltalirz]

P.S. Perhaps I misunderstood your comment and what you mean is to leave verdi setup/quicksetup untouched and instead change verdi computer setup such that the defaults are the ones that would configure the localhost computer.

That is a possibility as well - I wonder whether there would be any unwanted side effects when setting up other computers (e.g. people forgetting to change the transport plugin to ssh)... but it might be a good idea and a step in the right direction. I'm happy to review a PR that makes the change & play around with it a bit.

[ramirezfranciscof]

Ahh, I see now. Yes, your second interpretation is right, since we were talking about localhost, my mind automatically inserted a computer between that verdi setup. Let me rethink this a bit then.

[mbercx]

I like the idea in principle, but some of the setup (e.g. work_dir) should be specified by the user, no? Also: some users might have a local code they want to run with MPI perhaps?

Another side note is that this potentially can break setup scripts for users.

[ltalirz]

I like the idea in principle, but some of the setup (e.g. work_dir) should be specified by the user, no?

One can come up with a default work directory, e.g. tmp/$USER

Also: some users might have a local code they want to run with MPI perhaps?

This is not defined at the computer level, so I don't see the issue here?

Another side note is that this potentially can break setup scripts for users.

It could indeed. The default computer should therefore probably not be named localhost but some name that is not likely to occur by chance in existing setups.

[mbercx]

This is not defined at the computer level, so I don't see the issue here?

Wouldn't one typically want to specify the mpirun_command in the computer setup? To be fair, I haven't run many local codes in parallel.

As a user myself, I typically do want to specify the working directory of my localhost computer though. Similarly, I'd prefer it to be called localhost. So I'd probably wind up simply deleting the automatically generated localhost computer. 😅

[sphuber]

This was brought up in today's meeting. In my view, this should not be part of verdi setup as that is not its purpose. However, I can see adding a different dedicated command that automates the setup of localhost. Since it can be done using all defaults, it would require no user input. So we could simply add verdi computer setup-localhost (or some other name) and that takes no arguments or options. This way for tutorials or instructions the computer can be setup with a single simple command

[mbercx]

Another alternative would be to have a --setup-localhost option for the verdi setup and verdi quicksetup commands. @ltalirz which of these suggestions do you think is best? If we agree I can take care of the implementation.

[ltalirz]

The short answer is that I agree with Sebastiaan - i.e. use a separate command, don't make it an option of setup/quicksetup.

On a related note: I think there is a use case for wanting to run a code locally from the terminal without having to set up anything - no extra command, no options to specify during setup, nothing. While this goes somewhat against the current philosophy of how AiiDA usually works, it could be addressed by shipping a cli with the aiida-shell plugin e.g. something like aiida-shell pw.x -i pw.in > pw.out, which auto-generates a localhost computer and pw.x code on the fly, if they do not already exist.

[sphuber]

While this goes somewhat against the current philosophy of how AiiDA usually works,

Not sure what philosophy that is that this would go against? As long as the provenance is kept, I don't see a problem. The issue was that it always required some setup overly laborious setup for the user. This is exactly what aiida-shell addresses.

it could be addressed by shipping a cli with the aiida-shell plugin e.g. something like aiida-shell pw.x -i pw.in > pw.out, which auto-generates a localhost computer and pw.x code on the fly, if they do not already exist.

This is a good idea I think. It might just be a bit tricky to properly define the syntax that is allowed after the aiida-shell command. In this case pw.in is an input file, and so it should be treated differently than another argument, but I am not sure that aiida-shell can automatically determine this. For the way it currently works at least, I am therefore not sure that it would work. But I can have a more in depth look to see what can be done.