clawpack / clawutil

General utility programs
BSD 3-Clause "New" or "Revised" License
10 stars 31 forks source link

Add optional variable RUNEXE to Makefile.common #154

Closed rjleveque closed 10 months ago

rjleveque commented 1 year ago

Normally the Makefile for an application specifies EXE as a filename, such as xclaw, that serves both as the target for 'make .exe' and also as the executable command for running the code.

In some case, e.g. if using MPI, the command that needs to be run is different, e.g. mpiexec with various arguments. In this case you can now set e.g. RUNEXE = "/path/to/mpiexec -n 4 /path/to/xclaw_mpi" in the application Makefile. Full absolute paths should be used since this command is typically executed from a different directory specified by OUTDIR. Also it should be a string in quotes because it must be passed to the python code runclaw.py as a single argument.

If RUNEXE is not specified in the Makefile (or as an environment variable) then RUNEXE is set to EXE by default. So old Makefiles should still work fine.

mandli commented 1 year ago

Could this be used to reference an executable then at a different path?

rjleveque commented 1 year ago

@mandli: If it is just an executable like xclaw that is in a different directory, then it's simplest to just set EXE = /full/path/to/xclaw in the Makefile, since you presumably also want 'make .exe' to create that file, not an xclaw in the run directory. I often do this when I want to use the same executable xgeoclaw for many different tsunami simulations in different directories and there's no need to replicate the executable.

The new RUNEXE is for the case when the command to run the executable is different from the name of the file containing the executable.

rjleveque commented 1 year ago

Something else to consider before merging this....

This works ok for the MPI use case used as an example above, but I realized that this probably isn't as robust as it should be. The command specified by RUNEXE is passed in to clawutil.runclaw.runclaw, but is then it modified further there, based on other options (e.g. if nohup or nice is passed in) in a way that won't work for an arbitrary command.

Moreover the modified command eventually gets split up into tokens that are passed to subprocess.check_call to actually execute, and again this may not be very robust.

I'm marking this as a draft for now.

rjleveque commented 10 months ago

There's a better way to do this, so I'm closing this and will open a new PR