dolfin team mailing list archive

[kent-and@xxxxxxxxx]

>
>
> kent-and@xxxxxxxxx wrote:
>>>
>>> kent-and@xxxxxxxxx wrote:
>>>>> kent-and@xxxxxxxxx wrote:
>>>>>>> kent-and@xxxxxxxxx wrote:
>>>>>>>>> One or more new changesets pushed to the primary dolfin
>>>>>>>>> repository.
>>>>>>>>> A short summary of the last three changesets is included below.
>>>>>>>>>
>>>>>>>>> changeset:   4730:6548c25c33352492c9279c035509a139caab323b
>>>>>>>>> tag:         tip
>>>>>>>>> user:        "Garth N. Wells <gnw20@xxxxxxxxx>"
>>>>>>>>> date:        Tue Sep 09 13:08:58 2008 +0100
>>>>>>>>> files:       dolfin/fem/Assembler.cpp dolfin/pde/LinearPDE.cpp
>>>>>>>>> description:
>>>>>>>>> Revert to old assembly in LinearPDE due to bug in symmetric
>>>>>>>>> assembly.
>>>>>>>>>
>>>>>>>>> There is a problem with exterior facets in the symmetric
>>>>>>>>> assembly.
>>>>>>>>> The
>>>>>>>>> code needs to be broken up to make debugging easier.
>>>>>>>>>
>>>>>>>> Agree that it should be broken up. But it will take some effort.
>>>>>>>> Do you have an example where the bug is apparent ?
>>>>>>>>
>>>>>>> I was using a RT0 element (not one of the demos).  It should be
>>>>>>> reproducible by adding a non-zero Dirichlet bc (given be a
>>>>>>> Function)
>>>>>>> to
>>>>>>> the mixed-poisson demo.
>>>>>>>
>>>>>>> I had a quick look, but I couldn't find the problem, so I thought
>>>>>>> it
>>>>>>> better to wait until the code is broken up.
>>>>>>>
>>>>>>> Garth
>>>>>>>
>>>>>> Strange, I see no reason for this not to work.
>>>>>> (since the code involving only cell integrals is pretty clean, but
>>>>>> ...)
>>>>>>
>>>>>> Anyway, I noticed that with my setup, CG is used. CG can not be used
>>>>>> in this case since the problem is not positive. Did you use CG ?
>>>>> No, I used an LU solver. I first noticed the problem when the LU
>>>>> solvers
>>>>> return a message that the system was singular. I only looked at the
>>>>> computation of the RHS vector which was zero when it  shouldn't have
>>>>> been.
>>>> Ok, and I guess the system is singular unless you have a mix of
>>>> essential
>>>> and natural
>>>> bc.  But the rhs should not be zero.
>>>>
>>> The essential bcs appear in the form for this problem, so the assembler
>>> shouldn't be doing anything extra for the bcs (bcs.size() = 0 in
>>> Asssembler.cpp). Makes the bug rather strange.
>>>
>>> Garth
>>>
>>
>> So the essential bc that you refer to is the essential bc for the
>> classical Poisson problem
>> which ends up as natural in the mixed formulation. So you have something
>> like:
>>
>> L = w*f*dx + w*g*ds
>>
>
> Exactly.
>

OK, I think I have fixed it.

I have replaced:

if (facet->numEntities(D) ==1 )

(which I thought was appropriate)

with

if (facet->numEntities(D) != 2)


Kent