[mpich-discuss] Allowing client systems to come and go

[Darius Buntinas]

Dave H,

Hmm, I understood your question differently than Dave G did.  Just to 
clarify, is this the kind of situation you're asking about?

     User on a windows machine supplies data then "clicks run"
     ...magic happens...
     MPI job starts on linux cluster
     MPI job completes on linux cluster with output data
     ...more magic...
     User on windows machine gets output data

Or does the user need to interact with the job during the run?

The former is how MPI is used most often.  The "magic" needed would be 
if you want a "clickable" interface, as opposed to having the user start 
the jobs from a command line.

-d



On 01/25/2010 02:26 PM, Hiatt, Dave M wrote:
> Thanks.  Yes, I know it's difficult.  As with many things in life, the politics of the situation prevent me right now from introducing any more messaging solutions into the mix, so I'm stuck with needing to transfer message data and having just fought big time and winning getting MPI in, I can't open a second front for the UI.  That will be part of my summer offensive I guess.
>
> -----Original Message-----
> From: mpich-discuss-bounces at mcs.anl.gov
> [mailto:mpich-discuss-bounces at mcs.anl.gov]On Behalf Of Dave Goodell
> Sent: Monday, January 25, 2010 2:12 PM
> To: mpich-discuss at mcs.anl.gov
> Subject: Re: [mpich-discuss] Allowing client systems to come and go
>
>
> The MPI Standard provides mechanisms to support this usage (see
> MPI-2.2 chapter 10, "Process Creation and Management").  However, in
> practice you're just asking for pain if you want to use MPI like this
> in a long-running fashion.  MPICH2 (and basically all other MPI
> implementations AFAICT) doesn't support dynamic processes in a robust
> enough way to be able to use on a long-running basis.
>
> On top of the dynamic process support, you'd be mixing in heterogenous
> system support (Windows/Linux processes talking to each other), which
> has its own set of issues.
>
> You're welcome to give it a shot, but I definitely wouldn't call it a
> practical approach under current conditions.
>
> -Dave
>
> On Jan 25, 2010, at 1:59 PM, Hiatt, Dave M wrote:
>
>> It is advantageous for us to use MPICH2 to handle the setup and
>> status traffic between the client computers that allow users to
>> enter data and initiate runs and the gateway system to our cluster.
>> The client systems are Windows 7, the gateway box is Centos 5.4, as
>> is the cluster.  I thought I saw some references to how to allow
>> systems to attach to and then drop out of communicators on an ad hoc
>> basis.  The Linux gateway system will be up 24/7 and can host all
>> the communicators, or participate in them depending on the best
>> approach.  So can someone refresh my memory, did I see a discussion
>> on this topic within the last 6 months.
>>
>> To start with there will be about 25 client systems, so, is this a
>> practical approach?  Thanks
>>
>> dave
>>
>>
>> "Consequences, Schmonsequences, as long as I'm rich". - Daffy Duck
>> Dave Hiatt
>> Market Risk Systems
>> CitiMortgage, Inc.
>> 1000 Technology Dr.
>> Third Floor East, M.S. 55
>> O'Fallon, MO 63368-2240
>>
>> Phone:  636-261-1408
>> Mobile: 314-452-9165
>> FAX:    636-261-1312
>> Email:     Dave.M.Hiatt at citigroup.com
>>
>>
>>
>>
>> _______________________________________________
>> mpich-discuss mailing list
>> mpich-discuss at mcs.anl.gov
>> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>
> _______________________________________________
> mpich-discuss mailing list
> mpich-discuss at mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
> _______________________________________________
> mpich-discuss mailing list
> mpich-discuss at mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss