Tips for No convergence of GMRES?

maha-haji commented 4 years ago

Hi,

Does anyone have tips on how to troubleshoot the following warning? WARNING: No convergence of the GMRES.

My issue is that I am able to solve the radiation problem for separate, individual bodies. But once I combine them, I keep getting a GMRES warning like this and no solution.

Thanks!

mancellin commented 4 years ago

Interesting, I don"t remember ever having this problem. Could you give some details on the problem you are working on?

You can try a direct solver with the following syntax:

direct_linear_solver = cpt.BasicMatrixEngine(linear_solver='direct')
solver = cpt.BEMSolver(engine=direct_linear_solver)

maha-haji commented 4 years ago

I am trying to determine the hydrodynamic coefficients of a body comprised of three sections: a top float, a few columns, and a lower damping plate (see image for the immersed part).

I have no issues with any of the bodies individually (either the top float, the pair of columns, or the lower plate), but something seems to go awry when I combine any of them together. If I reduce the number of columns to 1, I also have no issues.

Trying the direct solver also did not seem to work. I receive the following output for the cpt.assemble_dataset(results):

Dimensions:            (body_name: 0, g: 0, influenced_dof: 0, omega: 0, radiating_dof: 0, rho: 0, water_depth: 0)
Coordinates:
  * g                  (g) float64 
  * water_depth        (water_depth) float64 
  * radiating_dof      (radiating_dof) object 
  * influenced_dof     (influenced_dof) object 
  * body_name          (body_name) object 
  * omega              (omega) float64 
  * rho                (rho) float64 
Data variables:
    added_mass         (g, rho, body_name, water_depth, omega, radiating_dof, influenced_dof) float64 
    radiation_damping  (g, rho, body_name, water_depth, omega, radiating_dof, influenced_dof) float64 
Attributes:
    creation_of_dataset:  2020-05-16T17:54:35.946682
    capytaine_version:    1.1

mancellin commented 4 years ago

There seems to be overlapping panels where the cylinders meet. It might be the issue. What if you add some vertical space between the cylinders ?

maha-haji commented 4 years ago

That seemed to work! I added 1e-6 z-distance between them and the algorithm seems to converge. Thanks!

On May 18, 2020, at 3:30 AM, Matthieu Ancellin notifications@github.com wrote:

There seems to be overlapping panels where the cylinders meet. It might be the issue. What if you add some vertical space between the cylinders ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mancellin/capytaine/issues/30#issuecomment-630029238, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF6JRRRX6QIAIUO7GR3746DRSDW2VANCNFSM4NCW57LA.

RubendeBruin commented 4 years ago

Are your results realistic? It is often very difficult to get realistic results using diffraction for models where panels are close to eachother. For example side-by-side moored tankers and semi-subersibles with horizontal planes just below the water surface. No idea what the true size of your geometry is but at least check for standing waves between the two columns.

izabala123 commented 2 years ago

Dear Matthieu

I also get GMRES warnings. Here I enclose you two samples, with the message and the set of files. Normally this message appears some times per case, and the calculation time gets very slow. Probably is because I'm not using the right parameters.

May you help me?

For mesh 00758_Y

INFO: Solve DiffractionProblem(body=.\mesh\00758_Y.dat, omega=1.563, depth=1000.0, wave_direction=180.000, g=9.807, rho=1025.0). WARNING: No convergence of the GMRES. Error code: 8020

For mesh 04519_Y

INFO: Solve DiffractionProblem(body=.\mesh\04519_Y.dat, omega=1.386, depth=1000.0, wave_direction=180.000, g=9.807, rho=1025.0). WARNING: No convergence of the GMRES. Error code: 46540

00758_Y.zip 04519_Y.zip

izabala123 commented 2 years ago

Thank you Matthieu

I didn't realize of it because the problematic nemoh.cal files are generated automatically from AQWA files with different headings, but I only postprocess the 0º one, so I wasn't aware of the bad results for other headings...

Now I will immediately fix this error in BEMRosetta.

mancellin commented 2 years ago

Now I will immediately fix this error in BEMRosetta.

The mistake is on my side: the wave direction should be in degrees in Nemoh.cal for consistency with Nemoh. It will probably be fixed in the next version of Capytaine, so if you change the behavior of BEMRosetta, you might want to add a test on the version of Capytaine to avoid converting twice the degrees in radians.

180 radians is still a valid wave direction, so it does not really explain your issue with the GMRES. I did not have the time to really look into that yet, but I have some questions to frame the problem:

The code is working fine for a wide range of frequency, but it misbehaves only at a given one, is that right? Does the result looks like an irregular frequency? I would not be surprised if there were this kind of issues at the peak of the irregular frequency.
Is the behavior different for an infinite depth case, instead of a finite 1000 meter depth?

izabala123 commented 2 years ago

Dear Matthieu

