It has long annoyed me that when we print exception messages that were created
via ExcMessage, that the information is really duplicative. Example:
--------------------------------------------------------
An error occurred in line <710> of file <.../step-6.cc> in function
int main()
The violated condition was:
false
The name and call sequence of the exception was:
ExcMessage ("abc" "def")
Additional Information:
abcdef
Stacktrace:
-----------
#0 ./step-6: main
--------------------------------------------------------
Here, the text that comes after 'The name and call sequence...'
is duplicative with what comes after 'Additional Information:'.
This is specifically the case for ExcMessage errors because
there *everything* that constructs the 'Additional information'
will actually be also under 'The name and...' part.
This patch cleans this up by omitting the first of these two
parts if the error message was created via ExcMessage.
On my desktop, I have not installed numdiff yet, and these tests fail because
there are either differences in whitespace, or there is a trailing colon on
a line. Neither seem to bother numdiff, but they bother regular diff. Fix this
by checking in corrected versions of these output files.
Reimplement the 2d implementation of edge orientation.
The old implementation, written in 2003 by Mike Anderson, is quite concise
and of high quality. But it is not extensively documented, and is
unnecessarily hard to read because it uses different conventions for names
etc than we use in the rest of the library.
This reimplementation uses standard conventions, and it uses the language and
symbols of a paper about to be submitted that concisely describes the algorithms
and data structures used in this algorithm. As an additional benefit,
it uses the standard vertex ordering of cells rather than the
old-style ordering used in the existing algorithm.
Following the algorithm without understanding the graph theoretical context
of the problem may be difficult, but because it uses the same symbols as in
the paper, should be easy enough if you have the paper.
David Wells [Fri, 23 Sep 2016 22:26:11 +0000 (18:26 -0400)]
Make read_input print error messages again.
This commit partially restores the old behavior of read_input: this
function now prints out the exception message and returns
false. Previously this function printed all parsing error messages.
Some tests expected (see 79e0a380fb) read_input to raise a specific
exception message: those were fixed by calling parse_input instead.
David Wells [Fri, 16 Sep 2016 00:02:23 +0000 (20:02 -0400)]
Clarify error handling with PathSearch/read_input.
This commit keeps the same control flow if one tries to use this
function to write out default values to a file but gets rid of the
std::cerr messages (like the recent changes to read_input).
David Wells [Thu, 15 Sep 2016 12:19:47 +0000 (08:19 -0400)]
Use exceptions in ParameterHandler::scan_line.
This commit overhauls the private function ParameterHandler::scan_line
to no longer use a boolean error code to mark failure; instead the
function will raise one of four new exceptions to precisely indicate
what went wrong.
This change broke a large number of ParameterHandler tests that handled
parsing failures: I modified those to print the exception messages to
deallog.
Convert a comment from old-style vertex numbering to the way we currently do it.
The comment dates back to a time when we numbered vertices in quadrilaterals in counter-clockwise
sense. Fix this. While there, also re-wrap the comments.
David Wells [Thu, 15 Sep 2016 12:16:32 +0000 (08:16 -0400)]
Number continuation lines with their first line.
Since a continuation line in a parameter file consists of several lines
concatenated by trailing '\'s, use the first line number when printing
error messages to make things a bit clearer.
Parallelize the operation of compute_number_cache().
For these functions, the 3d version calls the 2d version which itself calls the
1d version. These operations can all run concurrently. All three include two
loops each over all cells/quads/lines, so there should be plenty to do to
amortize parallel execution.
The only tricky part is that the quad and hex functions accessed a variable
that was first set by the 1d function (number_cache.n_lines). This may now
no longer be available in time for the 2d/3d functions, and so they
need to compute this information themselves. This is cheap, fortunately.