Luca Heltai [Thu, 16 Oct 2014 19:30:30 +0000 (21:30 +0200)]
Fixed also last comments by @bangerth, using std::tuple where appropriate. We split also some of the functions in utilities.h into two different parts, one of which is transparent to the underlying OpenCASCADE structures.
Andrea Mola [Tue, 14 Oct 2014 15:45:03 +0000 (17:45 +0200)]
step-54 is now completed (it only needs comments). three different projectors have now been created in boundary_lib: normal, directional and normal_to_mesh. to adjust tolerances, a new method retrieving tolerances from a shape has been added
Fixed indentation.
fixed some problems with residual calls to Pnt() (now Point()) and axis_ intersection() (now line_intersection()) functions in boundary_lib. files coarse_sphere and coarse_circle removed from step-54 directory. also parameters.prm has been removed, and n_cycles value is asigned in an hard coded way
all input and output files have been converted to .vtk
added comments to step-54.cc
fixed all the notes by luca exept for that on the closest point function
amola [Thu, 2 Oct 2014 10:41:10 +0000 (12:41 +0200)]
an attempt to improve opencascade directional projection with informations on local normal
an other attempt to improve opencascade directional projection with informations on local normal
version with directional projection depending on normals of surrounding points is now working. to this end, a method has been added to utilities, to return differential forms (normal and mean curvature) along with closest point on the CAD surface
trying to improve the directional projection
improved cell refinement on CAD with directional projector, by adding a separated treatment for case with 2 or 8 surrounding points (edge or cell refinement). the 2 points case uses some infos about the surface normal, the 8 case comes up with an approximated cell normal
This patch uses signals to determine whether a current iterate
satisfies the convergence criterion. Currently, the only slot that
is connected to a signal is the SolverControl::check() function,
but users will be able to connect different slots there as well,
closely monitoring the convergence process.
Timo Heister [Thu, 23 Oct 2014 11:05:03 +0000 (07:05 -0400)]
Merge pull request #206 from bangerth/remove-faulty-test
The test verifies that it doesn't matter whether we first call
DoFHandler::distribute_dofs() and then DoFHandler::distribute_mg_dofs(),
or the other way around. But we have recently changed the behavior
to require exactly this order, so part of the test is no longer of interest.
The test verifies that it doesn't matter whether we first call
DoFHandler::distribute_dofs() and then DoFHandler::distribute_mg_dofs(),
or the other way around. But we have recently changed the behavior
to require exactly this order, so this part of the test is no longer of interest.
Timo Heister [Wed, 22 Oct 2014 20:30:45 +0000 (16:30 -0400)]
Merge pull request #207 from bangerth/fix-test
We have recently allowed that one can set a vector to zero, even if it has
ghost elements. But this test verified that we throw an exception in this
case. Remove this one test.
We have recently allowed that one can set a vector to zero, even if it has
ghost elements. But this test verified that we throw an exception in this
case. Remove this one test.
Guido Kanschat [Fri, 17 Oct 2014 08:54:07 +0000 (10:54 +0200)]
Merge pull request #202 from kronbichler/master
Improved AVX-512 vectorization code path. The original version of the AVX-512 vectorization (DEAL_II_VECTORIZATION_LEVEL = 3) was not properly tested. When I did some tests with gcc, it turned out that I had to fix a few issues. Now it compiles fine and the generated assembler code looks good, but there is no hardware out to test it yet.
The original version of the AVX-512 vectorization (DEAL_II_VECTORIZATION_LEVEL = 3) was not properly tested. When I did some tests with gcc, it turned out that I had to fix a few issues. Now it compiles fine and the generated assembler code looks good, but there is no hardware out to test it yet.
I also improved some code comments.
Timo Heister [Thu, 9 Oct 2014 14:17:38 +0000 (10:17 -0400)]
Check in DoFHandler::renumber_dofs() that DoFs are distributed
- This adds several Asserts to check that DoFs are distributed
before calling renumber_dofs() for active or level DoFs.
- Note that we now also require that you call distribute_dofs()
before distribute_mg_dofs().
- Updated documentation.
Since these functions were moved to the header file, we no longer
need to explicitly instantiate them since every .cc file that uses
them will generate an instantiation where necessary.
Vijay Mahadevan [Thu, 9 Oct 2014 16:47:34 +0000 (11:47 -0500)]
Making the next_free_pair_object and next_free_single_object as inline functions.
Also contains a patch from Wolfgang with changes to the instantiation file.
Background: In release mode, GNU-4.8.x (OSX) seem to optimize away the calls when
specializing the template functions and then symbol definitions seem to be different
between debug and optimized modes. This causes undefined linkage for release mode.
Matthias Maier [Wed, 1 Oct 2014 13:08:18 +0000 (15:08 +0200)]
CMake: Remove test DEAL_II_HAVE_CXX11_ICCBOOSTSIGNALSBUG_OK
We cannot sanely test for this regression prior to boost setup. And after
boost setup it is incredibly ugly to do so because DEAL_II_WITH_STDCXX11 is
already processed.
CMake: Only use internal boost header (if available) for regression check
Fix a regression where a test for an icc regression in
check_01_cxx_features.cmake incorrectly used a generic <boost/signals2/...>
include. Such an include file doesn't have to be available at this early
point in the configuration run. User internal boost headers (if available)
instead - otherwise just test nothing.
If we avoid calling GlobalAssemble when copying from an Epetra_FECrsMatrix that uses a
non-local matrix (enabled for Trilinos 11.9 and greater), we do not run into some bad
code in Trilinos causing a segfault. At this point of the code, it is enough if we only
call FillComplete because there should be no communication after all.
CMake: Bugfix: Correctly detect unsupported flags in case of clang
The clang compiler frontend is very conservative in not issuing an error
for unsupported compile flags but that are valid for gcc. Therefore, also
supply "-Werror" for the clang compiler in all 'ENABLE_IF_SUPPORTED' tests.