Garth N. Wells wrote:
>
>
> 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
This is used to create copies of the vector (when creating a sub
function or in the copy constructor). How about adding a factory
function to GenericVector? (And also to GenericFoo in general.)
virtual GenericVector* create() = 0;
Then we can call this instead of new Vector() in DiscreteFunction.cpp.
/Anders
>> /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
