[FLASH-USERS] V-cycle not converging

[Artur Gawryszczak]

On czwartek, 18 września 2008, seyit wrote:
> 1) Is this warning something bad?

It depends on what was its cause. You may set mgrid_print_norm to .true. to 
see how many V-cycles are taken and how the convergence ratio changes. You 
may also want to inspect mg_unk array (mgw[1-5] fields in Flash 2.3 and 
earlier) to find where residuals remain uncorrected.

What boundary conditions do you use for gravity? For "isolated" BC it may 
happen that increase of mgrid_max_iter_change will help.

Another possibility is a defect of grid structure with a two refinement level 
difference across a corner or edge of the blocks. It occurs rarely when both 
refinement and derefinement of blocks takes place. Unfortunately I haven't 
any simple model that reproduces this problem. If this occured in your 
simulation you may expect defect in potential field located at grid fault 
(something like cosmic string ;-) ). It has usually magnitude of order of 1% 
or less, related to the correct field (an example or residual: 
http://users.camk.edu.pl/gawrysz/badrefinement.png), so it is possible that 
your simulations aren't much affected. You may also reduce mgrid_max_vcycles 
from the default value (100) to what is really needed (typically 10-15) to 
save some CPU time in some cases.

The change from mgw[1-5] fields in unk array to mg_unk array introduced in 
Flash 2.4 also reduced convergence ratio in multigrid solver, which 
indicates possible bug in guardcell communication. I haven't investigated it 
much - I just reverted from use of mg_unk to mgw[1-5] in unk.

If you plan to use multigrid solver in future I recommend you to switch to 
Flash 3.0 - the implementation of multigrid there is faster and better than 
in Flash 2.x.

> 2) would reducing mgrid_max_residual_norm (or using -O3 optimization)
> help?

It may hide the problem and will degrade quality of solution.

> PS: have I mentioned how bad ifort 8 is?... I guess I have. I was reminded
> of that again today, when I noticed yet again that that compiler messed up
> some results.

For me version 7 was unusable, 8 behaved suspiciously, 9 seemed to be usable 
until I run into some compiler bugs that messed up MPI communication, now I 
hope that 10.1 works well. In general Intel compilers are good because they 
produce fast executable but it is good to use other compilers and compare 
results from time to time.

-- 
Cheers,
        Artur