[Dune] Returning Geometries As Objects (again)

[Oliver Sander]

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
>