Subject: [FIAT-dev] entity_ids for DiscontinuousVectorLagrange

From: Anders Logg <[email-masked]>
Date: Wed, 11 May 2005 17:29:28 -0500

Rob, could you update entity_ids for DiscontinuousVectorLagrange to
the new format (same as for VectorLagrange)? Seems like num_reps is 1.

/Anders

---

From: Robert C. Kirby <[email-masked]>
Date: Wed, 11 May 2005 18:26:25 -0500

Doesn't matter -- all the nodes are internal -- did I only do one 
component's worth on the inside?

Rob

Robert C. Kirby
Assistant Professor
Department of Computer Science
The University of Chicago
http://people.cs.uchicago.edu/~kirby
On May 11, 2005, at 5:29 PM, Anders Logg wrote:

> _______________________________________________
> FIAT-dev mailing list
> [email-masked]
> http://www.fenics.org/cgi-bin/mailman/listinfo/fiat-dev

---

From: Anders Logg <[email-masked]>
Date: Wed, 11 May 2005 20:47:38 -0500

It doesn't really matter for the mapping of dofs other than resulting
in different types of maps for for continuous and discontinuous
Lagrange elements. (And yes, all components are there so it's not
wrong, only different.)

For linear Lagrange with two components, FFC generates the following
map:

dofs[0] = cell.nodeID(0)
dofs[1] = cell.nodeID(1)
dofs[2] = cell.nodeID(2)
int offset = mesh.noNodes()
dofs[3] = offset + cell.nodeID(0)
dofs[4] = offset + cell.nodeID(1)
dofs[5] = offset + cell.nodeID(2)

And for discontinuous linear Lagrance with two components, FFC
generates the following map:

dofs[0] = 6*cell.id() + 0
dofs[1] = 6*cell.id() + 1
dofs[2] = 6*cell.id() + 2
dofs[3] = 6*cell.id() + 3
dofs[4] = 6*cell.id() + 4
dofs[5] = 6*cell.id() + 5

In the first case the dofs are blocked wrt components and in the
second case they are interleaved.

One place where it does matter is when I need to generate code for
projections (see other post). Maybe this can be solved by adding a
descriptor of the type of dof to DualBasis? In addition to entity ids
associated with nodes, could you store some enum which tells me the
type of node (for example point evaluation) and the corresponding
coordinate. Or is that already in there?

/Anders

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/

---

From: Robert C. Kirby <[email-masked]>
Date: Thu, 12 May 2005 09:06:40 -0500

Perhaps it would be good to make it consistent between the two, just in 
case we need it.

It strikes me that what we really want to do is optimize 
Cartesian-product vector-valued elements for FIAT and FFC eventually 
where I just wrap a scalar element (less data, fewer operations, etc).  
In FFC, making use of this will make inferring and exploiting block 
structure easier.  Also, for FErari, I can really focus on optimizing 
scalar-valued element forms, since I will be just fed in blocks.

Rob

Robert C. Kirby
Assistant Professor

---

From: Anders Logg <[email-masked]>
Date: Thu, 12 May 2005 09:36:37 -0500

> Perhaps it would be good to make it consistent between the two, just in 

ok. Tell me if and when you have pushed this into FIAT and I can check
that I get correct results for the dof map.

> scalar-valued element forms, since I will be just fed in blocks.

I agree. In addition to FFC being able to generate potentially faster
run-time code with such a structure, it would be faster compile
time. When I did this manually before (checking for functions that are
zero), the speedup was a factor 2 or 3 but then the evaluation of
integrals was much slower so the speedup might not be that good.

/Anders

---

From: Robert C. Kirby <[email-masked]>
Date: Thu, 12 May 2005 09:42:46 -0500

> that I get correct results for the dof map.

I am working at home, and I seem to go need to beat bombadil -- I can't 
ssh into it from here.
Perhaps searching for higher order linear dependencies has sent it to 
an early grave :)

> integrals was much slower so the speedup might not be that good.

I'm thinking of something much more on compile time.  First, you might 
be able to zero out entire blocks, not just particular functions 
(vector Laplacian).  Second, you will only look at scalar functions on 
each block as you know only one component of the vectors will be 
nonzero.  Third, if you break the problem into p different blocks, 
these are trivially parallel.  You could use Python MPI bindings (e.g. 
pyMPI by Pat Miller.  Matt also has some bindings that I think are 
wretched to install) to farm out the tensor computations for each block 
to different processors.  You could run this on fledermaus/ficus at UC 
if you want.  For 3D elasticity, remember there are nine blocks to 
compute.  If all the blocks were equal cost to compute (in fact the 
diagonal is worse for elasticity), you could get a speedup of nine for 
this (really it will be more like three or four since the diagonals 
dominate).

Rob

---

From: Anders Logg <[email-masked]>
Date: Thu, 12 May 2005 10:00:04 -0500

> Perhaps searching for higher order linear dependencies has sent it to 

I also have problems reaching bombadil. I can wait.

Maybe we could aim at releasing new versions of FIAT, FFC and DOLFIN
early next week? (Or tomorrow if we have it working by then.)

The missing piece right now is to do the projections/interpolations.
When that works, everything should be in place for general order
continuous Lagrange in 2D, q <= 2 in 3D (still need to decide on a
convention for the orientation of edges in 3D) and general order
continous Lagrange in 2D and 3D. Crouzeix-Raviart should also work.

> this (really it will be more like three or four since the diagonals 

Compiling the forms in parallel will be interesting to try, but I feel
it's not on the top of my todo-list right now.

/Anders

---

From: Robert C. Kirby <[email-masked]>
Date: Thu, 12 May 2005 10:13:07 -0500

> early next week? (Or tomorrow if we have it working by then.)

Hope so -- I'm leaving town for a week or so on Wednesday, then you get 
to have a baby.  I don't know what your bandwidth will be after the 
baby is born.  I also have to finish my reappointment case...BTW do you 
have a working title for the FFC paper so I can put it "in preparation"

> continous Lagrange in 2D and 3D. Crouzeix-Raviart should also work.

This should become a higher priority.  I know that doing user defined 
functions in Sundance is a little piece of nastiness.  The abstract 
projector is fine, but the class you shove into it isn't
> it's not on the top of my todo-list right now.
The bigger win will come with block structure and getting everything 
down to the interaction of scalar functions.  I also started looking at 
FFC a little.  I'd like to pose some things to try to speed up what you 
have when I understand it better.

But parallelism would be fun to exploit if we could find it (later).