On Friday 15 May 2009 14:27:09 Ola Skavhaug wrote: > On Fri, May 15, 2009 at 2:25 PM, Johan Hake <[email protected]> wrote: > > On Friday 15 May 2009 13:37:48 Anders Logg wrote: > >> There have been some big changes to the code lately. Here's a summary: > >> > >> 1. We now use the wrappers module in dolfin_utils to generate the > >> DOLFIN wrapper code (in both FFC and SFC). This module generates > >> slightly different code to the old FFC wrappers. Most notably, > >> typedefs are used to avoid code duplication and classes/namespaces are > >> now nested. For application code, that means one must change from > >> > >> PrefixBilinearForm > >> PrefixLinearForm > >> PrefixTestSpace > >> PrefixTrialSpace > >> to > >> > >> Prefix::BilinearForm > >> Prefix::LinearForm > >> Prefix::BilinearForm::TestSpace > >> Prefix::BilinearForm::TrialSpace > >> > >> etc. > >> > >> If all test and trial spaces are equal, then a common class named > >> > >> Prefix::FunctionSpace > >> > >> will be created (a typedef). > >> > >> Some of you may remember that we've had this interface before, but > >> then had to remove it due to problems with SWIG. Now that SWIG just > >> looks at the pure UFC code it's not a problem anymore. > >> > >> 2. Initialization of mesh entities now happens in the constructor of > >> DofMap. The initialization happens automitcally only if the new > >> non-const (wrt Mesh) constructor of FunctionSpace is used. If the > >> const version is used, then an error message is given. So if you solve > >> something with P2 elements and need the edges, these must either first > >> be generated using mesh.init(1) or the non-const constructor must be > >> used. Most demos should remain unchanged. > > > > As swig does not distinguish between const and non const parameters this > > results in an overload warning. This is easely fixed, by an ignore > > statement. Just to be sure I do the right thing here, the right > > constructor to ignore is the const mesh one, right? > > Yes (Doesn't SWIG discard the const anyway?).
Yes, and that's why swig treats them as equal :) Stupid... Johan > Ola > > > Johan > > > >> 3. When running in parallel not only will the entities be generated, > >> but they will also be numbered globally. So all mesh entities have a > >> unique global index accessible in the data section of a mesh (named > >> "global entity indices %d"). The global dof map should also be > >> computed correctly now but I haven't checked. This means we may in > >> principle assemble in parallel now. But probably not in > >> practice... :-) > > > > _______________________________________________ > > 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