There was another fail on my side, initial nemoh.cal included headings from 180 to 180, 5 times, so really the 180 case was calculated 5 times :-( I have run the 00758_Y case three times:

Grad1000: Heading in degrees, depth 1000 m
Rad1000: Heading in radians, depth 1000 m
RadInf: Heading in radians, depth infinite

The problem repeats. You can see the outputs in the enclosed files.

RadInf.txt Rad1000.txt Grad1000.txt

mancellin commented 2 years ago

A late follow-up on this topic:

I can reproduce the GMRES convergence issue for omega ~ 1.4. When using a direct linear solver, there is no convergence issue, but the results are not really sound. Most likely irregular frequencies.

Figure_1

Code

```python import numpy as np import xarray as xr import matplotlib.pyplot as plt import capytaine as cpt body = cpt.FloatingBody.from_file('mesh/00758_Y.dat') body.center_of_mass = [78.5, 0, 5.04] body.add_all_rigid_body_dofs() body.keep_immersed_part() test_matrix = xr.Dataset(coords={ 'omega': np.linspace(1.0, 1.8, 100), 'radiating_dof': list(body.dofs), }) engine = cpt.BasicMatrixEngine(linear_solver='direct') solver = cpt.BEMSolver(engine=engine) ds = solver.fill_dataset(test_matrix, [body]) ds.added_mass.sel(radiating_dof="Heave", influenced_dof="Heave").plot(x="omega") plt.show() ```

I am wondering if we should keep GMRES as default linear solver or go back to a direct solver as in Nemoh. GMRES is faster on most cases, but does not finish for such unsound cases, whereas the speed of the direct solver is more predictable.

mancellin commented 1 year ago

Closing this old issue. As of today, the GMRES is not the default solver anymore, so most of the related issues should not show up anymore. Feel free to reopen a new issue if necessary.

samir-miloud commented 3 months ago

Hi,

I’m currently working on modeling the Sparbuoy OWC case using Capytaine, employing the Generalized Body Modes (GBM) method. I need to incorporate 7 degrees of freedom (DoFs) into the simulation. However, Capytaine only provides the 6 standard DoFs (surge, sway, heave, roll, pitch, yaw), and I am missing an additional DoF for the water column height. Does anyone have experience with adding a 7th DoF in Capytaine, or any suggestions on how to handle this with the GBM method?

Thanks!

izabala123 commented 2 months ago

Dear Samir

Since Capytaine can handle more than one body, I would consider the water column as a second body but taking into account for the latter only the results in heave, i.e. using only degrees of freedom 1, 2, 3, 4, 5, 6 and 9. The paper “Using NEMOH for Modelling Wave Energy Converters: A Comparative Study with WAMIT” by Markel Penalba, Thomas Kelly and John V. Ringwood, discusses how to model a column.

However, I cannot answer you whether Capytaine is able to handle the oscillating water columns. Matthieu or another expert will be able to answer you.

Best regards Iñaki Zabala

samir-miloud commented 2 months ago

Dear Iñaki, Thank you very much for your prompt response and for the valuable information you've provided. As I am new to this field, your advice is incredibly helpful. To further my research, could you please share the contact information for Matthieu or any other experts you know who might be able to assist with Capytaine and oscillating water columns? Thank you again for your support.

Best regards, Samir

Le lun. 12 août 2024 à 07:33, Iñaki Zabala @.***> a écrit :

Dear Samir

Since Capytaine can handle more than one body, I would consider the water column as a second body but taking into account for the latter only the results in heave, i.e. using only degrees of freedom 1, 2, 3, 4, 5, 6 and 9. The paper “Using NEMOH for Modelling Wave Energy Converters: A Comparative Study with WAMIT” by Markel Penalba, Thomas Kelly and John V. Ringwood, discusses how to model a column.

image.png (view on web) https://github.com/user-attachments/assets/920130ef-29f4-4707-b5e1-6d211678f862

However, I cannot answer you whether Capytaine is able to handle the oscillating water columns. Matthieu or another expert will be able to answer you.

Best regards Iñaki Zabala

— Reply to this email directly, view it on GitHub https://github.com/capytaine/capytaine/issues/30#issuecomment-2283201208, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHMBGCWRQ36J77JJAKD4OG3ZRBJMPAVCNFSM6AAAAABMK2R5DOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBTGIYDCMRQHA . You are receiving this because you commented.Message ID: @.***>

izabala123 commented 2 months ago

Hi Samir

As this is the Capytaine portal at GitHub, I advice you to open a new issue, asking for advice to model OWC with Capytaine. Some details and some views of your case or a similar one will help to understand better your case.

Best regards Iñaki Zabala

samir-miloud commented 2 months ago

Hi @mancellin,

I am writing regarding the modeling of a Sparbuoy OWC using Capytaine and the Generalized Body Modes (GBM) method. Specifically, I am facing difficulties integrating a 7th degree of freedom (DoF) for the water column height, as Capytaine generates only the 6 standard DoFs. Could you provide guidance on how to handle this situation or recommendations for incorporating the 7th DoF into the simulations? Any additional information or advice would be greatly appreciated.

Best regards,

mancellin commented 2 months ago

Hi @samir-miloud, this thread on GMRES is not the best place to discuss this, we should have the discussion on #582.

capytaine / capytaine

Tips for No convergence of GMRES? #30