Anders Logg wrote:
> 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).
>
I thought that this would be a simple solution, but there a "new Vector"
in DiscreteFunction which requires that the vector type be known. If
this is somehow re-written, the above approach could be used.
Garth
> /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
