[FLASH-USERS] V-cycle not converging

[Seyit Hocuk]

Thanks Artur,

Your mail explained a lot to me.

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.


That makes a lot of sense to me, because I may derefine very 
aggressively. I'm gonna check that.

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.


I have to mention that I did a basic and a simple jeans and sedov test 
comparing flash 2.5 and 3.0. Flash3 was slower in finishing the 
simulations. I did assume that both the standard setups and parameters 
stayed the same.

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.


Glad to hear that I am not the only one who had bad experiences with 
older versions of ifort. Ifort 10 seems to work good though.


Thanks again Artur.

Seyit




Artur Gawryszczak wrote:
> 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.
>
>