dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 01, 2010 at 11:26:42AM +0000, Garth N. Wells wrote:
>
>
> On 30/11/10 23:15, Anders Logg wrote:
> >On Tue, Nov 30, 2010 at 11:12:18PM +0000, Garth N. Wells wrote:
> >>
> >>
> >>On 30/11/10 23:09, Anders Logg wrote:
> >>>On Tue, Nov 30, 2010 at 10:48:09PM +0000, Garth N. Wells wrote:
> >>>>
> >>>>
> >>>>On 30/11/10 22:37, Johan Hake wrote:
> >>>>>On Tuesday November 30 2010 14:30:18 Garth N. Wells wrote:
> >>>>>>On 30/11/10 22:25, Anders Logg wrote:
> >>>>>>>On Tue, Nov 30, 2010 at 10:20:52PM +0000, Garth N. Wells wrote:
> >>>>>>>>We have a thread-safe problem in GenericFunction with the member object
> >>>>>>>>
> >>>>>>>>    mutable Data data;
> >>>>>>>>
> >>>>>>>>Any ideas on how to get rid of it? We really should pass data
> >>>>>>>>through the function interfaces, but we're constrained in this case
> >>>>>>>>by the UFC interface.
> >>>>>
> >>>>>This is ironical, as Data was introduced so we in the future (now present)
> >>>>>could be thread safe...
> >>>>
> >>>>Really? I remember Martin always warning against such a design
> >>>>because it's not thread-safe.
> >>>>
> >>>>>But I do not think GenericFunction was a ufc::function
> >>>>>at that time.
> >>>>>
> >>>>>Is it time to introduce the notion of thread in the ufc interface?
> >>>>>
> >>>>
> >>>>Not for this purpose. What would be helpful is a way to pass
> >>>>user-defined data through the UFC interface. Perhaps more
> >>>>importantly, we should avoid using 'mutable'. A 'const' object
> >>>>should in principle be thread-safe, but using mutable clouds this.
> >>>
> >>>Another solution (in addition to making the mutable data thread safe)
> >>>would be to extend the UFC interface with a void* optional argument
> >>>that can be passed to evaluate.
> >>>
> >>>Even if we add that, I suspect there will be a performance penalty if
> >>>we need to recreate the Data object each time in
> >>>restrict_as_ufc_function. In addition to convenience, Data is cached
> >>>between calls so it can be reused.
> >>>
> >>
> >>I'm trying the re-creation now. A good compiler might optimise away
> >>the overhead.
> >
> >Let's hope.
> >
>
> It seems that the only thing that we're missing relative to before
> is the local facet index. Everything else can be dealt with. Perhaps
> this could be added to the UFC interface, i.e.,
>
>   ufc::function::evaluate(double* values,
>                           const double* coordinates,
>                           const cell& c)
>
> could become
>
>   ufc::function::evaluate(double* values,
>                           const double* coordinates,
>                           const cell& c,
>                           int local_facet_index)
>
> ?

That sounds good. And -1 would signal that there the facet index is
not available.

--
Anders