From: Renato P. <re...@gm...> - 2017-11-18 21:25:12
|
So .... I realized my issue is in fact a linear solver convergence issue... It seems that I created a difficult matrix to solve with the pressure variable being hacked sort of manually. Getting the tolerance down and increasing the solver iterations did the job (although runtime went up). Please disregard the previous questions about the mesh... the mesh is ok. On the other hand: does libMesh have tools to assess the quality of the matrix being generated? To understand the results of the linear solver, I am using the function "print_converged_reason". Any better idea? Thanks and sorry for the previous stuff. Renato On Sat, Nov 18, 2017 at 3:33 PM, Renato Poli <re...@gm...> wrote: > Hi > > I am struggling here with boundary conditions in a system of equations. > I am solving a system for 3 vars: U,V,P (displacements and pressure). > I decoupled pressure and displacements as a first attempt (in fact, Kpp > gets to be an identity matrix), Fp is zero. > > To test, I generated a mesh in CGAL and a similar one in GMSH. > I translate internally the CGAL mesh to libMesh. > For GMSH, I am using gmsh_io::read function. > > It happens that, in CGAL translated mesh, when I set a boundary condition > in variable P, the solution for U and V gets invalid. The same does _not_ > happen in the mesh generated in GMSH (works beautifully). > > So, I believe the problem would be in the translation from CGAL to > libMesh, which is indeed very straightforward. I had already validated the > translation for 2 variables (U,V). It looked fine. > > Would you have an advice? What might be happening? In which case decoupled > variables might interact in the solver? > > I am currently in a reverse engineering effort in the gmsh_io::read > function ... (no pain, no gain...) > > Thanks, > Renato > > > |