dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Dec 07, 2006 at 01:12:41AM +0100, Garth N. Wells wrote:
> Anders Logg wrote:
> > On Wed, Dec 06, 2006 at 11:39:44PM +0100, Garth N. Wells wrote:
> >> Anders Logg wrote:
> >>> Do you mean "DofMap associated with mesh and finite element"?
> >>>
> >> Yep.
> >>
> >>> I'm ok with that. We could have a DiscreteFunction with two members:
> >>>
> >>>     Vector
> >>>     DofMap
> >>>
> >> That would work.
> > 
> > ok. This will also have consequences for the file format for
> > input/output of Functions.
> >
> 
> Yes. Slightly related, I'd like to add output for MeshFuction<T> if the 
> T is suitable for output.

This is already supported. (Fixed by Ola last week.)

It has been implemented for T = int, real, bool, but we need to add
support for uint as well.

> > Anyway, the Function class needs some work. We've also talked about
> > smart pointers before so there are a few things to figure out:
> > 
> >     - Incorporate DofMap
> >     - Reference counting/smart pointers
> >     - FiniteElement --> ufc::finite_element
> > 
> >>> I haven't looked closely on the DofMap yet, but does it allow working
> >>> only through the on-the-fly computed dofmap of the FFC generated code?
> >>>
> >> This is exactly what it does at the moment.
> >>
> >> DofMap::dofmap(int dof_map[], const Cell& cell, const uint e = 0) const;
> >>
> >> just call the FFC nodemap() function. The DofMap can have two finite 
> >> elements attached to it (for rows and columns), so e indicates which map 
> >> you want.
> > 
> > Sounds good. But I'd like to avoid talking about rows and columns if
> > possible.
> >
> 
> You don't see this in the code - just a hint in the comments that one 
> element should correspond to the test element and the other to the trial 
> element.

ok. I'm thinking of assembly of global tensors of arbitrary rank. We
have some code duplication now since we need to deal with scalars,
vectors and matrices. The UFC will be the same for any rank tensor,
but it's probably more difficult to make the global data structures
independent. (PETSc only has vectors and matrices for example.)

> >>> Or is it necessary to compute all the data?
> >>>
> >> You only need to compute something if you want to know the total number 
> >> of degrees of freedom or you want to the sparsity pattern.
> >>
> >> I'll add shortly the possibility to run the Cuthill-McKee over the map 
> >> and reorder it. This will be an option.
> > 
> > What is Cuthill-McKee?
> >
> 
> It's the most common reordering algorithm. It will probably improve the 
> sparse matrix performance.

ok.

> >>> I'd like something where one can decide whether to actually build all
> >>> the data or just use what FFC generates (to save memory in storing the
> >>> function).
> >> Agree.My intention is that the data is built only if a renumbering is 
> >> requested.
> >>
> >> What is worthwhile is computing the sparsity pattern. For 10^6 
> >> triangles, it only cost 2.5s to do this on my laptop and it can save a 
> >> lot of memory.
> > 
> > Very nice.
> > 
> > It looks like estimateNonZeros() is no longer needed in FEM?
> >
> 
> I think that I already removed it. FEM::size(uint e) should also be 
> removed and DofMap::size(uint e = 0) should be used instead. This 
> requires some work though because FEM::size() is used elsewhere in the code.

Yes, but the transition should be ok since those places are all
related to the Function class in some way.

/Anders


> Garth
> 
> > /Anders
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> > 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev