-
Notifications
You must be signed in to change notification settings - Fork 471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for input: Laplace-based linear and bilinear integrators #4238
Comments
Implementation effort can be reduced by using the |
Is there a need for a |
This sounds great to me!
I'm not sure we really need to target exact integration of Laplacian terms, even if that is possible in some cases. I think using the lowest quadrature order (e.g., ignoring the transformation order) that works robustly is best. It is hard to test all possible use cases for "works robustly", so go with what you find in your tests or what is recommended in the literature, if there are such recommendations. How do you plan to compute the Laplacian on a general element? Do you plan to use exact computation at quadrature points using the Hessian and the Jacobian of the transformation? An approximate alternative that only requires the Jacobian is to project the gradient (e.g. using nodal interpolation) back into the same FE space and then take the divergence. I think @bslazarov and/or @vladotomov wanted to try something like that but I'm not 100% certain. |
The Laplacian/Hessian is already implemented - in principle. The Laplacian is compute as the trace of the Hessian which sounds expensive but is the easiest way to have the correct effect of the mapping . There is a check of to see if the Transformation is affine, |
@michi002 My apologies, I pushed it to an other local repo. I will push it tomorrow, unfortunately I can not ssh into my machine due to overly zealous security... |
@IdoAkkerman thank you. I had a look on your commit. |
@michi002 Convection-diffusion only requires the scalar implementation. However, the SUPG/PSPG terms for Stokes/Navier-Stokes involve terms where the velocity and pressure spaces are combined, or is there a way to bypass that? Regarding, the term you are interested in, that can be obtained by by using the 4th term, viz. |
@IdoAkkerman Concerning the coefficient: |
Implementing Do you have a clear application in mind? |
@IdoAkkerman I do not know if it is an important case for the general userbase, but I think a mixed version ( |
So you are converting Why not test with |
@IdoAkkerman If you are really interested why we do that, you can look at our preprint: https://arxiv.org/abs/2404.10350 I hope that answers your question. |
@IdoAkkerman I have now implemented a mixed version of your
I would like to test my routine, by projection the laplacian of a |
@michi002 Thanks for the input, I was to lazy to change the name. I think the functionality is okay, but you are right for a final commit this needs to be rectified. |
@michi002 Sorry you are correct. I did make a typo! Thanks!! Perhaps I am also mistaken about the mixed stuff, but you might need to convince me... |
@IdoAkkerman |
I would not be surprised if My guess is that some of the mixed implementations have become defacto deprecated. |
@IdoAkkerman |
The |
@IdoAkkerman |
I am very interested in this integrator (I would like to use it as a I have not yet completely ruled out implementation issues or derivation issues on my side, but one thing I noticed is that this integrator seems to produce very large matrix entries compared to, for example, the
Furthermore, I modified example 0 to use the I added my code as attachment: ex0_biharmonic.zip |
@michi002 Apologies, my own workflows are confusing me (I had only pushed to my own local repo). |
@Rickbude Good to know there is more interest.
|
@IdoAkkerman thanks for your reply! The element scaling the way it does due to it being equivalent to the 2nd derivative is so logical, I don't know why this did not occur to me... But thanks for confirming this is correct behavior nonetheless. I can now scratch of a suspect for why my boundary condition might not be working.. I realize that the |
@Rickbude Perhaps look in the |
Now I have the latest commit. However I think there was maybe some mismatch between somewhere.
and this Nevertheless I looked at your routine for the laplace integrator. First there is again the same bug with the shape instead of the laplacian. Further I think there might be a problem, as we calculate the laplacian of the trial function. However the assembly routine takes the transformation of the test-function. I am not sure if this works, if I take for example the L2 space of piecewise constants over the mesh. At least in some test I had problems. This is why I implemented it via the adjoint operator in the first place. Maybe the transformation is the same also in e.g. the L2 case? |
@michi002 My apologies the branch is under development... I am working on several things, and I did not consider other users. I removed the I am not seeing the bug, its looks fine to me. I do not understand the quote:
The transformations are taken via the |
d085026 removed a few cpp files from |
@IdoAkkerman ok. The bug seems to be fixed in your new version (in the old version, there was a typo with the shape instead of the laplacian). But I also have the same compilation issues as @Rickbude.
Yes. The transformation is its own thing. But is it still correct, if I take for example piecewise constants so the |
I am interested in implementing
LinearFormIntegrator
andBilinearFormIntegrator
involving the Laplacian.Any heads up on potential conflicting or duplicate effort is highly appreciated.
Any tips or warning for pitfalls are also welcome.
Last but not least, if I am skipping some useful functionality for other use cases please let me know.
My personal interest for these terms are stabilized methods. So first would be the scalar convection-diffusion case which would require the following:
Coefficient f
Coefficient q
VectorCoefficient a
Coefficient q
VectorCoefficient a
Coefficient q
Next would be vector based case, such as navier-stokes. Which would require the same as above but all the scalar shape functions become vector shape function. The coefficients will in principle be of Matrix form, probably more efficient routines are available for scalar or vector (= diagonal of matrix). I will consider implementing all three.
To enable the pressure and PSPG terms two mixed terms are required.
MatrixCoefficient Q
MatrixCoefficient Q
Hessian based integrators will not be considered in this PR.
The text was updated successfully, but these errors were encountered: