[deal.II] tutorial step-36 failed with PETSc error number 76 while calling a SLEPc function

[Pragalv Karki]

I was trying to run the tutorial 36 but it shows up with following errors:

*[0]PETSC ERROR: - Error Message 
--*

[0]PETSC ERROR: Error in external library

[0]PETSC ERROR: Error in LAPACK subroutine steqr: info=0

[0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for 
trouble shooting.

[0]PETSC ERROR: Petsc Release Version 3.10.0, Sep, 12, 2018 

[0]PETSC ERROR: ./step-36 on a  named Pragalvs-MacBook-Air.local by 
pragalvkarki Tue Sep 10 15:29:22 2019

(Lot of unnecessary stuff (I think ) in between these error messages)

An error occurred in line <182> of file 

 
in function

void dealii::SLEPcWrappers::SolverBase::solve(const unsigned int, 
unsigned int *)

The violated condition was: 

ierr == 0

Additional information: 
An error with error number 76 occurred while calling a SLEPc 
function 

One of the error says " Petsc Release Version 3.10.0" . Is dealii not 
compatible with this version yet? I would really appreciate your help.

- Pragalv




-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0c8575ba-cf75-4612-9914-bf138f49789b%40googlegroups.com.

Re: [deal.II] Stabilization for Q1Q0 Stokes by Bochev [2006]

[Bruno Blais]

I second Wolfgang comment on the fact that Q1Q1 is not difficult to 
implement. You can also scale it to arbitrary Qn-Qn elements if you are 
interested in higher order.
We have implemented such an approach in our code based on dealii (
https://github.com/lethe-cfd/lethe)
Q1Q1 is already very diffusive (which is why it is so robust I guess), so I 
am not sure that going with Q1-Q0 to save a few pressure degree of freedom 
is actually worth it.
Best!
Bruno

On Tuesday, 10 September 2019 00:03:27 UTC-4, Wolfgang Bangerth wrote:
>
> On 9/9/19 1:57 AM, Richard Schussnig wrote: 
> > 
> > FINALLY, MY QUESTIONS: 
> > 
> > Using the Q1Q1, I would in the end (FSI) need to come up with a space 
> made 
> >  from Q1 elements with a discontinuity at the interface - which shall be 
> > realized using different material_id(). - how may I do that other than 
> > using a FE_DGQ space for the pressure and enforce continuity 'manually' 
> > through a giant ConstraintMatrix? 
>
> That's inefficient, of course :-) I assume that your interface is in the 
> interior of the domain? In that case, take a look at step-46, where 
> solution 
> variables only live on certain cells, and are discontinuous at the 
> interface 
> between the two parts of the domain. 
>
>
> > Using the Q1Q0, the main problem is data transfer and 'node searching' 
> in 
> > the parallel case - example: the stabilization matrix from cell 16 has 
> > pressure dof 45 and shares edges or maybe only a single vertex (!) with 
> > cells with pressure dofs 1 2 3 4 5. The cell matrix for the projection 
> from 
> > Q0(dc) to Q1(c) is an area-weighted sum of the pressures on the cells 
> > touching the vertex of the support of the matching bilinear function, 
> > therefore we get a 6x6 local matrix and entries into all 'touching' 
> cells. 
>
> Yes, you'd have to create a map that for each vertex gives you a list of 
> all 
> adjacent cells. I think I recall that there is a function in GridTools for 
> this, though. 
>
>
> > Since these cells are not only the direct neighbors of the current cell, 
> > things may get complicated quite fast, if we consider the 3d case with 
> > hanging nodes, but on the other hand side, looping in the element loop 
> over 
> > all elements again(!) to check the vertex_index() is extremely slow. 
>
> Yes, you'd reverse this approach by looping over all vertices first, and 
> then 
> in this loop over all adjacent cells. 
>
>
> > Do you know of any better-fitting stabilizations for the Q1Q0 pair? Or 
> do 
> > you think there are better options around? 
>
> Q1-Q1 is a pretty good method, and not very difficult to implement. I'll 
> note 
> that Q1-Q0 *sounds* like a good idea, but has a very low convergence rate 
> and 
> so will not yield particularly good accuracy if that's what you actually 
> care 
> about. Of course, Q2-Q1 is the standard for good reasons. 
>
> Best 
>   W. 
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/169fb0a3-a042-4a01-b25f-2fd46c20bde9%40googlegroups.com.

Re: [deal.II] Re: Extracting volume data to the boundary

[Alberto Salvadori]

Thank you very much, Wolfgang, crystal clear as always.

It is still unclear to me, though, how to reinit() the FEFaceValues
for the cell making use of the
map returned by the extract_boundary_mesh() function. I learned to reinit
FEFaceValues as:

fe_face_values.reinit (cell, face_number);

Is there a "simple way" to get the (volume) cell iterator and the
face_number from the
parallel::shared::Triangulation::face_iterator in the map returned by
the extract_boundary_mesh() function?

Or shall I use a different way to reinit FEFaceValues?

Thank you

Alberto



*Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale
(DIMI)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-page:
 http://m4lab.unibs.it/faculty.html



On Mon, Sep 9, 2019 at 7:09 PM Wolfgang Bangerth 
wrote:

>
> > In solving a Laplace-Beltrami problem on an advecting surface one should
> > identify the Gauss points on the manifold dim-1 cell and retrieve at
> > such locations relevant information from the solution of the advection
> > problem, using the dim dof_handler of the volume. I wonder how to
> > connect a manifold dim-1 cell to the volumetric cell it was extracted
> > from. The GridGenerator::extract_boundary_mesh method seem to provide
> > some information, since "it returns A map that for each cell of the
> > surface mesh (key) returns an iterator to the corresponding face of a
> > cell of the volume mesh (value). " . I am not sure how I can use this
> > map to link a manifold cell to the corresponding volume cell.
>
> Alberto,
> the way this is supposed to be used is as follows:
>
> When you are assembling the linear system for the surface problem, you
> will have an FEValues object for the surface shape functions.
> You initialize it with a Quadrature.
>
> But then you also need to evaluate the volume solution on the same
> quadrature points. You do this by creating an FEFaceValues object,
> which requires you to also provide a Quadrature object -- which
> you want to choose the same as above.
>
> Now, if you need the volume solution when assembling something for the
> surface problem, you are sitting on a cell of the surface mesh; use the
> map returned by the extract_boundary_mesh() function to obtain what the
> corresponding face of the volume mesh is and reinit() the FEFaceValues
> for that cell. You can then use the FEFaceValues object to evaluate the
> volume solution at the same quadrature points as you use for the
> FEValues object of the surface mesh. The only thing you may have to pay
> attention to is that the surface cell may be inverted compared to the
> volume cell's face -- in which case the quadrature points of the two
> objects match, but are in a different order. You'll have to translate
> between these permutations then.
>
> Best
>   W.
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/a60b9b5e-fef3-fd88-5e54-65bed698a5bc%40colostate.edu
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 


-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CABcATpdDUXf0bY%3DLW9%2BCeBe7JEGZR2dn2-hxLqTushwT2a0zJw%40mail.gmail.com.