As I said: if you think it is
 

As I said: if you think it is legal that in your geometry you have uncovered faces on the GGI interface, please use bridging: it will do what is necessary.

If you think the interface should be completely covered, set bridging to off. If you get the message, there is something wrong with your setup and you need to investigate by hand.

Clear?

Hrv

Ok I see, thanks. In this case
 

Ok I see, thanks. In this case it is legal so I switched and I get:

Attempt to cast type wall to type lduInterface
From function refCast<to>(From&)

Seems like there is something wrong with my bc?

Regards

Great, works. Thanks Hrv for y
 

Great, works. Thanks Hrv for your help once more. One ggi was still of type "wall".

Regards.

Happens to me as well - readin
 

Happens to me as well - reading the error message (however obscure) will usually help.

Enjoy,

Hrv

Hrv, finally I want to guid
 

Hrv,

finally I want to guide you to my add-on:

http://www.cfd-online.com/OpenFOAM_Discus/messages/126/11626.html?1236852411#POST3342 1

It helps do identify the problems.

Regards

Hrv, all: I still have trou
 

Hrv, all:

I still have troubles in runnig it on a cluster. On my workstation it runs on one cpu as well as on two, but on the cluster I get floating point errors.
I guess this has to do with parallelisation, I am unsure about how to do it. My first guess for decomposeParDict was:

preservePatches (patch1 patch1_shadow);
preservePatches (patch2 patch2_shadow);
preservePatches (patch3 patch3_shadow);

But obviously this is not the right way decause decomposePar complaines. So what I do now is:

preservePatches (patch1 patch1_shadow
patch2 patch2_shadow patch3 patch3_shadow);

Feedback now looks as expected but I get floating point exceptions. And ideas?

Regards

Well, unless you finished off
 

Well, unless you finished off the parallelisation while I wasn't looking, this should not run (ie. it is dependent on the decomposition). There is still 1-2 bits to implement - you are basically trying to run in parallel without parallel action on GGI.

Wait for it a bit more, I working on this.

Hrv

Ok so just choosing preserve p
 

Ok so just choosing preserve patches does not make sure it will run? And if it runes I had luck, right?

Thanks once more and regards.

BastiL

Hi BastiL, Your problem sou
 

Hi BastiL,

Your problem sounds to me like you have cyclics (cyclicGgi) in more than 1 direction, maybe even in all directions?

One "quick and dirty" solution for now is using preserveFaceZones (instead of preservePatches). preserveFaceZones should be used in that way that there exist a thin cell layer at the cyclics. (via faceSet and setsToZones).

Jens

Jens, I don't have cyclics
 

Jens,

I don't have cyclics just "traditional" non-conformal interfaces. However, your waorkaround may help me. Can you please give me some details about how to create these FaceZones? Thanks.

BastiL

Ok so what I tried is to creat
 

Ok so what I tried is to create faceZones using setSets. I put patch1 and patch1_shadow into one face zone. So I get 5 face zones for my 10 patches that form 5 ggis. However, I get the same behaviour as before. How do you handle this, Jens?
Seems like there are some other things going on regarding parallelisation.

Regards BastiL

Bastil, did you get your decomposition to preserve both sides of the entire GGI interface?

Kevin