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

Oliver Sander sander at igpm.rwth-aachen.de
Fri May 3 15:27:16 CEST 2013


Am 03.05.2013 15:18, schrieb Miguel de Benito Delgado:
> I ran the test with the same simple cube and things look perfectly ok.
>
Okay, that implies that the problem is not in the GmshReader.

A bug in the ALUGrid factory seems most likely to me.  Unfortunately I am not
an ALUGrid expert, and cannot help you there.

I you want to go hunting for it though, you may want to reduce your test
case further: skip the .msh file completely, and instead write C++ code
that feeds your small test grid directly into the ALUGrid factory.
Then report the bug on FlySpray and attach your test program.

Or just keep using UGGrid.

good luck,
Oliver



> 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
>>
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune





More information about the Dune mailing list