Daniel Bauer (205ef895) at 11 Jun 11:36
Merge branch 'bauerd/isl' into 'backend-rework'
... and 3 more commits
Daniel Bauer (8327805d) at 11 Jun 11:23
Daniel Bauer (8327805d) at 11 Jun 09:27
reviewer feedback
Of course you thought this through. Sorry for dumping my thoughts without thinking more about it first ^^.
The issue I had in mind was #265.
I am suspecting that this is a hot fix for a specific issue. IMO a proper fix should be implemented there. The old implementation allowed to skip communication in certain situations. I do not know if we rely on / exploit the old behavior anywhere.
I am not against this change, just wanted to mention that either variant has pros and cons.
Should we do the same for Nedelec?
In his monograph "Multigrid Methods for Finite Elements" (https://doi.org/10.1007/978-94-015-8527-9) Shaidurov presents some interesting quadrature rules. The idea is to place quadrature points on the boundary of elements, if possible. The integrand must thus be only evaluated once for all adjacent elements.
For example, first order polynomials (P1) can be integrated with one point at a tetrahedron's barycenter, i.e. 1 function evaluation per element. It can also be integrated using one point at each node. Assuming that each node is adjacent to 24 cells, this results in 1/6 function evaluations per element. On the flip side, four evaluations must be summed on each element (instead of just one). If function evaluations are expensive, this most definitely is not very significant.
The reference lists 5 rules on triangles and tetrahedrons, each. The rules with the most points can integrate P4 space exactly (with just one node in the volume).
That is probably the best solution. If nothing else works, you can of course swap those if conditions.
Implemented missing evaluation of blending maps and integrated it into trafo_ref_to_physical()
to be used in forms.
This can never be true because ExternalMap.supported_geometries
returns an empty list.
Up until now, we apparently have not tested translation variant expressions in forms. For affine domain transformations (aka no blending) the implementation falsely assumed that the entire form is translation invariant. But this is of course not true. It only applies to the Jacobian.
The downside of this simple fix is that I guess it will produce unused variables. But let's see.
Closes #17 (closed)?
Daniel Bauer (091b2497) at 03 Jun 18:07
simplify code
Daniel Bauer (f4ddc15e) at 03 Jun 17:44
fix typo and improve docstring
Hi,
working on issue #192 of HyTeG I tried to regenerate all forms in HyTeG using the generate_all_hyteg_forms.py
script. Doing so I ran into the following problems:
n1e1_linear_form_affine_q6
inside src/hyteg/forms/form_hyteg_generated
on HyTeG's master (or main, if you prefer) is not part of HFG's master, but can only be found on a branch.p2_mass_blending_q5
.p2_full_stokesvar_affine_q3
.Now all of these are not really show-stoppers, but IMHO we should consider, how we want to address the question of interplay between HFG and HyTeG. Should it be possible to regenerate all forms by the press of a button, or not? If not, can we at least add command line options to specify the quadrature order on-the-fly? Or maybe we need a specialised script or "database" of the forms we need in HyTeG and keep that up-to-date?
Cheers
Marcus
This issue shall collect discussions around the implementation of vector function spaces and their integration into the full operator generation.
Issues and open questions:
TensorialVectorFunctionSpace
already exists. We may want to streamline the members/methods if necessary.TensorialVectorFunctionSpace
implements
V_i = \{ q(\cdot) {\bf e}_i | ({e}_i)_j = \delta_{ij}, q \in P^1(\Omega), 1 \leq j \leq d \}
which is just a part of the full vectorial space (we would like to have V = V_1 + \dots + V_d
) - thanks @wagnandr for explaining that to me :)component
member?VectorFunction
types in the FOG.\nabla u \cdot \nabla v
could be replaced by the vector valued version \nabla u : \nabla v
, since the double contraction :
just automatically collapses to the product \cdot
in the scalar case. This may allow us to remove forms_vectorial.py
or rather replace the contents of forms.py
with the contents of forms_vectorial.py
.I think other things require cleanup in the forms as well, e.g., tabulations. I still wonder if we can come up with a more convenient way of defining these forms.