How to improve AMS's performance for highly non-uniform grid

[adam-sim-dev]

Hi,

I am solving complex Maxwell's equations with AMS, similar to ex22. Part of the domain's conductivity is very small, e.g., 1.0e-10, and I use a highly non-uniform grid. The scale in the outer part of the grid may be several thousands of that in the core domain. I observed AMS's poor performance for PCG (it did not reach a tolerance of 1.0e-2 after 100 iterations). Do you have any ideas on how I can improve AMS's performance by changing its default parameters? Or is this caused by the small conductivity value in the modeling domain?

Best,
Adam

[tzanio]

Hi Adam,

Small conductivity shouldn't affect AMS much (unless it is exactly zero). The issue is likely the anisotropic elements, which are challenging for the underlying AMG solvers. You can try changing some parameters in HypreAMS::MakeSolver to see if this will help: set amg_agg_levels to 0 and theta to 0.6 or 0.9.

Hope this helps,
Tzanio

[adam-sim-dev]

Hi @tzanio , I now have a problem with the' highly local irregular interface of two materials. The contrast of the beta coefficients is huge. I observed a significant decline in efficiency. How should I adjust the solver parameter?

[tzanio]

What is the range of values for beta?

[adam-sim-dev]

What is the range of values for beta?

One is 1.0e-8, the other is 2.0e-2. In part of the domain, their interface is not flat. I tried to increase theta, a medium theta performs better than a small one, however, the overall efficiency is not good.

[adam-sim-dev]

What is the range of values for beta?

I also suggest adding more setting functions to HypreAMS so that users can set the underlying AMG parameters. Currently, HypreAMS::MakeSolver uses some default parameters and is called inside the HypreAMS constructor. It would be good if we could create a HypreAMS object, set/update some parameters, and then make the actual solver before it's used.

[tzanio]

Hi @adam-sim-dev,

That jump by itself doesn't seem to large, so something else must be going on.

What is different about this simulation that the other ones that worked? Does AMS behave significantly better if e.g. the jumps are reduced? Does it have a long tunnel or twisted wire (those can lead to additional near-nulspace components)?

In principle you can obtain the hypre AMS solver object and call hypre functions on it if you want. If you can modify your copy of MFEM, it should not be hard to add more parameters in the constructor or through additional Setup functions. Before we do that in master though, I'd like to understand the source of the problem and what parameters are necessary to be changed.

Hope this helps,
Tzanio

[adam-sim-dev]

just to confirm -- the problem is definite in both cases, correct?

yes. beta is>0

[adam-sim-dev]

Hi @tzanio , any suggestions or comments?

[tzanio]

I am not sure what is happening in your simulation, typically jumps like these don't affect AMS much. Unless you have changed the default parameters, the ones we have in MFEM are already the best ones I am aware of. You can try varying some of them if you want (e.g. cycle type). If you are not using the latest MFEM, you should switch to that.

[adam-sim-dev]

The problem may be the irregular interface. Which cycle type or amg_interp_type may be better?

[tzanio]

I believe the default ams_cycle_type is 13. Others worth trying are: 1, 5, 7 and 11.

I would not change amg_interp_type, but you can try adjusting theta.