Subject: [UFC-dev] Another init function in dof_map?

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 10 Jan 2007 10:33:14 +0100

We have
  bool init_mesh(mesh &)
  void init_cell(mesh &, cell &)
but maybe we also should have a
  void init_finalize()
?

So it would be

 if(dm.init_mesh(m))
{
    for all cells c
        dm.init_cell(c)
}
dm.init_finalize()

This will allow the dofmap to f.ex. pack data into a static and more
efficient structure after all cells have been touched. An efficient
structure for inserting isnt' always the same as an efficient
structure for lookup.

martin

---

From: Ola Skavhaug <[email-masked]>
Date: Wed, 10 Jan 2007 10:44:17 +0100

> structure for inserting isnt' always the same as an efficient

I agree on the existence, if not on the choice of name, for this method.
Some suggestions:

    dm.init_cell_finalize()
    dm.optimize()
    dm.compute_static_dofmap()

Any better suggestions?

Ola
 
> martin
> _______________________________________________
> UFC-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufc-dev

---

From: Anders Logg <[email-masked]>
Date: Wed, 10 Jan 2007 10:50:25 +0100

>     dm.compute_static_dofmap()

How about

    bool init() const;
    void init_begin(mesh&);
    void init_cell(cell&);
    void init_end();

?

So it would be

   if dm.init()
   {
       dm.init_begin(m);
       for (c in cells)
           dm.init_cell(c);
       dm.init_end();
   }

/Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 10 Jan 2007 10:53:45 +0100

> >     dm.compute_static_dofmap()

These two
>     dm.compute_static_dofmap()
are too specific about what the function should do.

This
>     dm.init_cell_finalize()
is ok, it tells better that it is the init_cell loop that is finalized.

>        dm.init_end();

No. The dof_map always needs to know at least the size of the mesh to
return a correct value from global_dimension. But not always to
iterate over the cells, which is of course the costly part. But it
could be

     if(dm.begin(m))
    {
        for (c in cells)
            dm.init_cell(c);
        dm.init_end();
    }

martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 10 Jan 2007 11:02:43 +0100

> iterate over the cells, which is of course the costly part. But it

ok. I vote for adding init_cell_finalize();

/Anders

---

From: Kent-Andre Mardal <[email-masked]>
Date: Wed, 10 Jan 2007 11:03:55 +0100

> >     dm.compute_static_dofmap()

dm.init_end() is (usually?) an O(n) algorithm, should it be optional 
to do 'init_end()'.  

Or maybe this is handled in by the code generation, i.e., init_end() 
is empty unless the user ask for it to be none-empty? 

Kent

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 10 Jan 2007 11:12:56 +0100

> is empty unless the user ask for it to be none-empty?

Code generation (or possibly manual implementation in other systems)
defines the way the dof_map is implemented. It init_end() is optional,
the other dof_map functions probably becomes less efficient because
they have to do more checking.

So this function should always be called, and efficiency issues like
you describe should be handled by using a different dof_map structure.
For a particular implementation, different behaviour could be chosen
by runtime calls as long as there is a default behaviour.

martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 10 Jan 2007 11:18:59 +0100

> by runtime calls as long as there is a default behaviour.

We've discussed this before, but would it be possible at all to avoid
having the init_cell() functions in dof_map?

FFC will always return false in init_mesh(). Even so, we have a class
DofMap in DOLFIN that is used to compute the mapping from local to
global dofs (with the help of ufc::dof_map). This way, all the
algorithmic stuff (reordering, parallelism etc) can be handled by the
C++ implementation dof_map and we don't need to generate code for it.

Would it be possible to do something similar in SyFi, keeping dof_map
simple and doing the complicated stuff, searching reordering etc
somewhere else?

The advantage would be that we can remove the init_* functions and all
functions in the UFC interface would be const.

/Anders