fdrmrc / polydeal Goto Github PK
View Code? Open in Web Editor NEWC++ implementation of Polygonal Discontinuous Galerkin method within the deal.II Finite Element library.
Home Page: https://fdrmrc.github.io/Polydeal/
License: Other
C++ implementation of Polygonal Discontinuous Galerkin method within the deal.II Finite Element library.
Home Page: https://fdrmrc.github.io/Polydeal/
License: Other
In order to provide several app/examples that can be linked against polydeal
and run without changing examples/CMakeLists.txt
manually.
Assert(dim == 2 && spacedim == 2, ExcNotImplemented()); //@todo Not working in 3D
AgglomerationHandler
should not be responsible for the initialization and setup of FEValues-like objects, in the same way as DoFHandler
does not evaluate any basis function. A dedicated class, with name something along the lines of FEAggloValues
or FEPolyValues,
should be the one that calls these methods:
AgglomerationHandler<dim,spacedim>::reinit(polytope)
,AgglomerationHandler<dim,spacedim>::reinit(polytope,face)
Its constructor should be identical to the one of FEValuesBase with the twist that instead of using a DoFHandler, and AgglomerationHandler
is working under the hood.
This paper https://arxiv.org/abs/1906.01627 provides interesting quality metrics for polygons. We should really compute some of them to assess the goodness of the implementation. In particular, I am planning to compute uniformity factor and circle_ratio for a general 2D polygon.
Make sure it compiles against latest version of deal.II, and run all tests.
After #106, a new and more compact way to agglomerate elements is available. We should be consistent and use it everywhere.
The class CellsAgglomerator
should be used. Moreover, it allows extracting the polytopal hierarchy in user codes.
Sanity checks fail because basis functions involved in the jump terms are evaluated at wrong quadrature points. Indeed, printing explicitely the evaluation points seen from the two cells sharing a same face
// print real qpoints from current_cell
qpoints:
0.0140877 0.125
0.0625 0.125
0.110912 0.125
// print real qpoints from neighboring cell
qpoints :
0.125 0.139088
0.125 0.1875
0.125 0.235912
I'm working on that.
In several examples we use quadrature rules of order
I've verified locally that decreasing the order (say to
While the current status works, there is a major design aspect which has to be considered.
We should not let the user know explicitely that only one deal.II cell (the "master" one) of an agglomerate carries the DoFs. In our assembly routines, we effectively loop through all the master cells (i.e. all the polygons), but they are by all means simple deal.II cells. This continuous identification between polyongs and master cells is certainly confusing from a user's perspective.
The cleanest solution would be to design an Accessors and Iterators classes in the spirit of the Particles
namespace from deal.II (https://www.dealii.org/current/doxygen/deal.II/namespaceParticles.html).
Check things work also in 3D.
With bilinear DG elements (i.e. DGQ(1)) the L2 error is not zero for the linear solution 1e-5
.
I'm debugging quadrature points on faces and associated normals for this minimal example but they look okay.
Given the solution u
defined on the BBOxes of each polytope, interpolate in order to visualize it.
Whenever we have neighboring elements sharing lots of background faces we enumerate all of them and store this information.
reinit(polytope, f)
for every face index f
, which implies many calls. In practice, that means we create and reinit an object of type FEImmersedSurfaceValues
(plus the related quadratures and normals needed by ImmersedSurfaceQuadrature)
for every (background) face.Consider the following mesh made by two elements, and assume that K1 shares with K2 many straight little faces. With the latter approach:
- - - - - - - - - - - - - -
| | |
| K1 | K2 |
- - - - - - - - - - - - - -
Many tests will fail due to diffs in the golden output.
Thus, an FEImmersedSurfaceValues object can, typically, not be reused for different cells.
This suggests that it's better to group together these faces, since the cell
we have now is conceptually just one polygonal cell.
After #80, the only missing step in order to provide a full working example is to provide a way to interpolate the (distributed) solution vector on the fine (distributed) triangulation, i.e. to implemente a parallel version of AgglomerationHandler<dim, spacedim>::setup_output_interpolation_matrix()
, the rectangular matrix that provides the action of the nodal interpolant on the finer finite element space.
I already have a working version, but it needs to be polished in order to be used both in serial and parallel programs.
If we interpret each cell made by one element as a polygon itself, quantites like weights are scaled with the jacobian of the mapping associated to the bounding box and then multiplied back. This in necessary in order to conform with deal.II structures.
Consider the test of measuring the volume of a domain
The simplest solution is to just use classical FEValues
objects if we know this cell is made by just one element. I can confirm this give results that are equal up to machine precision
Constructor should take a Cached tria.
The minimal change in #64 highlights something serious. In order to map points back from real to unit space, we should not go through the many calls of the Mapping
class, but just use BoundingBox::real_to_unit()
. Surprisingly, this increased the computational times.
The reason is that the std::vector
of bounding boxes is long as the number of elements of the underlying triangulation. This should really be contiguous.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.