dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Nov 01, 2008 at 07:08:14PM +0100, Johan Hake wrote:
> On Saturday 01 November 2008 17:10:09 Martin Sandve Alnæs wrote:
> > 2008/11/1 Garth N. Wells <gnw20@xxxxxxxxx>:
> > > Martin Sandve Alnæs wrote:
> > >> Are there any plans for multicore support in DOLFIN, that is
> > >> automatic utilization of multiple CPU cores without significant
> > >> user intervention, in the near future? (For example using OpenMP).
> > >
> > > No immediate plans (message passing is the immediate priority), but
> > > obviously this would be very nice to have and we don't want our design to
> > > preclude it.
> >
> > Ok.
> >
> > >> If yes, am I the only one who thinks it would be a good idea
> > >> to consider this in the new Function design?
> > >
> > > You may be the only that knows enough about multi-threaded programming to
> > > be in a position to think properly about it.
> >
> > Ok, but I don't really know that much about it.
> >
> > >> I just want to point this out since I think this issue has been too
> > >> downplayed in the design discussions. And I don't think anyone
> > >> wants yet another redesign of Function within the next months...
> > >>
> > >> The main issue is that iterating over cells in a mesh and calling a
> > >> Function currently involves side effects, modifying its mutable members
> > >> cell and facet. Thus the user would have to construct multiple Function
> > >> objects for a Function to be used in basically any multicore situation.
> > >> Any solution to this must involve sending all kinds of cell data needed
> > >> as arguments to eval. Exactly how this should look is a design
> > >> discussion.
> > >
> > > So if we remove
> > >
> > >  mutable Cell* _cell
> > >  mutable int _facet
> > >
> > > from the private member data of Function, does this resolve the biggest
> > > design issue for running multi-threaded?
> >
> > Yes. Otherwise the threads will overwrite each others current cell all the
> > time.
> 
> Would it be possible to store the present Cell* and facet in two vectors of 
> length #threads. Then we either have to call the cell(), facet() and normal() 
> with the present thread number or if it is possible to implement a static 
> function that returns the present thread number in these functions. If the 
> last option is not possible we need to call the eval function with the 
> present thread number.

This is what I've been planning (but I don't know how to implement it).

If we can get the thread number, it should be simple. User-defined
functions access the cell and facet by the functions cell() and
facet(), so those functions may just pick the data from an array.

-- 
Anders


> > User functions need to be threadsafe too though, but we can't do
> > anything about that.
> 
> Passing the thread number to eval would make it possible to write thread safe 
> functions.
> 
> This is probably a quite common problem which has been solved in many previous 
> applications. 
> 
> 
> Johan
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature