Re: [deal.II] deal.II 9.5 released

[Wolfgang Bangerth]

A release is also always an opportunity for us to thank the many people who 
have contributed code to a release. The list is as always quite long -- for 
the 9.5 release, the following people have all contributed code or 
documentation or in other ways:


Pasquale Africa,
Nicolas Barnafi,
Nistha Bhawsinka,
Bruno Blais,
Fabian Castelli,
Terry Cojean,
Niklas Fehn,
Emmanuel Ferdman,
Vadim Gallyamov,
Daniel Garcia-Sanchez,
Rene Gassmoeller,
Robin Goermer,
Graham Harper,
Quang Hoang,
Sean Ingimarson,
Vladimir Ivannikov,
Pengfei Jia,
Tao Jin,
Nils Margenberg,
Luz Paz,
Laura Prieto Saavedra,
Sebastian Proell,
Ce Qin,
Oleg Rogozin,
Andrew Salmon,
Michael Schlottke-Lakemper,
Christoph Schmidt,
Magdalena Schreter-Fleischhacker,
Richard Schussnig,
Nils Schween,
Ahmad Shahba,
Simon Sticko,
Buğrahan Temür,
Ivy Weber,
Niklas Wik,
Vladimir Yushutin,
Jiaqi Zhang.

In addition, the release paper mentioned in the previous email has 15 authors.

Many thanks to all of you!
Wolfgang Bangerth, for all of the other developers

--

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/0161410a-cbd9-9792-df78-2a419baaee39%40colostate.edu.

[deal.II] deal.II 9.5 released

[Wolfgang Bangerth]

Version 9.5.0 of deal.II, the object-oriented finite element library awarded 
the J. H. Wilkinson Prize for Numerical Software, has been released. It is

available for free under an Open Source license from the deal.II homepage at

   https://www.dealii.org/

The major changes of this release are:
  - Substantial updates and extensions to deal.II's interfaces to other
libraries. This includes, in particular, the integration of Kokkos
additions and updates to the PETSc and Trilinos interfaces.
  - Improvements to the matrix-free infrastructure
  - Better support for non-matching grids
  - Faster or more robust linear solvers and preconditioners
  - Many changes to the CMake configuration system, as well as more extensive
use of modern C++ features
  - A large number of updates to the tutorials and other documentation.

For more information see:
  - The preprint at https://www.dealii.org/deal95-preprint.pdf
  - The list of changes at

https://www.dealii.org/developer/doxygen/deal.II/changes_between_9_4_0_and_9_5_0.html

The main features of deal.II are:
  - Extensive documentation and 83 fully-functional example programs
  - Support for dimension-independent programming
  - Locally refined adaptive meshes
  - Multigrid support
  - A zoo of different finite elements
  - Fast linear algebra
  - Built-in support for shared memory and distributed parallel computing,
scaling from laptops to clusters with 100,000+ processor cores
  - Interfaces to Trilinos, PETSc, SUNDIALS, UMFPACK and many other external
software packages
  - Output for a wide variety of visualization platforms.

Wolfgang,
on behalf of the deal.II developer team and many contributors.


--

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/96100e83-fb78-1aa9-250a-56868a5e1908%40colostate.edu.

Re: [deal.II] Does deal.ll support import grid from openfoam solver

[blais...@gmail.com]

It is maybe unrelated, but as far as I remember, OpenFOAM supports mesh 
adaptivity. It is maybe not as efficient (and does not include dynamic load 
balancing) like deal.II does, but I would first start with that.
Otherwise, you would need to go through the VTK file format or write your 
own openfoam reader for deal.II. I would suggest using VTK as an 
"interface" format.



On Saturday, July 15, 2023 at 8:18:31 a.m. UTC-4 vachanpo...@gmail.com 
wrote:

> I don't know about a direct technique, but you can first use foamToVTK to 
> convert foam mesh to vtk and then import vtk in dealii.
>
> Vachan
>
> On Sat, 15 Jul, 2023, 16:47 ztdep...@gmail.com,  
> wrote:
>
>> I want to couple the mesh adaptivity off deal.ll with openfoam solver. 
>> Could you please give me some suggestions.
>>
>> -- 
>> 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+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/86025b56-5496-4be7-8d03-c2b01acbe13cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/cfafab66-a67d-4cce-8be2-3267a5904d1dn%40googlegroups.com.

[deal.II] Re: Convergence failure in penalty method implementation

[blais...@gmail.com]

In addition to Wolfgang's answer. Here are some suggestions.

1. You system is not symmetric. Consequently, it is not a viable idea to 
use the CG linear solver 
(see https://en.wikipedia.org/wiki/Conjugate_gradient_method). As 
suggested, using something like GMRES would be a better idea for your case.
2. Be careful about the preconditioner  you use. Something like ILU, which 
is pretty blackbox, could do a good job for your problem (most likely). 
Increasing the fill level will increase the robustness, but make the solver 
more demanding.
3. If you wish to be able to continue your simulation when such a bug 
occur, you can catch the exception thrown by the linear solver. An example 
of this is done 
here: 
https://github.com/lethe-cfd/lethe/blob/master/source/solvers/gls_navier_stokes.cc#L1325
In essence, what we do is catch the exception and increase the fill level. 
The code to achieve this would look something like this:
try
{
  TrilinosWrappers::SolverGMRES solver(solver_control,
   solver_parameters);

solver.solve(system_matrix, solution, rhs, preconditioner;
}
  catch (std::exception )
{
Do something if convergence has failed. 
}


Best
Bruno


On Tuesday, July 18, 2023 at 2:44:54 a.m. UTC-4 sabya...@gmail.com wrote:

> Hello, 
>
> I have come up with a solution, although there may be other ones using 
> iterative solvers. I changed the solver to SparseDirectMUMPS (from tutorial 
> 62). It seems to have stopped generating the error.  Note that my stiffness 
> matrix is not symmetric ( system_matrix.is_symmetric()  is returning 0 ). 
> The modified lines are below: 
>
> --
> SolverControl solver_control(100, 1e-3*system_rhs.l2_norm());
> PETScWrappers::SparseDirectMUMPS solver(solver_control, mpi_communicator); 
> solver.solve(system_matrix, distributed_incremental_solution, system_rhs);
> --
>
> Best, 
> Sabyasachi 
> On Thursday, July 13, 2023 at 6:33:09 PM UTC+5:30 sabyasachi chatterjee 
> wrote:
>
>> I just wanted to correct one small thing. What I mean by relative error 
>> before is the residual norm, which is a relative number. 
>>
>> On Thursday, July 13, 2023 at 12:57:23 PM UTC+5:30 sabyasachi chatterjee 
>> wrote:
>>
>>> Hello, 
>>>
>>> I am trying to solve a nonlinear contact problem using penalty method. 
>>> The tangent stiffness matrix is of the form  K_e + c * K_p, where K_e and 
>>> K_p are the elastic and penalty contributions and c is the penalty 
>>> parameter, which is a large number (in the order of 10^2 to 10^3 in our 
>>> case). The part of the problem that carries out the linear solve for the 
>>> incremental displacement  using Newton Raphson method is below: 
>>>
>>>
>>> 
>>> PETScWrappers::MPI::Vector distributed_incremental_solution(
>>>   locally_owned_dofs, mpi_communicator);
>>> distributed_incremental_solution = incremental_solution;
>>>
>>> SolverControl solver_control(2, 1e-5); 
>>> PETScWrappers::SolverCG solver(solver_control, mpi_communicator);
>>> PETScWrappers::PreconditionBlockJacobi preconditioner(system_matrix);
>>>
>>> solver.solve(system_matrix,
>>>  distributed_incremental_solution,
>>>  system_rhs,preconditioner);
>>>
>>> incremental_solution = distributed_incremental_solution;
>>>
>>> hanging_node_constraints.distribute(incremental_solution);
>>> solution.add(1.0,incremental_solution); 
>>>
>>> 
>>>
>>> I receive the following error upon running the code: 
>>> --
>>> Iterative method reported convergence failure in step 33. The residual
>>> in the last step was 0.000778898.
>>>
>>> This error message can indicate that you have simply not allowed a
>>> sufficiently large number of iterations for your iterative solver to
>>> converge. This often happens when you increase the size of your
>>> problem. In such cases, the last residual will likely still be very
>>> small, and you can make the error go away by increasing the allowed
>>> number of iterations when setting up the SolverControl object that
>>> determines the maximal number of iterations you allow.
>>>
>>> The other situation where this error may occur is when your matrix is
>>> not invertible (e.g., your matrix has a null-space), or if you try to
>>> apply the wrong solver to a matrix (e.g., using CG for a matrix that
>>> is not symmetric or not positive definite). In these cases, the
>>> residual in the last iteration is likely going to be large.
>>> ---
>>>
>>> For my problem, I don't require a relative error of the order of say 
>>> 10^(-12) as is often used in the tutorials and a relative error of 10^(-4) 
>>> probably should also work. I increased the relative error to 10^(-4) and 
>>> 

Re: [deal.II] create reference simplex in 2d (triangle) based on three vertices

[Daniel Arndt]

Math,

You can use ReferenceCells::get_simplex()
https://www.dealii.org/current/doxygen/deal.II/namespaceReferenceCells.html#ace7fb0fa0c1a98b17ae9c6f6d2eaa650
to create a ReferenceCell object describing the reference simplex.

Best,
Daniel

On Tue, Jul 18, 2023 at 1:49 PM Mathieu  wrote:

> Thank you Daniel!
>
> I have one follow-up (I apologize for this basic question):
> -The ReferenceCall that I have to pass to GridGenerator::reference_cell
> only has a default constructor.
> So how can I create a simplex using this constructor?
>
> Best,
> Math
>
> d.arnd...@gmail.com schrieb am Dienstag, 18. Juli 2023 um 17:14:14 UTC+2:
>
> Mathieu,
>
> You should be able to use GridGenerator::reference_cell (
> https://www.dealii.org/current/doxygen/deal.II/namespaceGridGenerator.html#aeb9a83e353f8d69ce49ebdd191a3a51f
> ),
> and then move the vertices to your liking, e.g. by using
> GridTools::transform (
> https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a212e99cf0d923cebfa04f1d23fa60b04
> ).
>
> Best,
> Daniel
>
> On Tue, Jul 18, 2023 at 5:07 AM Mathieu  wrote:
>
> Hello everyone,
>
> I read the simplex support
>  
> documentation
> and was wondering
> whether it is possible to create a triangle in 2d based on three vertices?
>
> The quadrilateral pendant is GridGenerator::general_cell().
> Contrary to what one might think, GridGenerator::simplex()
> transforms the reference simplex into three quadrilaterals,
> which is also not what I am looking for.
>
> So is there a way to create a mesh consisting of one triangle (using three
> vertices)?
> I have deal.II 9.3.2 installed, but can upgrade if necessary.
>
> Thank you,
> Math
>
> --
> 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+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/1b0cefaa-24fe-4e7c-8f9a-aaaf72d8ee2cn%40googlegroups.com
> 
> .
>
> --
> 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/4e354772-377b-47bb-a9b7-eee733b957dbn%40googlegroups.com
> 
> .
>

-- 
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/CAOYDWbJRygOtcLhWZmQ0AmYBjzsHvZSbyU800k-g-mqUTM_Gfg%40mail.gmail.com.

Re: [deal.II] create reference simplex in 2d (triangle) based on three vertices

[Mathieu]

Thank you Daniel!

I have one follow-up (I apologize for this basic question):
-The ReferenceCall that I have to pass to GridGenerator::reference_cell
only has a default constructor.
So how can I create a simplex using this constructor?

Best,
Math

d.arnd...@gmail.com schrieb am Dienstag, 18. Juli 2023 um 17:14:14 UTC+2:

Mathieu,

You should be able to use GridGenerator::reference_cell (
https://www.dealii.org/current/doxygen/deal.II/namespaceGridGenerator.html#aeb9a83e353f8d69ce49ebdd191a3a51f
),
and then move the vertices to your liking, e.g. by using 
GridTools::transform (
https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a212e99cf0d923cebfa04f1d23fa60b04
).

Best,
Daniel

On Tue, Jul 18, 2023 at 5:07 AM Mathieu  wrote:

Hello everyone,

I read the simplex support 
 
documentation 
and was wondering 
whether it is possible to create a triangle in 2d based on three vertices?

The quadrilateral pendant is GridGenerator::general_cell().
Contrary to what one might think, GridGenerator::simplex()
transforms the reference simplex into three quadrilaterals,
which is also not what I am looking for.

So is there a way to create a mesh consisting of one triangle (using three 
vertices)?
I have deal.II 9.3.2 installed, but can upgrade if necessary.

Thank you,
Math

-- 
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+un...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/1b0cefaa-24fe-4e7c-8f9a-aaaf72d8ee2cn%40googlegroups.com
 

.

-- 
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/4e354772-377b-47bb-a9b7-eee733b957dbn%40googlegroups.com.

Re: [deal.II] Re: Convergence failure in penalty method implementation

[Wolfgang Bangerth]

On 7/18/23 00:44, sabyasachi chatterjee wrote:
Note that my stiffness matrix is not symmetric ( system_matrix.is_symmetric() 
is returning 0 ).


Then there is your mistake. You can only use the CG solver for symmetric and 
positive definite matrices. You will want to use GMRES for other matrices.


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/87e75e01-2fdb-63e1-6c0c-64a9dc7a9173%40colostate.edu.

Re: [deal.II] Re: Issue on CUDA code

[giuseppe orlando]

Dear Bruno,
thank you very much. I am having some troubles to install the new version 
with CUDA and MPI using 'nvcc_wrapper', but, once solved these issues 
(hopefully), I will definitely try with the last version of deal.II.

Best,

Giuseppe

Il giorno lunedì 17 luglio 2023 alle 20:34:18 UTC+2 bruno.t...@gmail.com ha 
scritto:

> Giuseppe,
>
> We totally rewrote the GPU matrix-free framework on the latest release of 
> deal.II (version 9.5). One of the advantages is that you can now 
> write/debug the code on the CPU and then switch to run the code on the GPU. 
> The new code is not 100% backward compatible but the changes are pretty 
> small. I advise you to switch to the latest version of deal.II, debug the 
> code on the CPU, and then run on the GPU.
>
> Best,
>
> Bruno
>
> Le lun. 17 juil. 2023 à 14:12, giuseppe orlando  a 
> écrit :
>
>> Dear Bruno,
>> thank you very much. That was the issue with the matrix-based version. 
>> I take the opportunity for another question (sorry in advance to bother). 
>> I also tried to implement a matrix-free version of the same problem, 
>> exploiting therefore all the routines such as 'assemble_rhs' and delegating 
>> the action of the matrix to suitable operators. The results are the same 
>> for a few time-steps and then it blows up. I guess that it is something 
>> again related to the memory access, but I couldn't figure out the issue. In 
>> thics case, it should not be CUDA::Handle, because I am not using it since 
>> we are in a matrix-free framework.
>>
>> Thanks again for the previous suggestion.
>>
>> Best,
>>
>> Giuseppe
>>
>> Il giorno lunedì 17 luglio 2023 alle 17:50:27 UTC+2 bruno.t...@gmail.com 
>> ha scritto:
>>
>>> Giuseppe,
>>>
>>> The CUDA::Handle needs to live longer than the sparse matrix but in your 
>>> code it goes out-of-scope at the end of assemble_system(). I know the same 
>>> code works with assemble_matrix but it only works "by chance" because 
>>> nothing wrote over the memory. I don't know if that's the  only problem but 
>>> that's definitely wrong.
>>>
>>> Best,
>>>
>>> Bruno
>>>
>>> Le lun. 17 juil. 2023 à 11:06, giuseppe orlando  a 
>>> écrit :
>>>
 Here, you can find the two codes. 'SBR_GPU' is the one that arrives up 
 to the end, whereas 'SBR_GPU_WRONG' is the one that stops with the error 
 described above once I call 'output_results'. If the code is too long and 
 can be helpful, I could try to reduce it avoiding ParameterHandler and 
 other more 'advanced' stuff and to reduce everything to a unique file.

 Best,

 Giuseppe

 Il giorno lunedì 17 luglio 2023 alle 16:11:18 UTC+2 
 bruno.t...@gmail.com ha scritto:

> Giuseppe,
>
> It's hard to tell what's wrong without seeing the code.
>
> Best,
>
> Bruno
>
> On Monday, July 17, 2023 at 9:04:42 AM UTC-4 gius...@gmail.com wrote:
>
>> Hello everyone,
>> I'm writing this post to ask some help for a CUDA code. I have 
>> implemented a matrix-based CUDA coda for the so-called solid body 
>> rotation, 
>> namely a time dependent advection problem. In my first implementation, I 
>> encapulased the computation of the matrix and of the right-hand side of 
>> the 
>> resulting linear system in the same routine ('assemble_system'). Then, I 
>> tried to separate the assembling of the matrix ('assemble_matrix') and 
>> of 
>> the rhs ('assemble_rhs'). Since the matrix does not change (I am using 
>> an 
>> explicit time integration scheme and, therefore, the resulting matrix is 
>> a 
>> mass matrix), I compute it at the beginning and then I just update the 
>> right-hand side. Everything works until I save the results, after which 
>> I 
>> obtain this error ("On entry to cusparseSpMV() parameter number 1 
>> (handle) 
>> had an illegal value: invalid pointer mode"). 
>> I also tried to create an auxiliary vector just for saving, but 
>> nothing changes. 
>> Everything runs with 1 GPU. Have anyone ever obtained this kind of 
>> issue? If it can help, I can share the two versions of the code.
>>
>> Thanks in advance
>>
>> Best
>>
>> Giuseppe 
>>
> -- 
 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 a topic in the 
 Google Groups "deal.II User Group" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/dealii/p5eZs3NaGRk/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 dealii+un...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/dealii/9d079799-6b51-46f6-8564-8058877e83d7n%40googlegroups.com
  
 

Re: [deal.II] create reference simplex in 2d (triangle) based on three vertices

[Daniel Arndt]

Mathieu,

You should be able to use GridGenerator::reference_cell (
https://www.dealii.org/current/doxygen/deal.II/namespaceGridGenerator.html#aeb9a83e353f8d69ce49ebdd191a3a51f
),
and then move the vertices to your liking, e.g. by using
GridTools::transform (
https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a212e99cf0d923cebfa04f1d23fa60b04
).

Best,
Daniel

On Tue, Jul 18, 2023 at 5:07 AM Mathieu  wrote:

> Hello everyone,
>
> I read the simplex support
>  
> documentation
> and was wondering
> whether it is possible to create a triangle in 2d based on three vertices?
>
> The quadrilateral pendant is GridGenerator::general_cell().
> Contrary to what one might think, GridGenerator::simplex()
> transforms the reference simplex into three quadrilaterals,
> which is also not what I am looking for.
>
> So is there a way to create a mesh consisting of one triangle (using three
> vertices)?
> I have deal.II 9.3.2 installed, but can upgrade if necessary.
>
> Thank you,
> Math
>
> --
> 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/1b0cefaa-24fe-4e7c-8f9a-aaaf72d8ee2cn%40googlegroups.com
> 
> .
>

-- 
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/CAOYDWb%2BqoRn14YNp28ZRShh%2BvSWH7yavpZU-P6dTK1B%3Dwbt1wQ%40mail.gmail.com.

[deal.II] create reference simplex in 2d (triangle) based on three vertices

[Mathieu]

Hello everyone,

I read the simplex support 
 
documentation 
and was wondering 
whether it is possible to create a triangle in 2d based on three vertices?

The quadrilateral pendant is GridGenerator::general_cell().
Contrary to what one might think, GridGenerator::simplex()
transforms the reference simplex into three quadrilaterals,
which is also not what I am looking for.

So is there a way to create a mesh consisting of one triangle (using three 
vertices)?
I have deal.II 9.3.2 installed, but can upgrade if necessary.

Thank you,
Math

-- 
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/1b0cefaa-24fe-4e7c-8f9a-aaaf72d8ee2cn%40googlegroups.com.

[deal.II] Re: Convergence failure in penalty method implementation

[sabyasachi chatterjee]

Hello, 

I have come up with a solution, although there may be other ones using 
iterative solvers. I changed the solver to SparseDirectMUMPS (from tutorial 
62). It seems to have stopped generating the error.  Note that my stiffness 
matrix is not symmetric ( system_matrix.is_symmetric()  is returning 0 ). 
The modified lines are below: 

--
SolverControl solver_control(100, 1e-3*system_rhs.l2_norm());
PETScWrappers::SparseDirectMUMPS solver(solver_control, mpi_communicator); 
solver.solve(system_matrix, distributed_incremental_solution, system_rhs);
--

Best, 
Sabyasachi 
On Thursday, July 13, 2023 at 6:33:09 PM UTC+5:30 sabyasachi chatterjee 
wrote:

> I just wanted to correct one small thing. What I mean by relative error 
> before is the residual norm, which is a relative number. 
>
> On Thursday, July 13, 2023 at 12:57:23 PM UTC+5:30 sabyasachi chatterjee 
> wrote:
>
>> Hello, 
>>
>> I am trying to solve a nonlinear contact problem using penalty method. 
>> The tangent stiffness matrix is of the form  K_e + c * K_p, where K_e and 
>> K_p are the elastic and penalty contributions and c is the penalty 
>> parameter, which is a large number (in the order of 10^2 to 10^3 in our 
>> case). The part of the problem that carries out the linear solve for the 
>> incremental displacement  using Newton Raphson method is below: 
>>
>>
>> 
>> PETScWrappers::MPI::Vector distributed_incremental_solution(
>>   locally_owned_dofs, mpi_communicator);
>> distributed_incremental_solution = incremental_solution;
>>
>> SolverControl solver_control(2, 1e-5); 
>> PETScWrappers::SolverCG solver(solver_control, mpi_communicator);
>> PETScWrappers::PreconditionBlockJacobi preconditioner(system_matrix);
>>
>> solver.solve(system_matrix,
>>  distributed_incremental_solution,
>>  system_rhs,preconditioner);
>>
>> incremental_solution = distributed_incremental_solution;
>>
>> hanging_node_constraints.distribute(incremental_solution);
>> solution.add(1.0,incremental_solution); 
>>
>> 
>>
>> I receive the following error upon running the code: 
>> --
>> Iterative method reported convergence failure in step 33. The residual
>> in the last step was 0.000778898.
>>
>> This error message can indicate that you have simply not allowed a
>> sufficiently large number of iterations for your iterative solver to
>> converge. This often happens when you increase the size of your
>> problem. In such cases, the last residual will likely still be very
>> small, and you can make the error go away by increasing the allowed
>> number of iterations when setting up the SolverControl object that
>> determines the maximal number of iterations you allow.
>>
>> The other situation where this error may occur is when your matrix is
>> not invertible (e.g., your matrix has a null-space), or if you try to
>> apply the wrong solver to a matrix (e.g., using CG for a matrix that
>> is not symmetric or not positive definite). In these cases, the
>> residual in the last iteration is likely going to be large.
>> ---
>>
>> For my problem, I don't require a relative error of the order of say 
>> 10^(-12) as is often used in the tutorials and a relative error of 10^(-4) 
>> probably should also work. I increased the relative error to 10^(-4) and 
>> still got a similar error with the final residual a little more than 
>> 10^(-4). I further increased the relative error to 10^(-3), but the 
>> accuracy of the results got compromised. Let me know if there is any way to 
>> go around this issue.
>>
>> Also please suggest if there is a way to NOT make the code stop if such a 
>> situation arises and instead accept the result as it is and move ahead?  
>>
>> Finally, do you recommend any other solver in this case . 
>>
>> Thanks, 
>> Sabyasachi 
>>
>>
>>

-- 
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/c1c356e7-e1cb-4697-a49d-edb01c06c1e6n%40googlegroups.com.