[Dune] Physical entities read by GmshReader seem to "bleed out"

Miguel de Benito Delgado m.debenito.d at gmail.com
Fri May 3 15:18:34 CEST 2013


I ran the test with the same simple cube and things look perfectly ok.

I also tried with the grids I'm using in my problem and everything looks fine. Meaning: indices are correctly associated to the 

So, is this a bug in the factory? Foolish misuse? Cosmic rays?

I'd bet on the first, but I'm so very often wrong...
--
Miguel de Benito.


On 3 May, 2013, at 14:37, Miguel de Benito Delgado <m.debenito.d at gmail.com> wrote:

> Hi,
> 
> thanks a lot for your suggestions. I've tried a cube with a coarser ALUGrid with 24 triangles on the surface (less and the GridFactory would assert()). I've configured the functor to have support just on one of the sides of the cube. There's still a vertex which shouldn't be there:
> 
>  https://dl.dropboxusercontent.com/u/15831115/wrongsupport2.png
> 
> I've checked the generated mesh (indeed quite easier now ;) and the elements seem ok:
> 
> $Elements
> 48
> 1 2 2 1 6 2 3 9
> 2 2 2 1 6 2 9 1
> 3 2 2 1 6 4 9 3
> 4 2 2 1 6 4 1 9
> 5 2 2 2 15 5 10 6
> 6 2 2 2 15 10 5 1
> 7 2 2 2 15 10 2 6
> 8 2 2 2 15 2 10 1
> ...
> 
> (Reminder: Each row is: id, type (2=triangle), numproperties, physical-id, internal-id, vertex1, vertex2, vertex3)
> 
> As can be seen, physical entity 1 contains exactly four triangles so I see no reason for that extra vertex in the support, since I check at the intersection level:
> 
> for (auto it = gv.template begin<0>(); it != gv.template end<0>(); ++it)
>   for (auto is = gv.ibegin (*it) ; is != gv.iend (*it) ; ++is)
>     if (func.isSupported (*is)) {
>       const auto& ref = 
>         GenericReferenceElements<ctype, dim>::general (it->type());
>       const int ivnum = ref.size (is->indexInInside (), 1, dim);
>       for (int i = 0; i < ivnum; ++i) {
>         int  subi = ref.subEntity (is->indexInInside (), 1, i, dim);
>         auto  idx = mapper.map (*it, subi, dim);
>         support[idx] = 1.0;
>       }
>     }
> 
> And this is func.isSupported():
> 
> template <class Intersection>
> bool isSupported (const Intersection& is) const
> {
>   if (is.neighbor() || !is.boundary() || !gf.wasInserted (is)) return false;
>   auto idx = gf.insertionIndex (is);
>   return (idx > 0 && idx < bi2pe.size() && bi2pe[idx] == group_identifier);
> }
> 
> If someone feels like peeking into it, the updated project is at the same location.
> 
> I guess I'll have to compile UGGrid...
> --
> Miguel de Benito.
> 
> On 2 May, 2013, at 16:05, Oliver Sander <sander at igpm.rwth-aachen.de> wrote:
> 
>> Hi Miguel,
>> can you reproduce the same effect with a different grid, say UGGrid?
>> can you reproduce the same effect with a smaller mesh?  A one-digit
>> number of elements would be a lot easier to debug.
>> Best,
>> Oliver
>> 
>> Am 02.05.2013 10:42, schrieb Miguel de Benito Delgado:
>>> Dear Duners,
>>> 
>>>  I use GmshReader to load a mesh with "Physical Surfaces" into an ALUGrid, then use the GridFactory's methods wasInserted(), and insertionIndex() to retrieve them. This I do into the functors I'll
>>> use for my boundary conditions.
>>> 
>>>  Apparently, so far, so good. I guess this should be pretty standard. But in the tests for the functors, I plot the support and export it to vtk and see that it's not what it should be. In this test:
>>> 
>>> https://dl.dropboxusercontent.com/u/15831115/wrongsupport.png
>>> 
>>> the support of the functor is set to be two of the lateral sides of the prism but it's obviously wrong (the front side is *not* among the physical surfaces in the support).
>>> 
>>> I've uploaded a minimal dune project here:
>>> 
>>> https://dl.dropboxusercontent.com/u/15831115/gmshreadertest.tar.bz2
>>> 
>>> Am I doing anything wrong? Is this a problem in GmshReader? I'd be most grateful for any comments or ideas.
>>> 
>>> Best,
>>> --
>>> Miguel de  Benito.
>>> 
>>> 
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>> 
>> 
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
> 





More information about the Dune mailing list