> > > [EMAIL PROTECTED] wrote: >>> >>> [EMAIL PROTECTED] wrote: >>>>> [EMAIL PROTECTED] wrote: >>>>>>> [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>" >>>>>>>>> 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
