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?
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
