dolfin team mailing list archive

[kent-and@xxxxxxxxx]

>
>
> 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

I'll have a look.

(But as already said, I completely agree on breaking up)

Kent