Re: [Moose-g3-devel] Revision 27 checked in

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

Dear all,
   As Niraj's checkin message stated, we have started a complete
reimplementation based on lessons from the MOOSE2006 API. There are many
more details in the subversion log in the intro section, and there is als=
o
a documentation directory that has a couple of sections handwritten, and
becomes richly populated when you run doxygen.

Hugo has brought up most of the key additional points:

>
> 1. I don't see any of the biophysics / parallel / solver stuff
> anymore.  So, or this is work in progress, or this has been accidently
forgotten/removed.  It would be nice to know what the status is, and to
have at least two or three examples of how to work with the new
basecode.

Yes, these are works in progress. I thought we should go for the 'release
early, release often' policy. You will see a lot more activity on the
subversion tree as a result.


Immediate development sequence:
- flesh out the parser interfaces. Currently compiles with Python/SWIG,
but I'll use the same function hooks to talk to the old GENESIS parser.
- Bring over the scheduling structure from MOOSE06
- Set up biophysics
- Set up hsolver (Niraj is working on this)

Examples of how to work with the new base code will be in the form of the
biophysics modules. In principle I could do those right away, but without
the scheduling and parser stuff that would not be terribly functional. Bu=
t
you can look at the element/Neutral files to get a preview.

>
> 2. I would like to learn more about the relationships between Finfo and
Ftype and related.  e.g. why do we need Ftype and Ftype2.  Is there any
more documentation available about the general relationships ?

Finfos hold information about fields. They are not typed, and rely on the
templated Ftype classes to handle type specific functions and information=
.
This separation helps because it keeps templating to a minimum and
encourages most operations to remain generic.

>
> 3. a question about the tests: wouldn't it be better to separate the
code from the tests completely from the code from the core ?  I have
seen to many cases where bugs in test code were interfering with bugs in
the tested code, such that everything seemed to work properly although
it was not.  For instance, the SimpleElement seems to be intended for
tests only, but is shipped in the basecode directory.

The tests are all wrapped in #ifdef DO_UNIT_TESTS. I like to have them
close to the classes they test because then it is easier to understand
what they are doing.

I have assertions everywhere, and those are intentional. Again, asserts
can be flagged out of the system when we are sure it works well.

SimpleElement is actually used for everything. It is currently the only
instantiable version of Element.


>
> 4. If I am correct, Element specific data is supposed to be hidden with
the ->data() method.  I am not sure if I like this idea or not, it has
both advantages and disadvantages: to make sure that I
> understand: my guess is that it avoids cases of multiple inheritance,
and it decouples privately owned data, so might require more
> implementation work and cause run-time overhead.  I think of this as a
major design decision, and it is different from the previous release of
Moose.  Can you explain the rationale for this, can you explain why the
previous release of Moose did this differently and what the
> problems were ?

Well, you've pointed out both the pros and the cons. It avoids multiple
inheritance and decouples private data at the cost of an extra
indirection. Another big reason for doing this is that it makes it easier
to set up variants of the Element class. As it turns out, it has helped a
lot in keeping the implementation of the wrapper code separate from the
user object code. For example, message and field handling becomes much
more modular in this system than it was earlier.


>
> 5. Is it correct to say that this version of Moose adds array based
fields and that this was not present in the previous release ?  Is this
a preparation for array based messaging ?
>

Array fields are now cleaner, but I did have a clunkier version
previously. I'm not sure what you mean by array-based messaging. We can
now send and receive messages from individual array entries. We were
always able to send and receive entire arrays.

Cheers,
  Upi