Garth N. Wells wrote:
>
> Ola Skavhaug wrote:
>> Garth N. Wells skrev den 25/07-2007 følgende:
>>> Martin Sandve Alnæs wrote:
>>>> 2007/7/24, Garth N. Wells <[EMAIL PROTECTED]>:
>>>>> Martin Sandve Alnæs wrote:
>>>>>> 2007/7/24, Garth N. Wells <[EMAIL PROTECTED]>:
>>>>>>> Martin Sandve Alnæs wrote:
>>>>>>>> As I understand it, "Matrix" is just a convenience class for users who
>>>>>>>> don't care about the underlying format. It should never be used at the
>>>>>>>> library level (because it ties the library to one format for each
>>>>>>>> compilation of the library), and can be ignored by anybody who
>>>>>>>> actually cares about which library they'll use.
>>>>>>> I would say that it is more than just a convenience class - it's more
>>>>>>> like the default linear algebra backend. Part of the idea is to tie the
>>>>>>> library to one format in order to guarantee that various objects are
>>>>>>> compatible with each other.
>>>>>> This doesn't sound like what Anders told me. Its the very idea of
>>>>>> "tying" the library compile-time to a single backend that I don't
>>>>>> like. As long as the rest of the library depends on GenericMatrix and
>>>>>> not Matrix, I'm happy. In that case, Matrix is a nice user-side
>>>>>> feature to keep user code portable.
>>>>>>
>>>>>>
>>>>>>> A possibility would be to make objects like
>>>>>>> Function templated, at the cost of increased complexity.
>>>>>> I don't see where Function enters this?
>>>>>>
>>>>> A Function requires a vector to store the dofs. This is currently a
>>>>> Vector, so it would have to be possible to specify the type of vector.
>>>>> With the current design, it's not enough to just make the underlying
>>>>> pointer a GenericVector.
>>>>>
>>>>> Garth
>>>> Using more than one linear algebra backend with this design must
>>>> require separately compiled libraries for each backend then? This is
>>>> not ok for Python apps at all, and will make the PyCC merge impossible
>>>> in my opinion.
>>>>
>>> What's the problem that makes things impossible?
>> Well, one problem is that PyCC uses its own linear algebra system (or
>> collection of linear algebra systems). It would me much simpler if we can
>> just
>> inherit a set of base classes, and then use our code transparently with
>> DOLFIN. The alternative would be to compile DOLFIN with the specific linear
>> algebra systems of PyCC. I fear that this would require much work.
>>
>> I suggest that we invest some time to resolve how this should be done in a
>> general and flexible manner. It might require some work, but we are ready to
>> do this. The benefits of the merge will for sure pay this effort off.
>>
>
> Yes, I agree and I'm looking forward to the merge. Would the below
> template approach work for you? Function will require some changes for
> parallel assembly and solve (which is being worked on), so now is a good
> time to work out what we need to make the merge smooth.
>
> Garth
I think there is a very simple solution. We just change the constructor
of Function to
Function(Mesh& mesh, GenericVector& x, const Form& form, uint i = 1)
and the vector member of DiscreteFunction to
GenericVector* x;
Then if one needs a Function that uses a particular linear algebra
backend, then just create the Function from a PETScVector, uBlasVector
or EpetraVector. Otherwise, create it from a Vector (tied to the default
backend) or let the Function itself decide (in which case it will be a
Vector).
/Anders
>> Ola
>>
>>
>>> I agree that it would be more elegant to allow the use of different
>>> back-ends, and it should require only a minor redesign. The least
>>> intrusive solution would be to make Function a templated class,
>>>
>>> template< class T > Function
>>> {
>>> public:
>>>
>>> . . .
>>> T& vec();
>>>
>>> private:
>>>
>>> T* vector;
>>> }
>>>
>>> Garth
>>>
>>>> I guess this requirement stems from that Function needs to construct
>>>> objects of GenericVector subclasses? We could use a factory design
>>>> then. The factory pattern is usually a good solution when "virtual
>>>> constructors" are needed, like here. But this probably leads to
>>>> changes many places, so I'm not trying to come up with a solution
>>>> right now.
>>>>
>>>> Martin
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> 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
