[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