[Dune] Returning Geometries As Objects (again)

[Martin Nolte]

Hi Oli,

test-alberta-3-3 segfaults with me. The recursive bisection simply exhausts 
the execution stack. This is due to the tested grid (simplex-testgrid-3.dgf). 
I could change the dgf file to make the test work (e.g., grid3Y.dgf). You can 
test this yourself by executing

./test-alberta-3-3 ../../../doc/grids/dgf/grid3Y.dgf

Unfortunately, I'm not aware of any algorithm that will ensure the recursive 
bisection will not run into infinite loops in 3d. For some grids it helps to 
select the longest edges are refinement edges. Unfortunately, this does not 
work, if the two longest edges don't share a common vertex (as is the case for 
simplex-testgrid-3.dgf). To test this, simply add the block

GRIDPARAMETER
REFINEMENTEDGE LONGEST
#

to the dgf file.

Best,

Martin


On 02/07/2012 09:57 AM, Oliver Sander wrote:
> Hi Martin,
>>
>> does the test-alberta-3-3 check run in the trunk? As far as I remember,
>> the test grid will cause a segmentation fault in the recursive bisection
>> algorithm (ALBERTA internal). If the test does not run in the trunk, I
>> would not consider this a showstopper (though this is my opinion).
>>
> I was speaking of the trunk. The test 'runs', but it fairly quickly starts
> exhausting all of my humble 4GB main memory. I had to kill it eventually.
>
>> I would also like to know what exactly you mean by 'the test suite on
>> the branch passes'? For me, it does pass if I do not use any external
>> grid (i.e., ALBERTA, ALUGrid, UG). Otherwise, you have to specify
>> versions of the external packages in question.
>
> I guess I would want it tested with those three external grid managers,
> all in their respective latest versions.
>
> Best,
> Oliver
>
>>
>> Your other point hits a nail on the head. The lifetime issue bothers me,
>> too. My trouble, however, is that this issue was never specified
>> explicitly for any object in dune-grid.
>>
>> For example, does an intersection iterator have to survive the entity?
>> While I don't see any reason for this and would say 'no', where
>> performance can be gained, users of the STL might tend to think 'yes',
>> because their container is the grid view.
>>
>> Just out of curiosity: What is the lifetime of the entity anyway? The
>> longest time an entity pointer to the entity exists? When are two
>> entities considered equal in the aforementioned question?
>>
>> Until now, I had in mind to discuss this issue (at least for the
>> geometry) on the next developer meeting.
>>
>> With respect to the Geometry object, I see two possible approaches in
>> the long run: We could specify
>> a) that the geometry need not survive the entity,
>> b) that the lifetime of the geometry is independent of the entity.
>> In both cases, I think the current solution is a good transition, though.
>>
>> If it helps, I can add a note on the lifetime in the documentation of
>> the geometry methods.
>>
>> Best,
>>
>> Martin
>>
>>
>> On 02/06/2012 12:22 PM, Oliver Sander wrote:
>>> Hi Martin,
>>> when I run make check in dune-grid, then all tests pass, except for
>>> test-alberta-3-3 which I had to kill when it started swapping.
>>> (That's with Alberta 2.0, the version from Debian). So all in all
>>> the test situation is not all that bad.
>>>
>>> Since you are preparing a fairly invasive patch, which may lead to
>>> difficult-to-find bugs [1], I think it would be reasonable to ask that
>>> the test suite on the branch passes before merging.
>>>
>>> [1] Actually, the idea of having Geometry objects that look like value
>>> objects but behave like references scares me quite a bit. Before,
>>> we had object lifetime issues with geometries, because they where
>>> just references. But at least you could see there was trouble because
>>> the relevant methods returned references. If the methods now return
>>> objects without the little '&', but the lifetime behavior stays the
>>> same, then I foresee major debugging trouble and user frustration.
>>>
>>> Cheers,
>>> Oliver
>>>
>>>
>>> Am 06.02.2012 10:07, schrieb Martin Nolte:
>>>> Hi Christoph,
>>>>
>>>> The check now passes for me (with some minimalistic configure options).
>>>> Thanks again for pointing this out.
>>>>
>>>> With respect to your comment: I agree that in an ideal world, tests
>>>> should compile and run at all times. However, truth is different and I
>>>> think this is due to a chicken-egg problem:
>>>>
>>>> 'make check' fails before I start my change, so it is rather pointless
>>>> to try 'make check' after my change. However, since my change might have
>>>> introduced a bug, 'make check' will not even work when other bugs are
>>>> fixed.
>>>>
>>>> Another problem seems to be the large number of configure options in
>>>> comparison to the small number of users (I also count developers, here).
>>>> I would guess that less than 5% of all possible configurations are
>>>> tested (used) on a regular basis.
>>>>
>>>> For example, dune-grid tries to support two versions of ALBERTA to
>>>> provide the AlbertaGrid (mostly supported by me). There two versions
>>>> have some important differences. Since I only use a cutting-edge version
>>>> (which will become ALBERTA 3.0), ALBERTA 2.0 is scarcely tested. In this
>>>> case, even 'make check' does not help, because with me everything works
>>>> fine.
>>>>
>>>> As a possibility, we could provide a table of configure options (and
>>>> external modules) that are actually used by the developers and, hence,
>>>> tested on a regular basis. If a certain configure option is not used by
>>>> any developer, we could mark it untested or even remove it. However,
>>>> this is a different story and needs discussion.
>>>>
>>>> Anyway, I think getting 'make check' to fully work before the merge
>>>> would mean to wait until after Easter (if not Christmas). And having two
>>>> actively developed branches only leads to their diverging.
>>>>
>>>> In my opinion, it would be best, if every developer (or even user) would
>>>> test his code with the branch and report any new bugs encountered.
>>>> Notice, however, that some bug fixes in the trunk have not been
>>>> backported to the branch.
>>>>
>>>> Unfortunately, it seems that few developers are interested in testing
>>>> before the merge (or trust me too much). So, unless somebody finds a
>>>> real showstopper in the branch or gives me a good reason not to merge, I
>>>> will merge the branch as scheduled, i.e., some time tomorrow.
>>>>
>>>> Best,
>>>>
>>>> Martin
>>>>
>>>>
>>>> On 02/05/2012 04:03 PM, "Christoph Grüninger" wrote:
>>>>> (Sorry, my new webmailer is strange. I resent this message, hopefully
>>>>> without HTML junk inside.)
>>>>>
>>>>> Hi,
>>>>> concerning Jö's question:
>>>>>
>>>>>> Do I understand correctly, this happens on the trunk (as well as on
>>>>>> Martin's branch)?
>>>>>
>>>>> No, make check passes through for trunk. Only on Martin's branch I
>>>>> get the error.
>>>>>
>>>>> BTW, should dune/grid/genericgeometry/test/testbasicgeometry.cc be
>>>>> moved to dune-geometry? The test seems to contain no dependencies
>>>>> to dune-grid. But I am still confused by the dozen geometry classes...
>>>>>
>>>>> I reran my tests with ALUGrid 1.50 enabled. I was surprised by the
>>>>> current trunk. At least one test did not compile at all, see below.
>>>>> Some tests failed for dune-grid like
>>>>>
>>>>> /bin/sh: Zeile 9: ./subsamplingvtktest: Datei oder Verzeichnis nicht
>>>>> gefunden
>>>>> FAIL: subsamplingvtktest
>>>>>
>>>>> The pdelab test using central differences took ages to run through
>>>>> and one of 22 tests failed (I don't know which).
>>>>>
>>>>> Using Martin's branch DuMuX went through, too. But PDELab failed
>>>>> completely for the central differences, see the defect nan after
>>>>> one step.
>>>>>
>>>>> Maybe we should fix the tests before we merge the branch? Having tests
>>>>> is kind of pointless if nobody runs them and it is not noticed when
>>>>> they fail.
>>>>>
>>>>> Bye
>>>>> Christoph
>>>>>
>>>>>
>>>>>
>>>>> ==========
>>>>> Error from dune-grid make check (trunk with ALUGrid 1.50):
>>>>>
>>>>> vertexordertest.cc: In function ‘int main(int, char**)’:
>>>>> vertexordertest.cc:290:23: warning: unused variable ‘mpihelper’
>>>>> [-Wunused-variable]
>>>>> In file included from vertexordertest.cc:21:0:
>>>>> /home/kiko/Dokumente/workspace/trunkDumux/dune-common/dune/common/fvector.hh:
>>>>>
>>>>>
>>>>>
>>>>> In constructor ‘Dune::FieldVector<K, SIZE>::FieldVector(const
>>>>> Dune::DenseVector<Other>&) [with C = Dune::FieldVector<double, 2>, K =
>>>>> double, int SIZE = 3]’:
>>>>> vertexordertest.cc:258:53: instantiated from ‘void
>>>>> testVertexOrderByIdSimplices(int&) [with Grid = Dune::ALUConformGrid<2,
>>>>> 3>]’
>>>>> vertexordertest.cc:321:69: instantiated from here
>>>>> /home/kiko/Dokumente/workspace/trunkDumux/dune-common/dune/common/fvector.hh:130:7:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> error: static assertion failed: "FieldVectors do not match in
>>>>> dimension!"
>>>>> /home/kiko/Dokumente/workspace/trunkDumux/dune-common/dune/common/fvector.hh:
>>>>>
>>>>>
>>>>>
>>>>> In constructor ‘Dune::FieldVector<K, SIZE>::FieldVector(const
>>>>> Dune::DenseVector<Other>&) [with C = Dune::FieldVector<double, 3>, K =
>>>>> double, int SIZE = 2]’:
>>>>> ../../../../dune/grid/utility/structuredgridfactory.hh:212:17:
>>>>> instantiated
>>>>> from ‘static std::shared_ptr<_Tp>
>>>>> Dune::StructuredGridFactory<GridType>::createSimplexGrid(const
>>>>> Dune::FieldVector<typename GridType::ctype,
>>>>> Dune::StructuredGridFactory<GridType>::dimworld>&, const
>>>>> Dune::FieldVector<typename GridType::ctype,
>>>>> Dune::StructuredGridFactory<GridType>::dimworld>&, const
>>>>> std::array<unsigned int, Dune::StructuredGridFactory<GridType>::dim>&)
>>>>> [with GridType = Dune::ALUConformGrid<2, 3>, typename GridType::ctype =
>>>>> double]’
>>>>> vertexordertest.cc:258:53: instantiated from ‘void
>>>>> testVertexOrderByIdSimplices(int&) [with Grid = Dune::ALUConformGrid<2,
>>>>> 3>]’
>>>>> vertexordertest.cc:321:69: instantiated from here
>>>>> /home/kiko/Dokumente/workspace/trunkDumux/dune-common/dune/common/fvector.hh:130:7:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> error: static assertion failed: "FieldVectors do not match in
>>>>> dimension!"
>>>>> make[5]: *** [vertexordertest-vertexordertest.o] Fehler 1
>>>>>
>>>>>
>>>>> ==========
>>>>> PDELab make check output with some of the tests before the failing
>>>>> one to easy to recognize which test failed (PDELab trunk, ALUGrid
>>>>> 1.50, dune-grid from Martin's branch):
>>>>>
>>>>> [..]
>>>>> PASS: testpk
>>>>> testpoisson:
>>>>> /home/kiko/Dokumente/workspace/trunkDumux_branch/dune-common/dune/common/fvector.hh:245:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> const K& Dune::FieldVector<K, 1>::vec_access(Dune::FieldVector<K,
>>>>> 1>::size_type) const [with K = double, Dune::FieldVector<K,
>>>>> 1>::size_type =
>>>>> long unsigned int]: Assertion `i == 0' failed.
>>>>> /bin/sh: Zeile 5: 2030 Abgebrochen ${dir}$tst
>>>>> FAIL: testpoisson
>>>>> testpoisson-globalfe:
>>>>> /home/kiko/Dokumente/workspace/trunkDumux_branch/dune-common/dune/common/fvector.hh:245:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> const K& Dune::FieldVector<K, 1>::vec_access(Dune::FieldVector<K,
>>>>> 1>::size_type) const [with K = double, Dune::FieldVector<K,
>>>>> 1>::size_type =
>>>>> long unsigned int]: Assertion `i == 0' failed.
>>>>> /bin/sh: Zeile 5: 2037 Abgebrochen ${dir}$tst
>>>>> FAIL: testpoisson-globalfe
>>>>>
>>>>> Hmesh_basic::ascireadtriang(?) opens: grids/2dsimplex.alu
>>>>>
>>>>> Created serial ALUSimplexGrid<2,2> from macro grid file
>>>>> 'grids/2dsimplex.alu'.
>>>>> PASS: testrt0
>>>>> ALU
>>>>>
>>>>> Hmesh_basic::ascireadtriang(?) opens: grids/2dtriangle.alu
>>>>>
>>>>> Created serial ALUSimplexGrid<2,2> from macro grid file
>>>>> 'grids/2dtriangle.alu'.
>>>>>
>>>>> PASS: testrt02dgridfunctionspace
>>>>> [0:1] [1:1] [2:1] [3:1] [4:1] [5:1] [6:1] [7:1] [8:1] [9:1] [10:1]
>>>>> [11:1]
>>>>> [12:1] [13:1] [14:1] [15:1] [16:1] [17:1] [18:1] [19:1] [20:1] [21:1]
>>>>> [22:1] [23:1] [24:1] [25:2] [26:2] [27:2] [28:2] [29:2] [30:2] [31:2]
>>>>> [32:2] [33:2] [34:2] [35:2] [36:2] [37:2] [38:2] [39:2] [40:2] [41:2]
>>>>> [42:2] [43:2] [44:2] [45:2] [46:2] [47:2] [48:2] [49:2] [50:3] [51:3]
>>>>> [52:3] [53:3] [54:3] [55:3] [56:3] [57:3] [58:3]
>>>>> all entries correct
>>>>> PASS: testutilities
>>>>>
>>>>> Created serial ALUSimplexGrid<3,3> from macro grid file ''.
>>>>>
>>>>> = Total number of elements: 24576 (interior: -24576, overlap: 24576,
>>>>> ghost:
>>>>> 24576)
>>>>> = Number of elements (rank 0): 24576 (interior: -24576, overlap: 24576,
>>>>> ghost: 24576)
>>>>> = Smallest edge: 0.0625
>>>>> == setup result vector
>>>>> == setup result vector (0.001s)
>>>>> TIME STEP [Central Differences] 1 time (from): 0.0000e+00 dt:
>>>>> 1.2630e-02
>>>>> time (to): 1.2630e-02
>>>>> == prepare assembler
>>>>> == prepare assembler (7.9558e+00s)
>>>>> == apply solver
>>>>> === matrix setup 3.3215e+00 s
>>>>> === matrix assembly 4.7763e+00 s
>>>>> === residual assembly 3.6105e+00 s
>>>>> === CGSolver
>>>>> Iter Defect Rate
>>>>> 0.0000e+00 1.1463e+05
>>>>> 1.0000e+00 -nan -nan
>>>>> 2.0000e+00 -nan -nan
>>>>> 3.0000e+00 -nan -nan
>>>>> 4.0000e+00 -nan -nan
>>>>> 5.0000e+00 -nan -nan
>>>>> 6.0000e+00 -nan -nan
>>>>> 7.0000e+00 -nan -nan
>>>>> 8.0000e+00 -nan -nan
>>>>> 9.0000e+00 -nan -nan
>>>>> 1.0000e+01 -nan -nan
>>>>> 1.1000e+01 -nan -nan
>>>>> 1.2000e+01 -nan -nan
>>>>> 1.3000e+01 -nan -nan
>>>>> 1.4000e+01 -nan -nan
>>>>> 1.5000e+01 -nan -nan
>>>>> 1.6000e+01 -nan -nan
>>>>> 1.7000e+01 -nan -nan
>>>>> 1.8000e+01 -nan -nan
>>>>> 1.9000e+01 -nan -nan
>>>>> 2.0000e+01 -nan -nan
>>>>> ^Cmake[4]: *** [check-TESTS] Unterbrechung
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany