[Moose-g3-devel] questions about MOOSE

[Greg H. <gh...@ps...>]

Upi,
I have spent the past week looking through the MOOSE code and documentation,
and am trying to get a good understanding of it before deciding on the
best way of parallelizing it.  I don't feel that I have yet reached that
point, but in the meantime I have several concerns that I'd like to discuss
with you:

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.

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
from 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 and received.  This means that the sender will need its own
thread, unless all computation is to be blocked while waiting for MPI
(a very bad thing).  If the sender is in its own thread, then much locking
will be needed to ensure that other threads on that node do not stomp
on each other.

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.

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 of
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" should
replace "element", and "class" should replace "object".

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?

6. How would variable-timestep methods be handled?
The clock-based scheduling appears very similar to that found in GENESIS 2.
How do you envision an element that is capable of variable-timestep
updating being handled?

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