[mpich-discuss] Spawns without mpirun

[Martín Morales]

Hi Hui.

About the "special (or interactive) mode" would be great!
In relation to your frontend-backend suggestion that you propose, having a
"proxy" process in that way might be an important code restructuring which
we just can't do at the moment. Thank you very much anyway.
Best regards,

Martín



<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Sep 25, 2020 at 12:58 PM Zhou, Hui <zhouh at anl.gov> wrote:

> Hi Martin,
>
>
>
> I see. Yeah, MPICH (or the project manager hydra) will not work with
> interactive programs nicely. It might be a potential interest to add a
> special mode that project manager do not try to take over the input/output.
> For now, is it possible for your ncurse application to spawn a separate
> process (via `mpirun -n 1 …`) that can be used to spawn additional
> processes? I am thinking that your interactive part can be programmed as
> purely a frontend to your actual MPI processes.
>
>
>
> --
> Hui Zhou
>
>
>
>
>
> *From: *Martín Morales <martineduardomorales at gmail.com>
> *Date: *Friday, September 25, 2020 at 9:09 AM
> *To: *"discuss at mpich.org" <discuss at mpich.org>, "Zhou, Hui" <zhouh at anl.gov>
> *Subject: *Re: [mpich-discuss] Spawns without mpirun
>
>
>
> Hi again Hui. My apologies, I overlooked your singleton analogie with
> mpirun (*mpirun -n 1 ./prog...* ). Yes, in fact, it was one our first
> tries. These program we use is interactive and requires the *ncurses *library
> for that. I read some time ago a known problem with Open MPI implementation
> and *ncurses*. Unfortunately with MPICH we've experienced the same issue.
>
> Best regards,
>
>
>
> Martín
>
>
>
> On Wed, Sep 23, 2020 at 9:28 PM Martín Morales <
> martineduardomorales at gmail.com> wrote:
>
> Hi Hui, thank you for your reply. Ok I'll create that issue then. We've a
> quite large PVM application. It has processes handling in a singleton
> fashion that it allows powerful functionality. We needed to port the PVM
> code to MPI in this exact way to preserve that functionality. We've done
> this already but with the Open MPI implementation. However we've found some
> inconsistencies in it and that's why I'm querying about this feature in
> MPICH.
>
> Best regards
>
>
>
> Martín
>
>
>
>
>
> On Wed, Sep 23, 2020 at 8:31 PM Zhou, Hui <zhouh at anl.gov> wrote:
>
> It’s possible but not prioritized. Could you open an issue on github? When
> we have enough users requesting the feature (or when we have persistent
> user requesting it), the priority may be escalated. 😊 Meanwhile, could
> you describe the scenario that you have to use singleton init (vs. `mpirun
> -n 1 prog …`)?
>
>
>
> --
> Hui Zhou
>
>
>
>
>
> *From: *Martín Morales via discuss <discuss at mpich.org>
> *Reply-To: *"discuss at mpich.org" <discuss at mpich.org>
> *Date: *Wednesday, September 23, 2020 at 3:49 PM
> *To: *"discuss at mpich.org" <discuss at mpich.org>
> *Cc: *Martín Morales <martineduardomorales at gmail.com>
> *Subject: *[mpich-discuss] Spawns without mpirun
>
>
>
> Hi all!
>
> I asked here some time ago about dynamically spawn processes  from a
> singleton but the answer was that unfortunately, there was a problem with
> that and just It was not possible. I wonder now if this functionality is
> available.
>
> Best regards
>
>
>
> Martín
>
>
>
>
>
>
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
> Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20200925/d2970ca4/attachment.html>