Anders Logg wrote:
> On Sun, Nov 02, 2008 at 03:52:17PM +0000, Garth N. Wells wrote:
>>
>> Joachim B Haga wrote:
>>> "Martin Sandve Alnæs" <[EMAIL PROTECTED]> writes:
>>>
>>>> 2008/11/2 Joachim B Haga <[EMAIL PROTECTED]>:
>>>>>>> On Saturday 01 November 2008 17:10:09 Martin Sandve Alnæs wrote:
>>>>>>>> 2008/11/1 Garth N. Wells <[EMAIL PROTECTED]>:
>>>>>>>>> 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.
>>>>> If you can get away with making these variables static, thread-local
>>>>> variables (storage class __thread) is simpler.
>>>> But static... That sounds very limiting.
>>> Perhaps. In that case, I'd suggest just letting each thread have its own
>>> instance of any mutable classes, if that's possible.
>>>
>> Isn't Martin's suggestion that the necessary data be passed to the eval
>> function much simpler?
>>
>> Garth
>
> Yes, the implementation would be much simpler, but it would be
> inconvenient if all user-defined functions must be defined with all the
> arguments:
>
> void eval(double* values, double* x, const Cell& cell, uint facet, ...)
>
> We could introduce a new class Data (or similar) that contains x and
> possibly a lot of other stuff:
>
> void eval(double* values, const Data& data)
> {
> values[0] = sin(data.x[0]);
> }
>
> The data variable can have member functions cell(), facet() etc.
>
I would prefer this. Even as it stands now, it wasn't obvious to me how
the cell and facet are updated. It requires some effort to trace this
through the code.
Garth
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
