Re: [deal.II] Assembling gradient jump at faces with FESystem

Thank you! It is good to know that the idea is to use FESystem, FEInterfaceVAlues and FEValuesExtractor together. I did not know this. However, our application is particular in that we actually do evaluate all the components to our FESystem at each interface. At the moment I do not have time to d

Re: [deal.II] Assembling gradient jump at faces with FESystem

If you use an FESystem, you typically don't need the evaluation done over all components. Instead, use an FEValuesExtractor and you should have everything available: https://www.dealii.org/current/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html I'd anything is wrong or missing, please open an

Re: [deal.II] Assembling gradient jump at faces with FESystem

Hello Wolfgang FEFaceValues has two types of functions voidget_function_values <> (const InputVector &fe_function, std::vector< typename InputVector::value_type > &values) const voidget_function_values <> (const InputVector &fe_function, std::vector< Vector <>< typename InputVector::va

Re: [deal.II] Assembling gradient jump at faces with FESystem

On 4/25/24 01:21, Nils Schween wrote: I think FEInterfaceValues is not implemented for FESystem. In my case, it actually just returned zeros without throwing an assertion. It is however more than two years ago I experimented with it. That would be a bug. We'd love to have a small test case th

Re: [deal.II] Assembling gradient jump at faces with FESystem

Thanks Nils you for sharing your experience. I may have to look into MeshWorker, but currently I am using WorkStream. I think with FEInterfaceValues, we can still compute the gradients and then compute the jumps, which seems easier to implement, than switching to MeshWorker. I will give that a

Re: [deal.II] Assembling gradient jump at faces with FESystem

I am sorry, I posted the wrong link. The correct link to Step 12b is https://dealii.org/developer/doxygen/deal.II/step_12b.html Best, Nils Nils Schween writes: > Dear Praveen, > > I think FEInterfaceValues is not implemented for FESystem. In my case, it > actually > just returned zeros without

Re: [deal.II] Assembling gradient jump at faces with FESystem

Dear Praveen, I think FEInterfaceValues is not implemented for FESystem. In my case, it actually just returned zeros without throwing an assertion. It is however more than two years ago I experimented with it. An alternative way to implement a face_worker without FEInterfaceValues can be found i

[deal.II] Assembling gradient jump at faces with FESystem

Hello In a continuous Galerkin method, I want to assemble terms involving jump in solution gradient and shape function gradient. For this, FEInterfacesValues seems like a good choice. But the function get_jump_in_function_gradients https://www.dealii.org/current/doxygen/deal.II/classFEInterfac

[deal.II] Assembling

Dear all, I am experiencing long time to computee the assembling and I would like to ask if this is common or there is something wrong with my implementation. My model is built in a similar way as step-29 and step-40 (using complex values ad solving with a direct solver using distributed paral

Re: [deal.II] Assembling explicit advection term independently

On 7/19/21 1:56 PM, Corbin Foucart wrote:

Re: [deal.II] Assembling explicit advection term independently

> That would be fantastic! There are some good resources linked to from > here, if > you're unsure about the process: > https://dealii.org/participate.html I'm ready to start working on this. I've read the participation FAQ, forked the repo, etc. This might be a basic question, but how shou

Re: [deal.II] Assembling explicit advection term independently

On 6/10/21 12:58 PM, Corbin Foucart wrote: To clarify, deal.II *did* throw some type of exception, I just wasn't able to interpret it and opted to use GDB instead; I'm a Python programmer and not a C++ expert by any stretch of the imagination :) Ah, I see. Yes, the error message is difficult

Re: [deal.II] Assembling explicit advection term independently

> I forgot that earlier. Could you come up with a small program that shows > the > segfault? We should have caught the wrong vector size via an assertion, > and > I'd like to add that assertion. > Certainly--please find attached. To clarify, deal.II *did* throw some type of exception, I j

Re: [deal.II] Assembling explicit advection term independently

On 6/10/21 7:10 AM, Wolfgang Bangerth wrote: Indeed,          std::vector> velocity_qpt_vals(n_face_qpts, Vector(dim));          fiv.get_fe_face_values(1).get_function_values(velocity_field, velocity_qpt_vals); accesses the values; the issue was I hadn't explicitly instantiated the Vector

Re: [deal.II] Assembling explicit advection term independently

On 6/10/21 2:07 AM, Corbin Foucart wrote: Indeed,         std::vector> velocity_qpt_vals(n_face_qpts, Vector(dim));         fiv.get_fe_face_values(1).get_function_values(velocity_field, velocity_qpt_vals); accesses the values; the issue was I hadn't explicitly instantiated the Vectors wit

Re: [deal.II] Assembling explicit advection term independently

Upon reading the documentation closer, I think I've found the way to access u^k (+/-) across each interface >- I can't seem to be able to access u^k(+) and u^k(-) using a >FEInterfaceValues fiv, because it's vector-valued >- this same procedure works fine for scalars. On any face,

Re: [deal.II] Assembling explicit advection term independently

Thanks for the detailed and helpful answer, Prof. Bangerth! Yes, I thought about it in the past few days and arrived at the same conclusion--that it does not make sense to represent the explicit advective term as a single finite element field. I settled on a separate RHSAssembler abstract base

Re: [deal.II] Assembling explicit advection term independently

On 6/8/21 3:33 AM, Corbin Foucart wrote: I've written generic, implicit HDG/DG solvers that solve a second-order diffusion type equation $\frac{du}{dt} - \nabla^2 u = f$ (where f is a generic DG finite element field). As I'm expanding the code to a set of projection methods, I'd like this $f$

[deal.II] Assembling explicit advection term independently

Hello all, I've written generic, implicit HDG/DG solvers that solve a second-order diffusion type equation $\frac{du}{dt} - \nabla^2 u = f$ (where f is a generic DG finite element field). As I'm expanding the code to a set of projection methods, I'd like this $f$ to represent an explicitly com

Re: [deal.II] Assembling sparse matrix from Matrix-free vmult with constrains

It looks like it was hidden bug inside my code. I've wrote the coarse grid direct solver for matrix-free operators. It ignores sparsity pattern and assembles the matrix by doing N vmults. The interface may be extended for optimalization. I think it might be an useful tool. Usage, for step-37: co

Re: [deal.II] Assembling sparse matrix from Matrix-free vmult with constrains

W dniu wtorek, 10 marca 2020 17:33:43 UTC+1 użytkownik Wolfgang Bangerth napisał: > > On 3/9/20 8:26 AM, Michał Wichrowski wrote: > > I've got matrix-free multigrid solver for Stokes problem. The main > > bottleneck is solution of coarse problem, so I tried to assemble the > > regular sparse

Re: [deal.II] Assembling sparse matrix from Matrix-free vmult with constrains

On 3/9/20 8:26 AM, Michał Wichrowski wrote: I've got matrix-free multigrid solver for Stokes problem. The main bottleneck is solution of coarse problem, so I tried to assemble the regular sparse matrix and use direct solver. Since the coarse problem is (relatively) small, I used vmults by unit

[deal.II] Assembling sparse matrix from Matrix-free vmult with constrains

Dear all, I've got matrix-free multigrid solver for Stokes problem. The main bottleneck is solution of coarse problem, so I tried to assemble the regular sparse matrix and use direct solver. Since the coarse problem is (relatively) small, I used vmults by unit vector to obtain columns of the m

[deal.II] assembling question

Dear all, I want to solve a system of equation for elasticity and I have an extra term in the my equations which is of the form -grad(b.u) here "b" is a vector of size DIM and "u" is the displacements with DIM components. I am a bit lost on how to express this with fe_values. Any help is ap

[deal.II] assembling individual block step 43

Hi all I am looking at step-43 using different method. I do a semi discretization in space and end up with an ode for the saturation and use different technique for time integration for the saturation. For this I will need to assemble the matrix H after solving for the velocity in the darcy sy

[deal.II] Assembling RHS coming from different equation with same triangulation but different dofhandler

Hello all, I am using deal.ii to solve two vector valued equations by FEM:- one for the velocity field "*v*" and the other for a vector field "*f*". I created different classes for solving these two equations separately. I am using same parallel::distributed::triangulation for both the equation