Re: [Moose-g3-devel] parallel MOOSE

[Upinder S. B. <bh...@nc...>]

Hi, Greg,
   That is very interesting, and I can see there will be lots of
subtleties for our ongoing implementation. For a first pass, then, I
will go ahead and have one-to-one mapping, but with the idea that later
we may do something more sophisticated. I can see that this strengthens
your point about the postmasters not being visible entities, because
the semantics will possibly change. But see below.

Greg Hood said:
> I'm not sure exactly how you are thinking of the postmasters, but I fee=
l
> very strongly that there should not be postmaster objects of the sort
> that are present in PGENESIS.  In PGENESIS, the postmaster is an
> object that is no different than any other object in the model.  That i=
s,
> it is visible to users as part of the element tree, and "showmsg" shows
> connections as going to or coming from the postmaster.  However, it
> fundamentally *is* different than other model constructs, and has no pl=
ace
> at the model level.  It is something that should be completely invisibl=
e
> to users, both in specifying models, and in examining them.  In other
> words,
> users should see internode connections as going from A to B, not as goi=
ng
> from A to a postmaster, and then from another postmaster to B.
>
> The postmaster concept may, however, be valid at the simulator level,
> and implementing it as a C++ object within MOOSE (but not as a MOOSE
> object
> itself) could be a legitimate realization of this concept.

I agree that the messaging should appear to go right to the target object=
.
In fact I think we are in good shape to have a completely transparent way
of spreading objects around, so that at first order the user never sees
which node they are on. That includes having messages appear to go right
to their target.

Nevertheless, I think that some form of visible postmaster is necessary.
My concern here is that I don't want to have hidden plumbing in MOOSE.
There was a lot of that in GENESIS, and it ended up being accessed throug=
h
a whole lot of special purpose calls. I would much rather have visible
'plumbing' objects that most people do not need to worry about, which do
provide a consistent interface to those who do care about such things. Fo=
r
example, where would you go to ask the system how many nodes the model wa=
s
running on, or if you want to explicitly shift objects around? For
instance, MOOSE already has the rather complex plumbing of the scheduler
completely visible.

Having said this, I really don't know what is to happen to the postmaster=
s
should we shift to the actual MPI communication to a two-hop process as
you described. Obvious possibility is to use a variant of the postmaster
class, with the design requirement that the first-order user viewpont
remains that of a transparent, singly rooted object tree with ordinary
messaging between objects. Anyway, it is still some way off.

Cheers,
   Upi