David Wells [Thu, 3 Mar 2016 01:14:24 +0000 (20:14 -0500)]
Redo the logic in make_flux_sparsity_pattern.
As was reported on the mailing list, this function did not work in 1D
because it relied on setting the user flag on a face. This is not
possible because a 'face' in 1D ultimately resolves to the class
TriaAccessor<0, 1, 1>, which does not support user flags.
David Wells [Sun, 6 Mar 2016 21:27:41 +0000 (16:27 -0500)]
Remove repeated tests.
Since CompressedSparsityPattern and CompressedSetSparsityPattern are now
just typedefs for DynamicSparsityPattern, the only difference between
these (deleted) tests and the versions without '_x's in their names is
a small change in how we loop across the sparsity pattern: the diff
between the version with the '_x' and the version without was always, up
to different classes for the sparsity pattern, either
< for (CompressedSetSparsityPattern::iterator
< c = sp.begin(line); c!=sp.end(line); ++c)
< deallog << c->column() << " ";
---
> for (unsigned int c=0; c<sp.row_length(line); ++c)
> deallog << sp.column_number(line,c) << " ";
or
< for (CompressedSetSparsityPattern::iterator
< c = sp.block(block_row.first,col).begin(block_row.second);
< c!=sp.block(block_row.first,col).end(block_row.second); ++c)
< deallog << c->column()
---
> for (unsigned int c=0;
> c<sp.block(block_row.first,col).row_length(block_row.second);
> ++c)
> deallog << sp.block(block_row.first,col).column_number(block_row.second,c)
These test tangent directions for the simple case that the pull back
and push forward operations are the identity, or the identity on a
subspace (i.e., a projection).
Implement the tangent vector for the ChartManifold class.
Once one writes the formula down, it is quite clear what needs to happen and
how the code has to look like. The only slight difficulty is to treat periodicity
correctly.
These tests implement a ChartManifold with an identity pull-back/push-forward,
thereby creating a flat manifold. The pre-image that the pull-back projects
onto has a higher dimension, however, adding a tiny wrinkle to the system.
This adjusts a single number, which was previously output as 3.37 and is
now output as 3.38. The correct value is likely 3.375, so will be rounded to
one or the other on the whim of the compiler and the phase of the moon.
The correct approach to fixing this is likely to just output one extra digit
in the .output file. However, this increases the size of the output file by 1.4 MB
and that seems silly, so I will perpetuate the fragile behavior by simply changing
the one number and kicking the can for a proper approach down the road.
Remove deprecated functions with names like 'boundary_indicator'.
They had previously already been replaced by functions with name 'boundary_id', to
be consistent with the spelling for other attributes such as subdomain_id,
material_id, etc.
David Wells [Sun, 28 Feb 2016 21:08:06 +0000 (16:08 -0500)]
Avoid boost functions that don't work on BSDs.
As was noted in issue #2261, the function boost::math::iround cannot be
used on some BSD variants due to the following compilation error:
In file included from /root/workspace/dealii/source/lac/lapack_full_matrix.cc:25:
In file included from /usr/local/include/boost/math/special_functions/round.hpp:15:
In file included from /usr/local/include/boost/math/special_functions/fpclassify.hpp:19:
In file included from /usr/local/include/boost/math/special_functions/math_fwd.hpp:26:
In file included from /usr/local/include/boost/math/special_functions/detail/round_fwd.hpp:12:
/usr/local/include/boost/math/tools/promotion.hpp:141:10: error: static_assert failed
"Sorry, but this platform does not have sufficient long double support for the special functions to be reliably implemented."
BOOST_STATIC_ASSERT_MSG((0 == ::boost::is_same<type, long
double>::value),
"Sorry, but this platform does not have sufficient long double support for the special functions to be reliably implement ed.");
/usr/local/include/boost/static_assert.hpp:31:45: note: expanded from macro 'BOOST_STATIC_ASSERT_MSG'
Since we only use iround for clarity this is not hard to work around.
A note on the implementation: LAPACK functions can usually be run in two
different modes. In the first, they compute the optimal size of the work
array. In the second they actually execute the function. Therefore
all we need to do is make the work arrays one longer and we should still
get the same performance out of LAPACK without needing to worry about
any unforeseen roundoff issues.
projects / dealii.git / log