dune-testtools issueshttps://gitlab.dune-project.org/quality/dune-testtools/-/issues2021-05-10T14:19:44Zhttps://gitlab.dune-project.org/quality/dune-testtools/-/issues/140export generated tests on cmake2021-05-10T14:19:44ZSantiago Ospina De Los RĂossospinar@gmail.comexport generated tests on cmake### Description
The names of the generated tests are not available after calling `dune_add_system_test` and `add_system_test_per_target` . Because of this, one has two options to modify properties of the resulting tests:
* Hand-write t...### Description
The names of the generated tests are not available after calling `dune_add_system_test` and `add_system_test_per_target` . Because of this, one has two options to modify properties of the resulting tests:
* Hand-write the test names in CMake.
* Reconstruct all possible names from the mini file.
The shortcomings of the two options are obvious: A lot of duplicated code and information for something that `dune_add_system_test` and `add_system_test_per_target` compute anyways.
### Proposal
Two options arise here:
1. Export the list of tests into a return variable.
2. Attach tests to a property of the created targets `CREATED_TARGETS`.
The second case does not work on aliased targets (see !140). Thus, I would go for the first one. Any other opinions on this?https://gitlab.dune-project.org/quality/dune-testtools/-/issues/124Performance testing - Evaluate the deal.ii approach2017-10-15T13:05:33ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.dePerformance testing - Evaluate the deal.ii approachI talked to Timo Heister from the deal.ii team at SIAM CSE17 and he developed a new tackle on performance testing. We should have a look and decide whether we want to follow the same route.
Here is the summary:
* Instead of measuring ti...I talked to Timo Heister from the deal.ii team at SIAM CSE17 and he developed a new tackle on performance testing. We should have a look and decide whether we want to follow the same route.
Here is the summary:
* Instead of measuring times, which is a noisy, clunky procedure, they start measuring *instruction counts*.
* Instruction counts are deterministic, so they can be compared with very low tolerance values
* `valgrind --tool=callgrind` and some additional gymnastics do the job
* The code has to be instrumented with macros starting and stopping the measurements (the counting only really makes sense in innermost loops, like assembly, iterative solvers etc.)
* deal.ii uses this on a monthly basis with `git-bisect` (which is a nice alternative to CI)
* Timo has uploaded his code to [github](https://github.com/tjhei/callgrind-wrapper)