dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

On Fri, May 15, 2009 at 2:25 PM, Johan Hake <hake@xxxxxxxxx> 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?).

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
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>



-- 
Ola Skavhaug