- Jun 25, 2014
-
-
Steffen Müthing authored
-
Steffen Müthing authored
-
- Jun 20, 2014
-
-
Ansgar Burchardt authored
-
Steffen Müthing authored
I messed up when editing the release notes, creating a Frankenstein text made up of bits that pertained to 1.1 and to 2.0. Replace that mess with a correct text.
-
- Jun 19, 2014
-
-
Steffen Müthing authored
Also remove the notice to use the release branch of the core modules, as DUNE 2.3.1 has been released now.
-
Steffen Müthing authored
PDELab doesn't work correctly with the 2.3.0 release of the core modules, so we better reflect that in the dependency requirements stated in the dune.module file.
-
Steffen Müthing authored
-
Steffen Müthing authored
-
Steffen Müthing authored
VariableMonomFEM for a simplex ALUGrid was initialized with the default constructor, which assumes a hexahedral grid, creating subtle inconsistencies in the ordering data structures. These only caused a test failure when compiled with assertions, which is why the problem went unnoticed for that long. Fixed by explicitly calling the correct constructor. Thanks to Christoph Grüninger for reporting the original issue.
-
Steffen Müthing authored
The updated hint on where to find examples for the boilerplate layer in boilerplate/pdelab.hh unfortunately contained the character sequence "/*" as part of the path to the examples, triggering a compiler warning about nested comments. Reworded to avoid the problematic path name.
-
- Jun 18, 2014
-
-
Steffen Müthing authored
VariableMonomFEM only supports a single GeometryType for grid cells, even though the fact that you can pass in an arbitrary mapper seems to suggest otherwise; the returned finite elements are only correct for the GeometryType passed to the FEM's constructor or the default GeometryType, which is a cube. Unfortunately, the FEM did not check whether the grid cell passed to find() actually had the correct GeometryType, leading to weird, subtle bugs in the ordering infrastructure later on. This was noticed by Christoph Grüninger, who ran testordering with assertions turned on, promptly tripping over a check to make sure that the current GeometryType is actually in use with the Ordering. Thanks for reporting, Christoph! This was really nasty to debug - it's fixed now by checking the GeometryType in find(), but it's still possible to create a wrong FEM for a given grid. After the release, we should change the FEM to simply take the GridView in its constructor and automate the whole process, maybe even adding support for different GeometryTypes. But for now, the quick fix will have to do.
-
Steffen Müthing authored
Extend PDELab with required support code to allow parallel computations in MultiDomain again. * feature/fix-parallel-multidomain: [Communication] Add support for communicating entities with partially inconsistent DOF counts [Communication] Add PolymorphicBufferWrapper to allow sending heterogeneous data in a single grid communication [Communication] Change DataHandleProvider and EntityIndexCache to keep per-leaf size information
-
Christoph Grüninger authored
The symbolic link in fem is not included, instead the folder grids is included a second time. Maybe there is a better solution.
-
Markus Blatt authored
This is thorrowly needed as there is a lack of source code documentation.
-
Steffen Müthing authored
[Cleanup] Remove unused typedefs and variables in constraints-free implementation of scatter_jacobian()
-
Steffen Müthing authored
This patch is required for supporting parallel computations with MultiDomain, where it can be possible for entities of codim > 0 to have different numbers of DOFs attached to them on different MPI ranks. The problem arises if an entity belongs to a subdomain, but there is no associated cell that also belongs to the subdomain on one MPI rank. In that case, the GridFunctionSpace will not now about this membership and thus consider the subspace assoicated with the subdomain to be empty, causing a crash when too much / too few data is sent / received. In order to fix this problem, there is now a new method sendLeafSizes() on the DataHandleProvider. If that method returns true, the generic data handle infrastructure will automatically communicate per-LeafOrdering sizes and only enforce sizes to be consistent for those leaf orderings. By default, this method always returns false, so most existing applications should not even notice the difference between the old and the new implementation. Please note that this change requires wrapping the message buffer passed in by the grid, as we now have to send heterogeneous data (e.g. sizes and doubles) over the same data handle. This is not supported by the standard data handles, so we use a DataHandle for char and marshal everything to a simple byte stream. However, these changes only apply to per-DOF communication. Per-entity communication does not require the additional overhead, as there is no ambiguity as to the subdomain membership of entities at the grid level.
-
Steffen Müthing authored
[Communication] Add PolymorphicBufferWrapper to allow sending heterogeneous data in a single grid communication PolymorphicBufferWrapper takes a grid MessageBuffer for data of type char and allows you to write/read data with arbitrary POD types.
-
Steffen Müthing authored
DataHandleProvider and EntityIndexCache cooperate using an informal protocol to calculate the per-entity DOF count. The DataHandleProvider obtains this information by visiting the leaves of the Ordering tree and accumulating the size information at those leaf Orderings. While the accumulated total is sufficient in the standard PDELab case, MultiDomain requires the per-leaf information for certain combinations of subdomain and processor boundaries, in particular if a subdomain exists on the cells on one side of the processor boundary but not on the other and the user has chosen a discretization with DOFs on entities with codim > 0. In this case, the per-entity size information on the different ranks can become inconsistent. This patch changes the accumulation process to store the per-leaf sizes in an array that is exported via the new method offsets() of the EntityIndexCache.
-
- Jun 12, 2014
-
-
Steffen Müthing authored
-
Steffen Müthing authored
-
Christoph Grüninger authored
-
Christoph Grüninger authored
Fixes configure warnings.
-
Christoph Grüninger authored
-
Christoph Grüninger authored
-
Christoph Grüninger authored
Ignore Eigen backend headers if Eigen not found.
-
- Jun 11, 2014
-
-
Steffen Müthing authored
Due to that functionality extension, I also renamed the test to reflect the fact that multiple values of k are tested.
-
Steffen Müthing authored
The PkFEM in 2D uses an array of 6 different FE variants for the different possible permutations of the vertex indices. When looking up a finite element, the subindices of the vertices are retrieved and compressed to the range [0,5] depending on their permutation state. Unfortunately, the code doing uses the inverse of the correct statement for the relative ordering for vertices 1 and 2. Fixed - thanks to Pavel for noticing!
-
- Jun 07, 2014
-
-
Steffen Müthing authored
-
Steffen Müthing authored
-
Steffen Müthing authored
-
Steffen Müthing authored
Looks like I forgot to add that file to both build systems. Fixed.
-
Steffen Müthing authored
-
Steffen Müthing authored
-
- Jun 06, 2014
-
-
Steffen Müthing authored
[GridFunctionSpace] Store constraints engine as shared_ptr and allow passing a shared_ptr to the constructor For some weird reason, when the GridFunctionSpace was modified to store the FiniteElementMap as a shared_ptr and potentially assume ownership of it, the constraints engine did not receive the same treatment. Usually, this is not a problem, because most current constraints engine do not carry any state, so the underlying variable can point at garbage without any harm, but that is of course not a solution. This patch changes the GridFunctionSpace to - use a shared_ptr for storing the constraints engine - add new constructors that allow passing in a shared_ptr to a constraints engine - export the new shared_ptr via a new method constraintsStorage() - get rid of the weird defaultce member - if we don't get a constraints object, we can just allocate one and store it in our internal shared_ptr
-
Steffen Müthing authored
We might want to update the underlying GridView if we want the GridFunctionSpace to survive operations like adaptivity and / or load balancing.
-
- Jun 05, 2014
-
-
Steffen Müthing authored
There were both leftovers of removed headers and missing new headers. This patch fixes FS#1472. Thanks to Markus Blatt for reporting this.
-
- Jun 04, 2014
-
-
Steffen Müthing authored
-
Steffen Müthing authored
-
Steffen Müthing authored
-
Steffen Müthing authored
-