bangerth [Thu, 2 Jun 2011 18:05:50 +0000 (18:05 +0000)]
Fixed: If an FEValues object was kept around until after the triangulation include source doc
on which it works has been refined or coarsened, and is then reinitialized
with a cell from the refined triangulation, it could compute wrong results or
crash outright. This has now been fixed.
kronbichler [Thu, 2 Jun 2011 15:11:08 +0000 (15:11 +0000)]
In test for whether std::thread with std=c++0x really works: link with libpthread. It is needed for threaded code in general, and the flag will be added in the function DEAL_II_GET_THREAD_FLAGS (no need for change there).
bangerth [Mon, 30 May 2011 00:22:23 +0000 (00:22 +0000)]
<li> Changed: deal.II has a namespace std_cxx1x that was used to
import classes from BOOST that are part of the upcoming C++ 1x standard. On
the other hand, if your compiler supported a sufficiently large subset
of C++ 1x, we had code that simply did
@code
namespace std_cxx1x = std;
@endcode
allowing you to refer to everything that was part of the compiler's namespace
<code>std</code> under the alternative name. This turned out to be untenable
in connection to the changed outlined below for _1, _2, etc. Consequently,
if the compiler used supports C++ 1x, we now selectively import elements of the
compiler's namespace std into namespace std_cxx1x as well. This may lead to
incompatibilities if you are already using elements of the C++ 1x
standard by refering to them through the std_cxx1x namespace and these elements
are not on the list of selectively imported ones.
<br>
(Wolfgang Bangerth, 2011/05/29)
<li> Changed: Previously, placeholder arguments like _1, _2, etc that are used
in conjunction with the std_cxx1x::bind function could be referenced as if
they are part of the global namespace. This was achieved by importing the
corresponding elements of namespace std::placeholders into the global namespace
if your compiler supported this part of the C++ 1x standard, or otherwise using
the BOOST counterparts which are already in the global namespace. However,
this leads to a conflict if one has a C++ 1x enabled compiler (e.g. GCC 4.6)
<i>and</i> #includes certain BOOST headers, since the importation of symbols
into the global namespace now leads to ambiguous names. The only solution to
the problem is to not import names into the global namespace, but rather
import the names from either BOOST or namespace std into the deal.II namespace
std_cxx1x. The downside is that all code that uses _1, _2, etc needs to be
changed to use std_cxx1x::_1, std_cxx1x::_2, etc from now on.
<br>
(Wolfgang Bangerth, 2011/05/29)
</ol>
bangerth [Mon, 30 May 2011 00:16:00 +0000 (00:16 +0000)]
<li> Changed: deal.II has a namespace std_cxx1x that was used to
import classes from BOOST that are part of the upcoming C++ 1x standard. On
the other hand, if your compiler supported a sufficiently large subset
of C++ 1x, we had code that simply did
@code
namespace std_cxx1x = std;
@endcode
allowing you to refer to everything that was part of the compiler's namespace
<code>std</code> under the alternative name. This turned out to be untenable
in connection to the changed outlined below for _1, _2, etc. Consequently,
if the compiler used supports C++ 1x, we now selectively import elements of the
compiler's namespace std into namespace std_cxx1x as well. This may lead to
incompatibilities if you are already using elements of the C++ 1x
standard by refering to them through the std_cxx1x namespace and these elements
are not on the list of selectively imported ones.
<br>
(Wolfgang Bangerth, 2011/05/29)
<li> Changed: Previously, placeholder arguments like _1, _2, etc that are used
in conjunction with the std_cxx1x::bind function could be referenced as if
they are part of the global namespace. This was achieved by importing the
corresponding elements of namespace std::placeholders into the global namespace
if your compiler supported this part of the C++ 1x standard, or otherwise using
the BOOST counterparts which are already in the global namespace. However,
this leads to a conflict if one has a C++ 1x enabled compiler (e.g. GCC 4.6)
<i>and</i> #includes certain BOOST headers, since the importation of symbols
into the global namespace now leads to ambiguous names. The only solution to
the problem is to not import names into the global namespace, but rather
import the names from either BOOST or namespace std into the deal.II namespace
std_cxx1x. The downside is that all code that uses _1, _2, etc needs to be
changed to use std_cxx1x::_1, std_cxx1x::_2, etc from now on.
<br>
(Wolfgang Bangerth, 2011/05/29)
</ol>
bangerth [Mon, 23 May 2011 18:21:21 +0000 (18:21 +0000)]
Fail also in optimized mode if umfpack wasn't configured, rather than silently
producing wrong results. I've seen several people run into this already now...
bangerth [Tue, 17 May 2011 04:50:10 +0000 (04:50 +0000)]
Change the way we include files: Instead of doing #include <base/quadrature.h> we now want to do #include <deal.II/base/quadrature.h>. Keep the old way for backward compatibility.
bangerth [Tue, 17 May 2011 04:34:08 +0000 (04:34 +0000)]
Change the way we include files: Instead of doing #include <base/quadrature.h> we now want to do #include <deal.II/base/quadrature.h>. Keep the old way for backward compatibility.
bangerth [Tue, 17 May 2011 01:33:43 +0000 (01:33 +0000)]
Set the boost path to a directory that has its own version number. This has the advantage that we can now atomically add a new version of boost and delete the previous one, rather than doing the three-step we previously had (add new, delete old, move over new; or delete old and add new) that typically also confuses svn and leads to directories that are a mess.
bangerth [Mon, 9 May 2011 22:45:32 +0000 (22:45 +0000)]
Fix a problem where we look up elements in a matrix using the row map instead of the proper column map. This manifests only if the matrix is rectangular.