<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<p dir="auto">Hi Carsten, <br>
I'm probably not clear as I would.<br>
Subgrid module has nothing to do with intersection problem, absolutely.<br>
The incoherence is in the geometry grid I use. And it is perfectly replicated in subgrids, then I'm sure there is no problem in it.<br>
The only problem I have with subgrid module is that I cannot build a new module with dune 2.4.1 and subgrid r424. Do you know why? It works perfectly with dune 2.3.0... and it is a matter of cmake.</p>
<p dir="auto">Thanks again.<br>
Marco</p>
<p dir="auto">Marco Cisternino, PhD<br>
Software Developer<br>
marco.cisternino@optimad.it<br>
</p>
<br>
<br>
<br>
<div class="x_gmail_quote">On Wed, Jun 8, 2016 at 3:44 PM +0300, "Carsten Gräser"
<span dir="ltr"><<a href="mailto:graeser@mi.fu-berlin.de" target="_blank">graeser@mi.fu-berlin.de</a>></span> wrote:<br>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Marco,<br>
<br>
Am 08.06.2016 um 14:35 schrieb Marco Cisternino:<br>
> Hi Carsten,<br>
> I didn't mention subgrid because the problem I have with intersection corners does not involve subgrid module.<br>
> The toy code I sent to reproduce the error does not even depend on subgrid.<br>
> But to test my real code with dune 2.4.1, I need subgrid module dependence. That's why I'building with it!<br>
> I hope you can help me in building my code.<br>
> I slightly modified subgrid module to use it in parallel. Surely, it is not a good way to do it but it works. For this reason I would like to continue to use my r424 version of subgrid module.<br>
unfortunately I can't give support for your locally modified version of<br>
dune-subgrid. But I doubt that a 'slightly modified' version will work<br>
correctly in parallel. I'd expect problems especially wrt the<br>
intersections.<br>
<br>
Best,<br>
Carsten<br>
<br>
> <br>
> Thanks,<br>
> Marco<br>
> ________________________________________<br>
> Da: Carsten Gräser <graeser@mi.fu-berlin.de><br>
> Inviato: lunedì 6 giugno 2016 12.47.57<br>
> A: Marco Cisternino; Dune<br>
> Oggetto: Re: [Dune] Intersection area and corners<br>
> <br>
> Hi Marco,<br>
> <br>
> Am 01.06.2016 um 16:26 schrieb Marco Cisternino:<br>
>> Hi Martin,<br>
>><br>
>> I turned on the dune assertion but I have no interruption using dune 2.3<br>
>><br>
>> I tried to build my code using dune 2.4.1 and dune-subgrid r424 but<br>
>> dunecontrol tells me that it cannot find a configuration file for<br>
>> sune-subgrid.<br>
> you did not mention that you're using dune-subgrid before.<br>
> There's three possibilities:<br>
> <br>
> a)You're only marking complete levels for the subgrid.<br>
>   Then it will inherit the conformity of the host grid.<br>
> b)You're marking only parts of each level. Then you will<br>
>   in general have _non-conforming_ grids.<br>
> c)You're very carefull in marking parts of each grid<br>
>   level, such that the subgrid is still conforming.<br>
> <br>
> Since c) is very unlikely, I assume that either a) or b)<br>
> is true. In case of a), please try to give a test case<br>
> without using dune-subgrid. In case of b) please double<br>
> check if your grid is conforming, having in mind that<br>
> adaptively refined subgrids are in general non-conforming<br>
> in contrast to the hostgrid.<br>
> <br>
> Best,<br>
> Carsten<br>
> <br>
> <br>
>><br>
>> Is there a way to avoid this build error?<br>
>><br>
>> Thanks<br>
>><br>
>><br>
>> Bests,<br>
>> Marco<br>
>> ------------------------------------------------------------------------<br>
>> *Da:* Marco Cisternino <marco.cisternino@optimad.it><br>
>> *Inviato:* mercoledì 1 giugno 2016 16.01<br>
>> *A:* Martin Nolte; Dune<br>
>> *Oggetto:* Re: [Dune] Intersection area and corners<br>
>><br>
>><br>
>> Hi Martin,<br>
>><br>
>> I have a restart procedure, but I try to give the simplest version of<br>
>> the code reproducing the error.<br>
>><br>
>> However, I'll try to rebuild dune with assertion in order to see if even<br>
>> with dune 2.3 I have the same assertion interruption.<br>
>><br>
>> I'll try to move to 2.4, but I need to say if the dune-subgrid di<br>
>> compatible with this version, because I need it.<br>
>><br>
>> Did you need to change a lot of things in my code to run with dune 2.4?<br>
>><br>
>> What do you mean with bugs in initialization order??<br>
>><br>
>> Thanks a lot for your help.<br>
>><br>
>><br>
>> Marco<br>
>> ------------------------------------------------------------------------<br>
>> *Da:* Martin Nolte <nolte@mathematik.uni-freiburg.de><br>
>> *Inviato:* mercoledì 1 giugno 2016 12.29<br>
>> *A:* Dune<br>
>> *Oggetto:* Re: [Dune] Intersection area and corners<br>
>><br>
>> Hi Macro,<br>
>><br>
>> I ported you code to the master branch (which was not too painful). For me,<br>
>> the program results in an assertion (see output below), so I cannot<br>
>> reproduce<br>
>> your bug.<br>
>><br>
>> Unfortunately, your "small example" is really huge (> 4000 lines of code).<br>
>> This is quite a problem, because I have to understand (and trust) your<br>
>> example<br>
>> code, before I can start hunting bugs in GeometryGrid. At the moment, I do<br>
>> neither understand the code, nor do I trust it (my compiler spat out a<br>
>> ton of<br>
>> warnings, including bugs in initialization order). It also seems to me that<br>
>> the code can be further reduced.<br>
>><br>
>> Another problem is that the code runs quite some time in debug mode (to<br>
>> compute some parametrizations). Couldn't they be precompiled offline (on<br>
>> your<br>
>> machine) and be shipped as data?<br>
>><br>
>> To be honest, I am a bit at a loss how to help you. We're not supporting 2.3<br>
>> anymore (since 2.4 is released) and I cannot reproduce your bug in the<br>
>> master<br>
>> branch. Instead I get a curious assertion, which indicates you are<br>
>> dereferencing an end intersection iterator.<br>
>><br>
>> Best,<br>
>><br>
>> Martin<br>
>><br>
>> PS: This is the output I get:<br>
>><br>
>> Hello World! This is intersectionBug.<br>
>> I am rank 0 of 1 processes!<br>
>> Starting folder selection...<br>
>>  The folder exists. With write permissions.<br>
>>  The folder exists. With write permissions.<br>
>> End of folder selection...<br>
>> The number of element parameters is: 0<br>
>> The number of vertex parameters is: 0<br>
>> Has boundary parameters? 1<br>
>> 4018 vertices read.<br>
>> 0 is the size of vtxParams_<br>
>> 1920 elements read: 0 simplices, 0 pyramids, 0 prisms, 1920 cubes.<br>
>> 0 is the size of elParams_<br>
>> WARNING (ignored): Could not open file 'alugrid.cfg', using default<br>
>> values 0 <<br>
>> [balance] < 1.2, partitioning method 'ALUGRID_SpaceFillingCurve(9)'.<br>
>><br>
>> You are using DUNE-ALUGrid, please don't forget to cite the paper:<br>
>> Alkaemper, Dedner, Kloefkorn, Nolte. The DUNE-ALUGrid Module, 2016.<br>
>><br>
>> Created parallel ALUGrid<3,3,cube,nonconforming> from macro grid file<br>
>> 'testgrid2'.<br>
>><br>
>> Computing parametrizations...<br>
>> End of parametrizations computation...<br>
>> intersectionBug:<br>
>> /home/nolte/numerics/master/dune-alugrid/dune/alugrid/3d/topology.hh:201:<br>
>> static int Dune::ElementTopologyMapping<type>::dune2aluFace(int) [with<br>
>> Dune::ALU3dGridElementType type = (Dune::ALU3dGridElementType)7u]: Assertion<br>
>> `index >= 0 && index < numFaces' failed.<br>
>> Aborted<br>
>><br>
>><br>
>> On 05/30/2016 07:14 PM, Marco Cisternino wrote:<br>
>>> Hi Martin,<br>
>>><br>
>>> I found where the error is produced:<br>
>>><br>
>>><br>
>>> it is exaclty in dune/grid/geometrygrid/cornerstorage.hh in the<br>
>>> IntersectionCoordVector method<br>
>>><br>
>>> template< std::size_t size ><br>
>>>       void calculate ( array< Coordinate, size > (&corners) ) const<br>
>>><br>
>>> Here corners are computed by using<br>
>>><br>
>>>  corners[ i ] = elementGeometry_.global( hostLocalGeometry_.corner( i ) )<br>
>>><br>
>>><br>
>>> hostLocalGeometry_.corner( i ) gives the right coordinates in reference<br>
>>> element of corner i of the intersection, but the global() method gives the<br>
>>> wrong result<br>
>>><br>
>>> In global() method this statement is used to compute the return<br>
>>> mapping_->global( local )<br>
>>><br>
>>> if the mapping is affine (and this is the case) the method starts from<br>
>>> physical position of 0-corner of the element and compute the position of the<br>
>>> current corner by<br>
>>> jacobianTransposed_.umtv( local, global )<br>
>>><br>
>>> this is where the error is made: local is right and input global too, but<br>
>>> for only one element, namely element 43 and for only 2 corner, namely<br>
>>> {0,1,1}, i.e. corner 6 ,and {1,1,1}, i.e. corner 7 the results is wrong<br>
>>> I would say wrong jacobian but it works fine for all the other 6 corner of the<br>
>>> element (and the algorithm to compute it works for all the other intersections<br>
>>> in the grid!!)<br>
>>><br>
>>> Let me remark that elementGeometry_ member in IntersectionCoordVector has the<br>
>>> right physical corners relatives to {0,1,1}, i.e. corner 6 ,and {1,1,1}, i.e.<br>
>>> corner 7. So, it is a little bit weird to recompute intersection corners<br>
>>> starting from corner 0, instead of using corners stored in elementGeometry_.<br>
>>> Could you explain me why you chose this way?<br>
>>><br>
>>> Thanks for any help!<br>
>>> Bests,<br>
>>><br>
>>> Marco<br>
>>><br>
>>><br>
>>> ------------------------------------------------------------------------------<br>
>>> *Da:* Marco Cisternino <marco.cisternino@optimad.it><br>
>>> *Inviato:* venerdì 27 maggio 2016 19.13<br>
>>> *A:* Martin Nolte; Dune<br>
>>> *Oggetto:* Re: [Dune] Intersection area and corners<br>
>>><br>
>>><br>
>>> Hi Martin,<br>
>>><br>
>>> I prepared the smallest case I could do.<br>
>>><br>
>>> It is a bit slow because of the computation of the element parametrizations.<br>
>>><br>
>>> It will print at stdout the corners of the element (index 43) having the sick<br>
>>> intersection from the geometry grid and from the host one and the corners of<br>
>>> the sick intersection from both grids.<br>
>>><br>
>>> The intersection has index 3 in this element.<br>
>>><br>
>>> As you can see in the geometry grid case corners 0 and 1 of the intersection<br>
>>> are not at the same position of corners 6 and 7 of the element.<br>
>>><br>
>>> In the case of the host grid everything works fine.<br>
>>><br>
>>> I would no say the bug is in dune, but I cannot understand why the<br>
>>> intersection is not coherent with its element.<br>
>>><br>
>>> It is not evident from this code but the neighbour through this intersection<br>
>>> is not coherent too. Its index is 1025.<br>
>>><br>
>>><br>
>>> I remark that using the leaf mapper of the geometry grid crashes the run<br>
>>> giving segmantation fault, see line 142 of intersectionBug.cc.<br>
>>> All the test I made are serial.<br>
>>><br>
>>> If you need more feel free to ask.<br>
>>> Thanks for your help,<br>
>>><br>
>>> Marco<br>
>>> ------------------------------------------------------------------------------<br>
>>> *Da:* Marco Cisternino <marco.cisternino@optimad.it><br>
>>> *Inviato:* giovedì 26 maggio 2016 14.12<br>
>>> *A:* Martin Nolte; Dune<br>
>>> *Oggetto:* Re: [Dune] Intersection area and corners<br>
>>><br>
>>><br>
>>> Hi Martin,<br>
>>><br>
>>> I'll try to set up a small example.<br>
>>><br>
>>> The weird thing is that I have 2k elements in my coarse grid and this problem<br>
>>> occurs for only 1 intersection. That's why I would like to see how the<br>
>>> intersection is built, in order to understand if my code wrongly changes that<br>
>>> intersection object.<br>
>>><br>
>>> Thanks.<br>
>>><br>
>>><br>
>>> Marco<br>
>>><br>
>>><br>
>>><br>
>>> ------------------------------------------------------------------------------<br>
>>> *Da:* Martin Nolte <nolte@mathematik.uni-freiburg.de><br>
>>> *Inviato:* mercoledì 25 maggio 2016 17.47<br>
>>> *A:* Dune<br>
>>> *Oggetto:* Re: [Dune] Intersection area and corners<br>
>>><br>
>>> Hi Marco,<br>
>>><br>
>>> the intersection of GeometryGrid is based on the intersection of the host<br>
>>> grid. Then, you use the geometryInInside and the element geometry (of the<br>
>>> inside element) to build the global geometry of the intersection. So, in a<br>
>>> conforming situation, the corners of the intersection should be a subset of<br>
>>> the corners of the inside element.<br>
>>><br>
>>> Therefore, I consider your question a bug. Can you provide a small example?<br>
>>><br>
>>> Best,<br>
>>><br>
>>> Martin<br>
>>><br>
>>> On 05/25/2016 03:59 PM, Marco Cisternino wrote:<br>
>>>> Thank you Martin for your quick reply.<br>
>>>><br>
>>>> No, for the configuration I'm debugging I'm not dealing with non-conforming<br>
>>>> elements. That's why I cannot really understand why intersection and element<br>
>>>> are not coherent.<br>
>>>><br>
>>>> How the intersection is built? I could look in the constructor to see why its<br>
>>>> corners are not among the element corners.<br>
>>>><br>
>>>> Thanks again<br>
>>>><br>
>>>><br>
>>>> Marco<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ------------------------------------------------------------------------------<br>
>>>> *Da:* Martin Nolte <nolte@mathematik.uni-freiburg.de><br>
>>>> *Inviato:* mercoledì 25 maggio 2016 11.00<br>
>>>> *A:* Dune<br>
>>>> *Oggetto:* Re: [Dune] Intersection area and corners<br>
>>>><br>
>>>> Hi Marco,<br>
>>>><br>
>>>> I am not sure whether I get your question correctly. You seem to be comparing<br>
>>>> the geometry of the inside element to the geometry of the intersection.<br>
>>>><br>
>>>> This is only reasonable, if the intersection is conforming. Otherwise I expect<br>
>>>> the corners to be different. Is it possible, that your intersection is<br>
>>>> non-conforming?<br>
>>>><br>
>>>> Please note the using GeometryGrid with non-conforming grid views is a bit<br>
>>>> problematic. Basically you are creating a first order Lagrange function over a<br>
>>>> non-conforming grid. If you don't constrain hanging nodes, the position of a<br>
>>>> hanging node might not be on the edge of the bigger element but slightly moved.<br>
>>>><br>
>>>> You might also want to have a look at the following merge request:<br>
>>>><br>
>>>> <a href="https://gitlab.dune-project.org/core/dune-grid/merge_requests/60">https://gitlab.dune-project.org/core/dune-grid/merge_requests/60</a><br>
>> <<a href="https://gitlab.dune-project.org/core/dune-grid/merge_requests/60">https://gitlab.dune-project.org/core/dune-grid/merge_requests/60</a>><br>
>><br>
>> Bugfix/geometrygrid various (!60) · Merge Requests · Core Modules /<br>
>> dune-grid <<a href="https://gitlab.dune-project.org/core/dune-grid/merge_requests/60">https://gitlab.dune-project.org/core/dune-grid/merge_requests/60</a>><br>
>> gitlab.dune-project.org<br>
>> Grid Interface and Implementations<br>
>><br>
>><br>
>><br>
>>> <<a href="https://gitlab.dune-project.org/core/dune-grid/merge_requests/60">https://gitlab.dune-project.org/core/dune-grid/merge_requests/60</a>><br>
>>><br>
>>> Bugfix/geometrygrid various (!60) · Merge Requests · Core Modules / dune-grid<br>
>>> <<a href="https://gitlab.dune-project.org/core/dune-grid/merge_requests/60">https://gitlab.dune-project.org/core/dune-grid/merge_requests/60</a>><br>
>>> gitlab.dune-project.org<br>
>>> Grid Interface and Implementations<br>
>>><br>
>>><br>
>>><br>
>>>> <<a href="https://gitlab.dune-project.org/core/dune-grid/merge_requests/60">https://gitlab.dune-project.org/core/dune-grid/merge_requests/60</a>><br>
>>>><br>
>>>> Bugfix/geometrygrid various (!60) · Merge Requests · Core Modules / dune-grid<br>
>>>> <<a href="https://gitlab.dune-project.org/core/dune-grid/merge_requests/60">https://gitlab.dune-project.org/core/dune-grid/merge_requests/60</a>><br>
>>>> gitlab.dune-project.org<br>
>>>> Grid Interface and Implementations<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> It deals with normals in non-conforming grids, which might also be buggy in<br>
>>>> DUNE 2.3.<br>
>>>><br>
>>>> Best,<br>
>>>><br>
>>>> Martin<br>
>>>><br>
>>>> On 05/25/2016 10:44 AM, Marco Cisternino wrote:<br>
>>>>> Good morning,<br>
>>>>> I have a problem with one intersection in my dune application.<br>
>>>>> The area I get is not what I expect.<br>
>>>>> So I tried to look inside the Intersection object using gdb<br>
>>>>> It is important to say that my grid is a GeometryGrid with a DiscreteFunction to parametrize the elements.<br>
>>>>><br>
>>>>> If I look at these two things:<br>
>>>>><br>
>>>>> - *(in.real.insideGeo_.mapping_)<br>
>>>>> - *(iGeo.realGeometry.mapping_)<br>
>>>>><br>
>>>>> where the in variable type is<br>
>>>>> GeometryGrid::LeafGridView::IntersectionIterator::Intersection<br>
>>>>> and iGeo is<br>
>>>>> GeometryGrid::LeafGridView::IntersectionIterator::Intersection::Geometry<br>
>>>>><br>
>>>>> I see different corners stored in. I mean two of the 4 corners given by *(iGeo.realGeometry.mapping_) are different from the two correspondant corners given by *(in.real.insideGeo_.mapping_). All the other corners are the same.<br>
>>>>><br>
>>>>> If I compute the intersection area using corners given by *(in.real.insideGeo_.mapping_), I get the right area. On the other hand, if I compute the intersection area using the corners given by *(iGeo.realGeometry.mapping_), the area is wrong.<br>
>>>>><br>
>>>>> I want to specify that the corners given by *(in.real.insideGeo_.mapping_) are the same I get using e.geometry().corners(i) where e is of type<br>
>>>>> GeometryGrid::LeafGridView::template Codim<0>::template Partition<Dune::InteriorBorder_Partition>::Iterator::Entity<br>
>>>>><br>
>>>>> Could anyone help me please? Am I doing something wrong?<br>
>>>>> Ask for more details if you need.<br>
>>>>><br>
>>>>> I'm using DUNE 2.3 with ALUGrid 1.52. I know it is old, but at the moment I cannot migrate to the new Dune releases.<br>
>>>>><br>
>>>>> Thanks a lot!<br>
>>>>><br>
>>>>> Marco<br>
<br>
<br>
-- <br>
Prof. Dr. Carsten Gräser<br>
Freie Universität Berlin<br>
Institut für Mathematik<br>
Arnimallee 6<br>
14195 Berlin, Germany<br>
phone: +49 30 838 72637<br>
fax  : +49 30 838 472637<br>
email: graeser@mi.fu-berlin.de<br>
URL  : <a href="http://page.mi.fu-berlin.de/graeser">http://page.mi.fu-berlin.de/graeser</a><br>
<br>
</div>
</span></font>
</body>
</html>