I've pushed a fix for this to master. Cian, could you test it? Longer term the assembly code in question needs some re-factoring.
Garth On 20 March 2015 at 11:05, Garth N. Wells <[email protected]> wrote: > So this doesn't get lost, I've registered it as an issue: > > https://bitbucket.org/fenics-project/dolfin/issue/494 > > Garth > > On Tue, Feb 10, 2015 at 4:28 PM, Garth N. Wells <[email protected]> wrote: > > On Tue, Feb 10, 2015 at 3:48 AM, Cian Wilson <[email protected]> > wrote: > >> Hello, > >> > >> Just finished upgrading to the 1.5.0 release. Very excited about dg > >> parallel so thank you for all the hard work. > >> > >> I noticed in some of my test cases that use meshes converted from gmsh > using > >> dolfin-convert now fail when assembling facet wise in SystemAssembler. > This > >> appears to be caused by a new assumption, that any facet will only have > one > >> neighboring cell for which that facet is local facet 0. > > > > We shouldn't be making this assumption - it will not be true for all > meshes. > > > >> This assumption > >> appears to be true for internally generated meshes but not for gmsh > meshes > >> converted using dolfin-convert. > >> > >> I'm attaching a unit test that demonstrates the problem using > dolfin-1.5.0 > >> (though there are no changes to meshconvert.py or SystemAssembler.cpp > >> between dolfin-1.5.0 and master that would fix this). This is based on > >> test_system_assembler.py and runs test_facet_assembly_cellwise_insertion > >> twice, once with an internal UnitInterval mesh and once with a gmsh unit > >> interval mesh converted using dolfin-convert. The first run passes but > the > >> second fails because cell_index gets set to a single value for both > >> neighboring cells at SystemAssembler.cpp:714 and then used to access the > >> cell_dofs for both cells at SystemAssembler.cpp:747. > > > > Are your lines number w.r.t. the 1.5 release? > > > > Garth > > > > This is fine if only > >> one of the neighboring cells has the facet as local facet 0 but causes > the > >> matrix (in this case a simple P0 mass matrix) to have double values > inserted > >> for some cells and nothing inserted on the diagonal elsewhere. More > >> generally this assumption crops up in other places that don't affect > this > >> test case. For example, cell_integrals and tensor_required_cell make > the > >> same assumption. > >> > >> I've hacked around and removed the assumptions in a branch > >> ( > https://bitbucket.org/tferma/dolfin/branch/systemassemblertensorrequiredfix > ) > >> to confirm that it fixes my test cases (which it does) but I wanted to > check > >> whether this was intentional or not. Is it now a required that every > facet > >> only has a single neighboring cell for which that facet is local facet > 0? > >> If so I guess gmsh conversion in mshconvert.py needs fixing instead and > I'd > >> appreciate any tips on ensuring this. > >> > >> Any advice much appreciated. > >> > >> Many thanks, > >> Cian > >> > >> > >> _______________________________________________ > >> fenics mailing list > >> [email protected] > >> http://fenicsproject.org/mailman/listinfo/fenics > >> >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
