[Dune] Returning Geometries As Objects (again)

Martin Nolte nolte at mathematik.uni-freiburg.de
Mon Feb 6 10:07:27 CET 2012


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

-- 
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




More information about the Dune mailing list