Re: [deal.II] fixing one component of solution to the same value

Hello Daniel, Thank you so much for pointing this out. I have been stuck here for a long time and could not figure out. I understood that the sparsity pattern class was some how failing to know that space needs to be allocated for coupling with *the_dof even though it was not locally

Re: [deal.II] Custom shapeset questions

Lukas, for solving the (ideal) MHD equations, I would like to implement two custom shapesets: By "shapeset" do you mean "set of shape functions"? * one for the flow part, completely discontinuous, scalar FE space, analogy to FE_DGQ, but based on Taylor expansion in the cell center

Re: [deal.II] Custom shapeset questions

Hello Lukas You may want to look up this thread https://groups.google.com/d/msg/dealii/RbcPNELLHZA/eZxRYjzlVXIJ I started implementing Taylor basis as FE_DGT class some years back but did not complete it, see code here https://bitbucket.org/cpraveen/deal_ii/src/master/fe_dgt/?at=master

Re: [deal.II] fixing one component of solution to the same value

Hello Daniel, Thanks for the reply. I am actually doing what you suggested. Please look at the updated code that I had posted earlier and works with deal.ii 8.5. These lines are already there in the code. Surprisingly, such an error is still showing up. I am not sure what is still causing

Re: [deal.II] Re: imposing boundary conditions for a three-fields formulation

Thank you Daniel and Jean-Paul. Indeed I am using PETSc wrappers and the columns manipulation is not active. And indeed if I run a little less academic example, i.e. more than a single element, CG converges. Just to know, in case of a single element CG does not, likely this is not unexpected. The

Re: [deal.II] Re: imposing boundary conditions for a three-fields formulation

Alberto, Now I understand your concern. The boolean flag that is passed as the final > parameter to MatrixTools::apply_boundary_values > > > determines whether column elimination is

Re: [deal.II] fixing one component of solution to the same value

Rajat, What is happening here is that you try to create constraints that include DoFs that are not element of the IndexSet you provided to the DynamicSparsityPattern object. Therefore, all the entries for your "fixed" DoF are ignored if it is not already part of the locally relevant DoFs. Have

Re: [deal.II] Call for Codes

Hi Toby, That sentence is not well written. I should have written I ocassionally scan GitHub to learn what features of deal.II people are using in their own projects. For example, we will not break anyone's codes by removing the PETSc serial vector classes: no one is using them anymore

Re: [deal.II] Call for Codes

Thanks David. Now I think I get it. :-) Best, Toby 20.04.2017 17:00 "David Wells" napisał(a): > Hi Toby, > > That sentence is not well written. I should have written > > I ocassionally scan GitHub to learn what features of deal.II people are > using in their own projects. > >

Re: [deal.II] Re: imposing boundary conditions for a three-fields formulation

1 - Can I manage the exception in a way that in case CG does not converge I can try GMRes rather than aborting? Is the usual try-catch instruction working? 2 - I see that the class PETScWrappers implements both BiCGStab and GMRes. Can you pinpoint to an example? Yes, this works. Here is an

Re: [deal.II] fixing one component of solution to the same value

Rajat, It seems that I confused lines and did not express in the code what I wrote above: You have to add that additional index also when initializing the sparsity pattern, i.e. std::cout << " constraints printed " <