Patrick Esser [Mon, 1 Feb 2016 19:42:22 +0000 (20:42 +0100)]
avoid warning about unused variable
According to the documentation of ArpackSolver::solve the first parameter is
unused. Do not give it a name in the definition to avoid unused variable
warnings.
Timo Heister [Tue, 26 Jan 2016 14:03:53 +0000 (15:03 +0100)]
improve PETSc sparse_matrix constructor error msg
If you construct a PETSc sparse matrix with invalid IndexSets for local
rows/columns, you only get a cryptic PETSc error code. This commit adds
a check in debug mode with a helpful error message.
Timo Heister [Tue, 26 Jan 2016 09:51:38 +0000 (10:51 +0100)]
fix metis partitioning with too many processors
If you have more processors than cells to partition, METIS will behave
in a weird and undesired way:
- at some point all subdomains land on a single processor
- METIS produces an error message "***Cannot bisect a graph with 0
vertices!"
David Wells [Fri, 22 Jan 2016 22:57:41 +0000 (17:57 -0500)]
Ignore surrounding whitespace if continuing lines.
This commit modifies the behavior present in both 23f306dfc5 (which did
not join lines if there was whitespace following a '\') and 0b962b1103 (which did not trim whitespace at the beginning of continued
lines).
We decided to remove whitespace at the beginning of a continued line
both because it was implemented that way in 23f306dfc5 (i.e., the 'fix'
in 0b962b1103 was wrong) and because it makes writing things
like (example provided by Alberto Sartori)
set Finite element space = FESystem[FE_Q(1)^d-\
FE_DGPMonomial(0)-\
FE_DGPMonomial(0)]
possible.
For the sake of posterity, here is part of the discussion (PR #2101)
which lead to the decision to remove trailing whitespace:
drwells:
I agree with @asartori86 that trailing whitespace is a mistake. I
suppose that I ultimately disagree because I think it is one that we
should 'forgive'. I think we are in agreement that we should join lines
if the last non-whitespace character is a `\`, then.
bangerth:
I agree, too, that trailing whitespace is a mistake. But there are two
options:
* Enforce it. In those cases you'll get an error about the next line not
being what the parser expects, while the file looks completely correct
visually. People will probably spend a long time rubbing their eyes
before they realize the problem.
* Forgive it, at the cost of not being able to support valid cases where
the user wants to have a backslash within the text, followed by only
spaces. That seems like a rare case to happen in practice, and also a
poor choice of syntax for whatever the user wanted to achieve.
From a usability standpoint, option 1 seems more appealing.
Timo Heister [Sun, 24 Jan 2016 17:05:13 +0000 (18:05 +0100)]
fix crash in petsc step-40
fix:
An error occurred in line <96> of file </ssd/deal-
git/source/lac/petsc_solver.cc> in function
void dealii::PETScWrappers::SolverBase::solve(const
dealii::PETScWrappers::MatrixBase&, dealii::PETScWrappers::VectorBase&,
const dealii::PETScWrappers::VectorBase&, const
dealii::PETScWrappers::PreconditionerBase&)
The violated condition was:
ierr == 0
The name and call sequence of the exception was:
ExcPETScError(ierr)
Additional Information:
An error with error number 80 occurred while calling a PETSc function
David Wells [Wed, 20 Jan 2016 18:46:56 +0000 (13:46 -0500)]
Prefer 'MeshType' to 'Container' and 'GridClass'.
These things are already described as meshes in the documentation and there is
already a class named Mesh (buried in grid_reordering_internal.h), so the best
name for the concept is MeshType.
FESystem has a number of functions that are called in the member initializer list
of the constructors. These are all static functions, of course, and don't access
any member variables.
This patch moves them ouf of the class altogether. This has the advantage that
it reduces the size of the .h file, and that it reduces the number of functions
exported by the shared libraries. Rather, these functions may as well live
inside an anonymous namespace in the .cc file.
There are no functional changes, nor anything that would be visible to the user.
The value of this argument was unused by this class, but several derived
classes passed something down anyway. Fix this by simply removing the argument.
Timo Heister [Sat, 23 Jan 2016 10:56:27 +0000 (11:56 +0100)]
fix test codim_one/error_estimator_02
fixes dealii/tests/codim_one/error_estimator_02.cc:75:9: warning: using
integer absolute value function 'abs' when argument is of floating point
type [-Wabsolute-value]
if (abs(p(1)-1.0)<1e-5)
Timo Heister [Thu, 21 Jan 2016 20:47:08 +0000 (15:47 -0500)]
doxygen: do not export duplicate functions
Since we started handing .cc files to doxygen, every explicit template
declaration of a function inside a .cc would generate another line for
that function in the class documentation (not clickable and before the
correct ones). We fix this by hiding undocumented functions. A quick
test shows, that even with this change, undocumented functions inside
classes defined in the .h will still be exported, because things like
@name groups and @ingroup count as "documentation".