MPI: check presence of a runner command only with run and test apps

[perazz]

Address #935.

• if MPI can’t find a runner, do not stop if we are not running either fpm run or test
• with MPI, --runner option overrides mpiexec instead of appending it (backward compatibility)
• add --runner-args option so additional arguments can be passed to the runner command instead of to the app (e.g., "-np 123"

@Carltoffel all CI tests work as there is always a runner command there.
Can I ask you to test this in the case you detailed in #935?

Thank you!

[Carltoffel]

Thanks for fixing this issue!
While it works, it stills prints very verbose warnings:

 + which mpiexec
/usr/bin/which: no mpiexec in (...)
+ which mpirun
/usr/bin/which: no mpirun in (...)
 + which mpiexec.exe
/usr/bin/which: no mpiexec.exe in (...)
 + which mpirun.exe
/usr/bin/which: no mpirun.exe in (...)

Where (...) is my whole path environment.

After printing these warnings, it starts compiling.

[perazz]

Good catch thank you @Carltoffel, the unnecessary messages should be gone now (only output on --verbose)

[Carltoffel]

Another thing and sorry for the confusion I may have caused: I just updated the issue because fpm test doesn't work by simply providing a runner via --runner. Maybe it is possible to add another check, if a runner was provided and only if not search for mpiexec and mpirun?

[henilp105]

Thanks @perazz , looks good to me.

[Carltoffel]

Good catch thank you @Carltoffel, the unnecessary messages should be gone now (only output on --verbose)

Much better!
Now it produces this output:

 + which mpiexec
 + which mpirun
 + which mpiexec.exe
 + which mpirun.exe

[perazz]

The current logic is to pass only additional arguments with the runner flag, like:

./fpm run --runner=" -np 4"

queue systems have rather convoluted syntax and there is no straightforward way to support them via fpm run unfortunately.

[Carltoffel]

queue systems have rather convoluted syntax and there is no straightforward way to support them via fpm run unfortunately.

I previously did it like this:

fpm run --runner "sbatch juwels.sh"

juwels.sh:

#!/usr/bin/ksh
#SBATCH --time=00:01:00
#SBATCH --nodes=1
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=1

time srun $1

And it worked fine.

Edit: $1 is the executable name provided by fpm.

[Carltoffel]

The current logic is to pass only additional arguments with the runner flag, like:

Is it like that only when using MPI? In this case I would suggest using another option-name as it is inconsistent with how it worked before or without MPI.

[perazz]

I need to check the code again and get back to you.
The reason it is this way is that there was a CLI issue in the passing of -np N or -np * via fpm's

  -- ARGS    Arguments to pass to executables.

[Carltoffel]

Just an idea, what do you think about a new fpm subcommand: fpm mpirun?

[minhqdao]

These lines before the change look pretty good to me. What speaks against them? We return early if there's an error and therefore do not need to care about the value of this%has_run_command.

[perazz]

These were changed to account for your request @minhqdao. If you think the previous version was better, please revert, thank you.

[minhqdao]

No, the question was what speaks against the lines 1008-1010 (before this PR)?

[perazz]

Confirm my previous answer

[perazz]

Just an idea, what do you think about a new fpm subcommand: fpm mpirun?

@Carltoffel I checked and can confirm that there is currently no way to pass flags other than via --runner "my_runner -f1 -g2 -h3"
I am not sure if there would be consensus on adding another (different) runner command, but maybe we can split the two of them? Something like:

fpm run --runner="my_script.sh" --runner-flags=" -np 2 -N 10"

In this way, --runner would override the default MPI runner instead of cating it, which makes more sense

[Carltoffel]

fpm run --runner="my_script.sh" --runner-flags=" -np 2 -N 10"

I really like this idea!

But then we should check if the argument of --runner is an executable without any flags.

[perazz]

Thanks @Carltoffel, I think that would be implicitly taken care of:

The rule would be,

• --runner defines a running command, overriding any default ones (sh, cmd.exe, or mpiexec if MPI). It may or may not include additional arguments
• --runner-args specify additional arguments (better args than flags) that will be appended to the runner command anyways.

I think this would be a pretty general approach?

[Carltoffel]

It may or may not include additional arguments

I'm not sure, if we should forbid passing arguments to the runner. At least we should print a warning, IMHO.

Edit: Besides of this, I totally agree with you.

[perazz]

If we look at the fpm help, it says:

  --runner CMD   Provides a command to prefix program execution paths.
  -- ARGS    Arguments to pass to executables.

I've tried to pass the ARGS in every possible way but they don't seem to work when a runner is present. Probably a feature that was initially foreseen but never fully implemented. So I think at the end of the day, it's probably not too bad if we give it a name and call it

  --runner-flags ARGS    Arguments to pass to executables.

[perazz]

@Carltoffel like discussed, I've introduced the option to pass arguments to the runner (instead of to the app) via --runner-args.

So for example, one can now pass arguments to the runner e.g. mpiexec via:

./fpm run --runner-args=" -np 2"

(note heading space, needed by M_CLI2).
In presence of MPI, the runner command is also not appended anymore but mpiexec is only used if there is no user-provided runner (which restores backward compatibility).

@urbanjost I've tried to add a CI test but I keep failing writing "namelist language". If it is not too much of an issue, can I ask you to take a look at this PR? Thank you in advance.

[perazz]

I believe the comments and concerns so far were addressed; so, if there are no further ones, I think the content of this PR is ready to merge soon

[urbanjost]

missed this one. Not quite sure what the exact issue is; but there was an earlier version prototype proposed where you could control the position in the command of the filenames by using a special string like %% or {} or $FILE. If the special string (lets say it is %% is found is is replaced much like commands like xargs or find do. xargs is particular seems a good model, as the -I switch lets you specify a string to replace, and that triggers the replacement operation. Would that be a useful solution? There are several string replacement procedures available.

[perazz]

no problem @urbanjost, the request is to be able to pass arguments to the runner command rather than the project executable. MPI is the example that triggered this need, as one has:

[/path/to/mpiexec] [-np 123 -N 456] [/path/to/project/.exe] [ARGS]

Now, to pass [-np 123 -N 456] one should have used --runner, but in this case, the path to the mpiexec would get lost (this is something the MPI metapackage searches for). So now --runner-flags allows to append flags to the runner executable. This is also backward compatible, as the former option is still valid

[perazz]

If there are no more comments, I think this can be merged soon.