[david]

Hi everybody

I could read in the forum that the GGI interface shouldn't be used at the moment as the weighting factor calculation is still under development:

http://www.cfd-online.com/OpenFOAM_D...es/1/5967.html

As im very interested in the GGI interface, I made a test with the ERCOFTAC diffuser:

http://openfoamwiki.net/index.php/Si...nical_diffuser

I modified Case0 and defined two patches and a GGI interface at cross-section B (Case0.1). The interface is the only difference, all other parameters remained unchanged. Here are the results:

ERCOFTAC_U.tar.gz
ERCOFTAC_k.tar.gz

The results show that the GGI interface induces an error which has a significant effect on k. Further downstream the difference between the two cases is surprisingly high if we consider the fact that the boundaries were conformal. Is this error resulting from the computation of the weighting factors? What is the problem with the actual implementation of the weighting factor calculation and how can it be improved? Would it be possible to get better results by adjusting the tolerances (GGImaxIter, GGIAreaErrorTol and GGISumFacetTol)?

I tried to understand how the GGI is working but wasn't very successful. I found that weights are computed at two different places. One is the member function makeWeights in ggiFvPatch and the other location is in the private member function calcAddressing in GGIinterpolation. Does anybody understand the difference between the two weights and the connection between them?

Thanks a lot
david

[cedric_duprat]

Hi David,

1- I will be interrested to see your plot of k a the different probes sections.

2- did you try to run the case without your GGI interface ? results are diferent ?

I ask these questions because I had also significant difference between my k and experimental the one. It seem that initial value for k and epsilon are realy important. ( See M. Page answer there : http://www.cfd-online.com/OpenFOAM_D...es/1/6714.html )

so, maybe, the effect of k is not comming from your method but, form your initial value.

.... but, it's just a guess.

I hope it can help you.

Cedric

[david]

Hi Cedric

The files contain all the plots from the automatic postprocessing comparing the measurements with the original case (Case0) and the GGI case (Case0.1). The results are different.

The initial values are loaded in both cases from OFturboWGcase0.csv and use MuT/Mu=14.5. That means that the difference is really coming from the GGI.

Regards
david

[mbeaudoin]

Hello David,

I have been working on the GGI interface quite a lot recently, and the ERCOFTAC conical diffuser from the Turbomachinery group is one of my test case.

I will be showing my current results on the GGI development at the Third OpenFOAM Workshop in Milano next week, so if you plan to attend, we can discuss about this some more.

In the mean time, I can provide you with some remarks.

There are some internal adjustments that need to be made in the GGI source code when placing a GGI right at cross-section B for Case0; the geometry of the cells on each side of the GGI is a factor here.

So even with a conformal mesh, the actual implementation of the GGI will not work when placing such an interface at section B for Case0. I initially had the same results as you.

Another problem with the current implementation of the GGI is that the determination of the patch faces "neighborhood" on each side of the GGI does not always work well.

So if you plan to use the GGI with the ERCOFTAC conical diffuser O-grids geometry and with non-conformal meshes, you might end up with some problems.

You could try to switch to Case1 instead and put a GGI at cross-section B. The results might be better than Case0 with a conformal mesh, but if you modify Case1 to use non-conformal meshes, which is why you want to use a GGI in the first place, then you will likely ran into the "neighborhood" determination problem.

So far, I have achieve some pretty interesting results with my current implementation of the GGI, which is based on Hrv's initial version.

I plan to release my source code on openfoam-extend, but I still have some work to do before going there.

Martin

[david]

Hi Martin

Thank you very much for your interesting explanations. In a turboWG mail, that was sent a month ago, was already mentioned that the crucial points are the robust determination of the cell neighborhood on each side of the GGI interface, and also the computation of the weighting factors. But it's always interesting to receive more detailed information.

Unfortunatelly I will not participate in Milano. But my supervising tutor will be there and I hope that he will come back with a lot of interesting information ;-)

Regards
David

[david]

Hi Martin

I dealt further with the GGI interface and I hope that I was able to find the problems you mentioned. But I have still some questions and would like to ask you whetver I understood everything correctly.

----------------------------
Neighbourhood:

The neighbourhood of a cell face is searched from its face center which can lead to wrong results. For a nonconformal interface it's possible that the connections M1-S1 and M2-S2 will be found, but not M1-S2. Under certain conditions it can occur that even the neighbourhood enrichment doesn't find the connection M1-S2.



----------------------------
Weights:

The calculation of the weights uses the full area of the neighbour cell's contact face. In the following example, the MasterWeights are

w0=Area(S0)/(Area(S0)+Area(S1))
w1=Area(S1)/(Area(S0)+Area(S1))



Isn't that wrong? If we would consider only the real contact area, then we would get different values.

----------------------------
Reconstructed Cell Centres:

Reconstructed cell centres are used for the discretization. If we have a conformal grid, then the reconstructed cell centres are identical to the real cell centres. But where exactly is the error produced in the ERCOFTAC case. Do we need more than a non-orthogonality correction to avoid this problem?

Thanks a lot
david

[david]

Sorry, I made a mistake. I wanted to say that the connection S1-M2 will not be found (and not M1-S2).

Regards
David

[david]

Unfortunatelly I overlooked that the reconCtrs are not identical to the real cell centres for a conformal interface. I changed that and implemented a non-orthogonality correction on the GGI interface. The results are equal to the simulation without GGI. Can this procedure lead to any disadvantages when we use non-conformal interfaces?

regards
david

[david]

Hello

I tried to improve the computation of the weights and implemented a clipping algorithm for the determination of the intersection areas. A first version of the algorithm computes the correct weights for a conformal interface and seems also to work well for non-conformal interfaces.

Tests on Case1 with block AB rotated by 15° and a GGI at cross section B showed good results. Case1 was presented in this form by Martin & Prof. Jasak as validation testcase for the GGI at the 3rd OF workshop. With the already mentionned modifications I get also nice results for Case0 with a conformal interface.

Unfortunately I get still wrong results in Case0 with a non-conformal interface. If the geometry of the cells is a factor here, does this mean that the error comes from the position of the reconstructed centres? How else could the form of the cells affect the solution? And how would it be possible to fix this problem? Any help is very appreciated.

Best regards
david