[Dune-devel] SOCIS 2014: update

[Markus Blatt]

Hi Marco,

thanks for the new blog entry. It is nice to see the progress with
interference from my side.

On Mon, Jun 16, 2014 at 10:06:52AM +0000, Agnese, Marco wrote:
> Dear Markus and Christian,
> the last two weeks I get practice a little with C++11 threads
> reading some books and writing some very stupid code just to get a
> little practice. 
> Moreover I took a look of  Tiny Threads++ just to see the similarities and the difference with the STL.
> I also read the paper about the parallel index set and I wrote a simple code (which follow the examples in the article) to understand how the classes are supposed to work.
> 

That is great and will give you a good background for the project.

> I would like to discuss with you about a schedule. 
> What do you think we need to do now?

I guess we are on the same page concerung the technology we should
use. If that is possible we should try to suffice with the subset of
the thread support provided by TinyThreads++. If we later realize that
some more functionality is needed we can either extend TinyThreads or
even move on to something else.

I know that there are concerns about side-effects about using direct
thread supports and e.g. Intel's TBB. But that is something that will
probably occur when combining projects that use the STL with other
projects that use TBB, too. Therefore there are probably either already
solutions for this or it simply is not a problem. Anyway porting low
level thread support to a high level is way easier than the other way
around.


Concerning the schedule. That is actually your task,

> I am starting now to read the source of the classes to understand
> better the implementation and figure out how to design the thread
> support.  

Great that is definitely the first step. When starting to design, I
would first limit the project to only threads with no MPI at all. Be
aware that we are doing something different compared to Steffen, and
Peter. 

The parallel index sets are not used by dune-grid, but only by
dune-istl. Therefore it must be possible to set up some part of the
problem (read: the grid) globally/by one thread and later on start
another part of the algorithm using threads and so on. For now neglect
dune-grid and concentrate on dune-common/dune-istl.

A good example program might be one that construct some global 1d-grid
and then the threads do a simple finite difference discretization on a
distributed representation with one cell overlap.

As the next step we can try to solve the problem using one of the
parallel iterative methods of istl.

If that all works well, we can start with the hybrid concept.

Does that sound reasonable? Then please think of some timeline for
this. 

Like I said before: Nothing is carved in stone and this is only a
rough idea. It is your task to do the hard detailed (concept work). If
there any obstacles or better ways we need to bend the above plan.

Regards,

Markus

-- 
Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20140619/160d23aa/attachment.sig>