Re: [Moose-g3-devel] questions about MOOSE

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

Hi, Greg,
  Thanks for the feedback. I hope you have had a chance to look at
revision 5 or later from the SVN repository. Here are my responses.

Greg Hood said:
>
> 1. pointers versus handles
> The typical way that an element is referenced within MOOSE is by a
pointer
> (Element *).  What this effectively means is that objects are frozen to
a particular memory location on a particular node, and it will be next to
> impossible to later move them to different nodes.  Is that limitation
acceptable to you?  The alternative would be to use some sort of handle
that is a persistent identifier of that object, regardless of its
location.

As you say, pointer reference is not a good idea, and is meant to be
encapsulated in messages. Note that the object hierarchy (/root/foo/bar)
is maintained through 'child' messages. These messages are the correct
handle to use. I currently permit pointer reference for atomic operations
like tree searches. The idea is that these operations should be local and
should be instantaneous, ie, no other operation should mess with the tree
structure while they occur.
Messages as handles are quite general and can stretch across nodes, much
like the older GENESIS messages.
As it turns out, the solver design which I'm working on also is purely
message based. In principle one could have solved objects on multiple
nodes. Why anyone would want to do this is another matter!


>
> 2. ReturnFinfo
> I'm not exactly sure what sort of thing ReturnFinfo is supposed to be
used
> for. (I couldn't find an instance of its use in the examples.)  My
interpretation of its function is that it immediately returns a value fro=
m
the receiving element to the sending element.  This will cause trouble if
the sending element is on a different node than the receiving element,
because the sender will have to be delayed while MPI messages are sent an=
d
received.  This means that the sender will need its own thread, unless al=
l
computation is to be blocked while waiting for MPI (a very bad thing).  I=
f
the sender is in its own thread, then much
locking
> will be needed to ensure that other threads on that node do not stomp o=
n
each other.
>
Yes, ReturnFinfo is meant to return a value immediately. Example is table
lookup in channel calculations. Multiple differnt channel instances will
want to look up the same alpha/beta table, and will each have their own
values to find.
Yes, it is bad to run this across nodes. The system should object if this
is attempted.
As you can see from the example above, the purpose of this message is to
avoid the use of pointers but still permit shared resources. If you want
to do this across nodes you can duplicate the target. I haven't yet froze=
n
the semantics, but as presently used, ReturnFinfo is readonly.


> 3. mpp preprocessor
> If someone has an X.mh file and runs it through the mpp preprocessor,
then
> they get X.h, XWrapper.h, and XWrapper.cpp files out.  Under what
circumstances
> does one need to hand modify these files?  I would argue that this
should
> never be happen.  Here's a thought: why not have a single X.moose file
that
> contains all information about the MOOSE classes, and let mpp translate
this
> into read-only X.h, X.cpp, XWrapper.h, and XWrapper.cpp files, possibly
locating these in a C++/ subdirectory so they will not clutter up the
developer's working directory.  The MOOSE developer should not have to
directly deal with these .h and .cpp files anyway.  By judicious use of
#line directives in the .h and .cpp files, any errors in the C++
compilations can be referred back to the original X.moose file.

This is almost exactly what I would like and am working toward. At this
point the preprocessor is incomplete, partly because the base code still
has some way to go. But you'll find that revision 5 is _much_ improved an=
d
can do about 95% of the job of generating X.h, XWrapper.h and XWrapper.cp=
p
files without user intervention. More like 100% in the case of
straightforward classes, which are what most users would need.
One difference is that the X.cpp file is intentionally not supported. The
idea is that this is stuff that the user will want to code independently
of the wrapper stuff. For example, if there were serious calculations
needed inside an object, we don't want to squash it all into the X.mh fil=
e
(think of the X.mh file as a super 'header' file). These would then go
into X.cpp. The X.cpp functions need not know about MOOSE at all.
BTW, I am not keen to use #lines. Phenomenally ugly!

>
> 4. semantics of "messages" needs to be clearer
> I have read various documents under DOCS/ that describe messages, but
I'm
> still fuzzy on exactly how they work, and why all the different types o=
f
messages are needed.  It would be good to have some concrete examples to
refer to, in order to make this clearer.  For example, I'm not clear how
the clocks for the source and destination elements affect transmission of
> information across messages (if at all).  Also, I'd still like to push
to change the name of a "message" to something else (connection? link?),
since "message" in CS terminology has a connotation of a one-shot
delivery
> of information.  Similarly, to conform to general usage, "object" shoul=
d
replace "element", and "class" should replace "object".
>
Two points here: Message functionality and the name message.
Message functionality: Think of them as remote function calls with
persistent traversal information. Remote in this context means to another
object, wherever it lives. I have a list somewhere in the documentation o=
f
all the message categories, 7 at last count. Yes, this is a big number an=
d
could probably be tightened. I want to first get all the base code stuff
done (solvers and parallelization in particular still remain) before
assessing how the different varieties of message behave and seeing if the=
y
can be condensed without loss of efficiency.
The name 'message': this is a hangover from GENESIS. I actually use the
term connection for the underlying traversal framework, and 'message' for
the overall construct. I don't see how we can easily rename it without
breaking backward compatibility assumptions, but I am quite open to
suggestions. As I recall we have had this discussion before,
inconclusively.


> 5. Why are synapses treated separately in the Moose header files? Since
synapses are just messages, why should they be given a separate section
within a Moose class definition?
This is just because they are a special kind of message. Synapses
associate extra information with each message (weight, delay, etc) which
is allocated on a per-message basis and is not part of the argument list.

>
> 6. How would variable-timestep methods be handled?
> The clock-based scheduling appears very similar to that found in GENESI=
S
Solvers handle variable-timestep stuff. When a solver is set up, it
inserts itself into the scheduling object hierarchy, and replaces the
usual clocktick object that calls the equivalent of the PROCESS action.
Then it is up to the solver to decide how to interface with the schedulin=
g
calls.
Individual variable-timestep solvers are no problem in this context. They
get the universal clock ticks from the scheduler and make sure that they
are within the appropriate time window. I've already done something like
this in GENESIS 2 for the Gillespie solver.
Multiple variable-timestep solvers may need to negotiate if they depend o=
n
mutual data.

2.
> How do you envision an element that is capable of variable-timestep
updating being handled?
See above.

>
> I don't know if you prefer to discuss these issues in e-mail, or want t=
o
try to do a teleconference (possibly with VNC???) with those of us intere=
sted
> in this level of detail.  Let me know what works best for you.

I think these are very good questions to bring up, and they should be on
record at the MOOSE site to help developers as they dig in.

Thanks,
  Upi