CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Bugs (https://www.cfd-online.com/Forums/openfoam-bugs/)
-   -   GGI changes, release 1165, 1170 and 1266 (https://www.cfd-online.com/Forums/openfoam-bugs/65257-ggi-changes-release-1165-1170-1266-a.html)

bastil June 10, 2009 03:38

GGI changes, release 1165, 1170 and 1266
 
Dear GGIers,

I have problems with running a case in my latest svn-Release (1266). I get exploding velocities at one of my ggis after just running a potentialFoam. PotentialFoam takes all its 100 Iters but does not converge. I have seen simular behavior in 1170.
Everything worked fine for this case in 1165 as far as I remember but I do not have this build available anymore. I have to check this back next week.

Are there changes between 1165 and 1170/1266 that might cause this? ggi-non-orthogonal-correction? non-orthogonal-correction at boundaries? Something else?

Regards BastiL

mbeaudoin June 10, 2009 08:54

Hello,

The ggi-non-orthogonal-correction is disabled by default, so you would need to explicitly enable this yourself in your main controlDict. If you did not, then you get the same behaviour as before, meaning no ggi-non-orthogonal correction.

The non-orthogonal-correction at boundaries is an "experiment" that Hrv decided to stop at revision 1238.

Martin

Quote:

Originally Posted by bastil (Post 218754)
Dear GGIers,

I have problems with running a case in my latest svn-Release (1266). I get exploding velocities at one of my ggis after just running a potentialFoam. PotentialFoam takes all its 100 Iters but does not converge. I have seen simular behavior in 1170.
Everything worked fine for this case in 1165 as far as I remember but I do not have this build available anymore. I have to check this back next week.

Are there changes between 1165 and 1170/1266 that might cause this? ggi-non-orthogonal-correction? non-orthogonal-correction at boundaries? Something else?

Regards BastiL


bastil June 10, 2009 09:03

Quote:

Originally Posted by mbeaudoin (Post 218818)
Hello,

The ggi-non-orthogonal-correction is disabled by default, so you would need to explicitly enable this yourself in your main controlDict. If you did not, then you get the same behaviour as before, meaning no ggi-non-orthogonal correction.

I see. By default I had it set to "0" in my controlDIct. It should give me save behaviour as 1165, but I think it does not. As I mentiond before I have to re-install 1165 to check back next week...
I tried "1" instead (does it mean one corrector step or on?), however I get bad behaviour for both cases.
Quote:

Originally Posted by mbeaudoin (Post 218818)
The non-orthogonal-correction at boundaries is an "experiment" that Hrv decided to stop at revision 1238.
Martin

Ok, thanks. I will get back to you as soon as I am sure it runs with 1165 or not.

Regards.

mbeaudoin June 10, 2009 10:18

Quote:

Originally Posted by bastil (Post 218821)
I see. By default I had it set to "0" in my controlDIct. It should give me save behaviour as 1165, but I think it does not. As I mentiond before I have to re-install 1165 to check back next week...
I tried "1" instead (does it mean one corrector step or on?), however I get bad behaviour for both cases.

Regards.

No no, this flag is just a boolean flag to enable/disable the non-orthogonal correction on the GGI interface.

And it is set at false or 0 by default.

If your mesh is not skewed on each side of the GGI interface, you should not see any significant impact from this feature, enabled or not.

Martin

bastil June 10, 2009 10:35

Quote:

Originally Posted by mbeaudoin (Post 218832)
If your mesh is not skewed on each side of the GGI interface, you should not see any significant impact from this feature, enabled or not.

Martin,

thanks. that is what I also found, no difference. After you modified the code i know which of my interfaces give me the warnings. One of these is the one with the exploding velocities after potentialFoam:

Evaluation of GGI weighting factors:

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 533
Uncovered faces found. On master: 0 on slave: 445
Largest slave weighting factor correction : 0.999925 average: 0.0204606
Largest master weighting factor correction: 0.650792 average: 0.0224402

I know I had the same model running before (I think it was in 1165), I have some log-Files. I tried under-relaxing velocity but that does not seem to help at all - I can neither run potentialFoam nor simpleFoam for one iteration without these "velocity-peaks". Currently I have no idea about that.

bastil June 16, 2009 07:39

Ok sorry guys I ran into the same behaviour with 1165 - the problem must be somewhere else but I don't know where. I had it running once...
I get exploding velocity values (about 200 times higher than expected) at some of my interfaces after running potentialFoam on my case. I guess this is a initialization problem. Is it recommended to initialise the ggis with velocity "uniform (0 0 0) " or not. I got it running with none of them. I also tried strong unterrelaxation of my case without success. Where could this problem come from and how can it be solved? Thanks.

Regards BastiL


All times are GMT -4. The time now is 00:50.