Skip to content

Add grad for LagrangeRefSpace{T,1,3} #187

Open

Description

@sbadrian

Currently, it provides the function value and the curl. However, for discretization a Laplacian, the gradient would be needed, too.

I think that simply adding the gradient to the tuple shouldn't be a problem, should it?

Activity

  1. krcools commented on Feb 4, 2026

    @krcools
    Owner

    The ad-hoc supply of derivatives has always bothered me. In the Mawell single layer it makes complete sense to have both the function value and the divergence. For now, I make the Laplacian like this:

    Id = BEAST.Identity()
    grad = BEAST.gradient
    
    @hilbertspace u
    @hilbertspace v
    
    a = @varform Id[grad(v), grad(u)]
    
    X = lagrangec0d1(Gamma)
    A = assemble(a, X, X)

    Moving forward we have to choose probabely one of:

    • Complementing evaluation of shape functions with a maximal set of derivatives
    • Supplying multiple evaluation functions for shape functions and let dispatch depend on the type of operator
    • Solely depend on the above method. This opens new questions like what local space should the derivative be expressed in? Is there always a straightforward minimal choice for this?
    • The approach @PaulOlyslager takes (see the section on composite operators in the dev version of the docs)
    • Overload assembly for a LaplacianOperator to first take the gradient of test and trial functions and off-load the heavy lifting to the assembly of the identity (essentially automating the procedure above).
  2. sbadrian commented on Feb 4, 2026

    @sbadrian
    ContributorAuthor

    Complementing evaluation of shape functions with a maximal set of derivatives

    I guess this could be done as quick solution at the price of a performance penalty. I am not sure how many function spaces are affected that would need several derivatives as does the LagrangeRefSpace{T,1,3}

    Supplying multiple evaluation functions for shape functions and let dispatch depend on the type of operator
    Should be also fairly easy to move to this, shouldn't it? Probably even code duplication could be avoided using nested (inline) functions?

    Solely depend on the above method. This opens new questions like what local space should the derivative be expressed in? Is there always a straightforward minimal choice for this?

    You mean computing the, for example, gradient of a function space as in your code snippet? I feel it somehow contradicts the logic of operators and handling "mixed" discretizations seems difficult.

    The approach @PaulOlyslager takes (see the section on composite operators in the dev version of the docs)
    What specifically do you have in mind?

    I guess it would be interesting to also find a solution for linear combinations of operators so that it is automatically deduced what needs to be computed and it is only computed once for all operators. This seems, however, more difficult to attain quickly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions