0

Hello dear Communauts,

I'm am creating a terminal animated status report for a parallel software I'm developing. I'm using NCurses. I'm having an issue related to the restoring of the standard behavior of the terminal. After running my software the terminal keeps having just 24 lines, no matter if I call endwin() or I don't. Here the simplified code:

int size=10;
initscr();
refresh();
while(KeepAlive){
      int j=1;
      mvprintw(j,0,/*Blah blah header*/));
      for(int i=0;i<size;i++){
          j++;  
          mvprintw(j,0,/*Some blah blah*/);
       }
       refresh();
       usleep(1000000);
}
endwin();

KeepAlive is a control variable changed by another thread (so the while is not infinite loop, but controlled loop). After running this software my terminal has only 24 lines, echo works, but there's plenty of blank space.

Thanks a lot for your help, have fun

EDIT:

I would like to share with you some information I found while attempting to solve my issue:

  1. curses (ncurses) is perfectly working under openMP, then you can imagine some threads doing your math calculations and one thread (only one, be aware) giving out some runtime infos.
  2. curse (ncurses) is NOT compatible with MPI. Well, the right stating would be is "not completely" compatible with MPI. MPI is really sophisticated about stdin/stdout/stderr, since all outputs from all MPI-processes could be redirected to a display (which could be specified). Using any advanced terminal output overriding library will take to a fault of the code, or unexpected behaviors.

That's supported by the MPI faq:

Maybe. But probably not.

Open MPI provides fairly sophisticated stdin / stdout / stderr forwarding. >However, it does not work well with curses, ncurses, readline, or other >sophisticated I/O packages that generally require direct control of the terminal.

Every application and I/O library is different -- you should try to see if yours >is supported. But chances are that it won't work.

Sorry. :-(

found here (MPI reference).

What I've discovered is that even if you appoint only one MPI-process to manage all the curses output (just that process calls initscr() at the beginning and endwin() at the end of his part of code) there is no way to force curses to use the full terminal (only default UNIX 24x80 will be available). Once MPI has been finalized your whole terminal will keep working in 24x80 mode until reset is called.

Thanks to all communauts that helped me,

Have fun

gf

Community
  • 1
  • 1
jetstream
  • 106
  • 1
  • 10

2 Answers2

1

One possible solution is to completely decouple your text GUI from the rest of the MPI code and make both parts talk to each other via the client/server mechanism of MPI-2. That means:

  1. Run the GUI as singleton MPI program, i.e. one that calls MPI_Init{_thread} but is not started via mpiexec. It then should open a listening port by calling MPI_Open_port. The call returns a string port name that has to be supplied to the compute part of the application. The GUI part should then start listening for connections by calling the blocking MPI_Comm_accept.

  2. The compute part is started as usual via mpiexec. It should connect to the GUI by calling MPI_Comm_connect given the port name from (1).

  3. The combination of MPI_Comm_accept in the GUI and MPI_Comm_connect in the compute part establishes an intercommunicator that can be used for sending messages between the two parts. The compute part could e.g. send periodic status messages to the GUI. If necessary, the intercommunicator could be further "flattened" to an intracommunicator.

  4. Once the computation is finished, the communication part should disconnect by calling MPI_Comm_disconnect.

  5. The GUI should call MPI_Close_port and finish its own execution.

In that scenario, the GUI part could be a text mode curses application started locally or remotely via SSH, an X11 GUI application, or whatever else there.

Hristo Iliev
  • 72,659
  • 12
  • 135
  • 186
  • Thanks for your advice. I can't figure out what do you mean for part of the first point of your answer. Should I use a pair of terminals to call in one of them the computational part and in the second the monitor? – jetstream Mar 22 '15 at 21:52
  • NVM found here another answer of yours http://stackoverflow.com/questions/15007164/can-mpi-publish-name-be-used-for-two-separately-started-applications – jetstream Mar 22 '15 at 21:58
0

It should work. The comment about "parallel" suggests multithreading, which can mean that your output is not flushed as one might expect.

Likely this is the same issue (Ncurses limited output size) for which more information was given. Neither question provides enough detail to offer more than generic advice.

Community
  • 1
  • 1
Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
  • Thanks for your answers. Later I'll try to produce a sort of dummy software to reproduce the behavior. Anyway, even if I'm using openmp, just one of the available threads commits the output. What kind of additional information do you need? Thanks in advance – jetstream Mar 21 '15 at 12:14
  • I recall a recent discussion with someone where it appeared that due to the way the threading was done, `endwin` was not actually called (at least, it did nothing). A complete code-sample which lets others test it really helps. – Thomas Dickey Mar 21 '15 at 12:18
  • I've found out that the issue is throw by ncurses+MPI interation. ncurses works like a charm simply with OpenMP. I'm investigating on a solution. – jetstream Mar 21 '15 at 19:21
  • @jetstream, OpenMP is a threading technology that works inside the process. It does not perform any I/O redirection and therefore does not mess up ncurses. – Hristo Iliev Mar 22 '15 at 00:25