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

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

Dear Greg et al,
  Thanks for raising some very important and interesting points. I have
not yet thought much about parallel model loading, because I don't have
much idea about how much of a bottleneck it might be. Before I dive into
the details, this is my earlier line of thought; please comment on it.

1. Threads: I had considered restricting multithreading to solvers, on a
per-node basis, for some of the reasons Greg has outlined.
2. RelativeFind etc: I had considered caching info on the postmaster to
speed up the process of finding remote objects, and grouping requests for
remote-node element info.
3. Parallel model building: I thought that almost all cases where this
would be critical would be through special calls like createmap,
region-connect, and perhaps copy. Most of these can be rather cleanly don=
e
in parallel with minimal internode communication. However, a global
checkpoint would be needed to ensure synchrony between these calls.

I should also add that the divide between setup time and runtime is
probably not so clean and we will definitely need to figure out efficient
ways of handling this. For example, in signalling simulations I have
already had issues where new organelles are budding  off and being
destroyed at runtime.

To consider Greg's points:
> The greatest concern I have is with the many places in the basecode tha=
t
make an implicit assumption that elements are locally resident in the
nodes's memory, and that only one thread will be actively
> modifying them. (...)
> Some form of locking will thus be needed (probably on a per-Element bas=
is).
Couldn't we put a lock at an appropriate place in an element tree, but
permit other element trees to be accessed safely ?

>The most troublesome situations will be when
> modifications are being made to the element tree, such as when new
>elements are being created or old ones destroyed.
Can we have a lock set whenever 'dangerous' commands are being executed?
Most commands at runtime are relatively safe.

> One solution may be to standardize at the .mh level.... This approach
> might make sense if nearly all the
> visualization and other add-on code would be at the .mh level or higher=
,
> but not if those things require major changes to the existing basecode.

I'm not sure what you have in mind here. To me it looks like all the
locking stuff should be done at the basecode level, so the user does not
need to know about it even if they are developing new objects using .mh
files. Could you expand on it?

--  Upi