Terminal size under OpenMPI

[mrzv]

Background information

What version of Open MPI are you using? (e.g., v3.0.5, v4.0.2, git branch name and hash, etc.)

v4.0.4

Describe how Open MPI was installed (e.g., from a source/distribution tarball, from a git clone, from an operating system distribution package, etc.)

Homebrew (same result for packages from the ArchLinux distribution)

---

Details of the problem

When querying the size of the terminal under OpenMPI, the result comes back as 0 columns, which messes up code that relies on this number for formatting.

Here's an example in Python.

# terminal-size.py
import shutil
print(shutil.get_terminal_size())

Running without OpenMPI, reports 191 columns.

python3 terminal-size.py            
os.terminal_size(columns=191, lines=75)

Running with OpenMPI, reports 0 columns.

mpirun -n 1 python3 terminal-size.py
os.terminal_size(columns=0, lines=0)

FWIW, under MPICH the terminal size is reported as 80 columns.

[jsquyres]

This is probably not surprising. I don't remember exactly how Open MPI's pty code works (I'd have to rummage around / refresh my memory), but MPI processes are generally remote from mpirun, and therefore it's probably reasonable to report 0 rows/columns. I.e., even though we transport the stdout/stderr of each MPI process back to mpirun, it's not actually running in the same terminal session an mpirun.

In your example, I'm presuming that you're running locally, so an argument may be able to be made that if the MPI process has a simple ancestral relationship to mpirun, then we should report the same rows/columns as mpirun. I'm not offhand sure why we don't do that, but it could well be that we took a unification / simplification step and decided that all MPI processes report 0 rows/columns...?

Is this creating a problem? I.e., is there a use case where an MPI process should report >0 rows/columns?

[mrzv]

I'm not sure I agree with the reasoning why 0 columns is a reasonable thing to report. Remote or not it's normal for MPI applications to output something. Even when redirecting the output to a pipe, you normally get some reasonable default number of columns (usually 80). With the above example:

python3 terminal-size.py | cat
os.terminal_size(columns=80, lines=24)

The reason of course is that if you want to display any non-trivial formatting, it's useful to know the screen width. (That's how I've run into this problem.) MPICH reports the same 80x24, BTW.

Passing the true terminal size to all MPI processes would be a great solution (after all by default you are sending all of their output to the terminal), but the simple result that one gets for a pipe (80x24) would also work. I'm not hoping for anything fancy; it's just that 0 columns makes very little sense and breaks some code.

[jsquyres]

@mrzv I talked to @bwbarrett + others about this today; our consensus is that Open MPI has always been this way, so this technically isn't a regression.

Meaning: this sounds like a feature request.

We talked through what it would take to implement this. On the surface, it's pretty simple: a straightforward ioctl() to get the size of the mpirun terminal session, and another ioctl() to set it in each of the launched MPI processes.

...but unfortunately it's not that simple. The size -- if it's available -- would then need to be communicated to all back-end possibilities (direct launch, mpirun launch, etc.) and set in all the back-ends where it is available and usable. Once that's done, then the next natural thing to ask for is to watch for the resize terminal session event, which then would need to do the whole thing again on the fly / in the middle of the MPI job. All that, taken together, seems like a fairly large job.

We could take the approach of hard-coding the size to 80x24 (and not do any communication), but given that Open MPI hasn't set a size for ~15 years, someone would likely complain that we're setting it to a fixed value that is unrelated to mpirun's terminal session. Given the history, the half-baked / "trivial" approach isn't likely to be sufficient -- it probably needs to be done correctly.

Also, this would likely need to be in PRRTE (you may not be aware: Open MPI's master / head of development has 100% revamped its back-end run-time support such that it is wholly and completely different than it is on v4.0.x / v4.1.x. For the upcoming v5.0.x series, PRRTE is the back-end run-time for Open MPI, and the change would likely need to be done over there -- not directly in Open MPI).

All this boils down to: it sound like this is a fair feature request. It's unfortunately likely to be a big job. I'm not sure where in the priority list this feature will be slotted; probably not near the top (just being honest here...).

[mrzv]

Thanks for the update.