[maka]

Collapsed fields does not correspond to averaged fields:

After running the channelOodles tutorial case:

I used postChannel . channel395, then printed Uf.xy. I noticed that y coordinates goes from 0 to 1 and then repeates. Also if one assumes that this is just repeated answer and plots half of Uf, the max Uf will not be in the center of the channel. I checked the Umean field with paraFoam, it looks OK. I'm using V1.3. I do not remember that I faced such problem was in V1.2. Here a print of Uf.xy:


0.00480001 0.0820381
0.0148983 0.0942319
0.026045 0.103695
0.0383488 0.109816
0.05193 0.114243
0.066921 0.117896
0.0834683 0.120942
0.101734 0.123414
0.121895 0.125268
0.144149 0.12659
0.168714 0.127447
0.195829 0.127924
0.225758 0.128054
0.258795 0.127855
0.295262 0.127342
0.335514 0.126465
0.379945 0.125109
0.428988 0.123146
0.483123 0.120553
0.542878 0.117418
0.608836 0.113751
0.681641 0.109467
0.762005 0.103566
0.850711 0.0944171
0.948626 0.082215
0.00480001 0.0820465
0.0148983 0.0942416
0.026045 0.103699
0.0383488 0.109808
0.05193 0.114224
0.066921 0.117868
0.0834683 0.120902
0.101734 0.123356
0.121895 0.125225
0.144149 0.126577
0.168714 0.127445
0.195829 0.12792
0.225758 0.128056
0.258795 0.127889
0.295262 0.127394
0.335514 0.126485
0.379945 0.125095
0.428988 0.123128
0.483123 0.12054
0.542878 0.117414
0.608836 0.113739
0.681641 0.109452
0.762005 0.103563
0.850711 0.0944225
0.948626 0.082224

[mattijs]

postChannel only supports a block-structured mesh. (it uses i,j,k addressing). There is no real difference between 1.2 and 1.3 version. Can you find out what goes wrong in your case?

[maka]

I reproduced the same error in the standard tutorial case. You can run the standard case and wait till time is 1000 or to save some time by changing system/controlDict:

endTime 1;

writeInterval 1;

then run postChannel. Offcourse the avarage will not be a converged statistics but I will show the same kind of error.

then run postChannel and check Uf.xy, it should have the same problem.

both the location and value of Ufmax is not right. max(Uf) = 0.124 at y=0.25 while by looking at the avaraged field Ufmax aprox= 0.169 at y=1.

I think it is a bug, what do you think? I'm trying to figure out what went wrong by looking into postChannel code.

Best regards,
Maka

[maka]

I check V1.2:

It gives the same incorrect result as V1.3.

/Maka

[maka]

Problem solved:
http://www.cfd-online.com/OpenFOAM_D...tml?1165923342
/Maka

[maka]

I was asked by a colleague here to post the solution of the above problem since he faces the same problem and the solution link is dead!

Usually you get a strange collapsed field when you have the postChannel dictionary specifid in a way that is not consistent with your blockMeshDict. That is very common to happen, since you modify the mesh and forget to modify the postChannelDict.

The default postChannel dictionary in V1.3 was:

Nx 40;
Ny
(
50
);
Nz 30;


it should be:

Nx 40;
Ny
(
25
25
);
Nz 30;

I posted a message with the error as a bug in the tutorials, and the message was removed from bug forum, which means that most probably that was correction in V1.4 tutorials. Thanks.

Best regards,
Maka

[cedric_duprat]

Hi OpenFoamers,

I've got a strange problem with the postChannel tool.
my Uf.xy looks like that :
0.00161998 0.106685
0.00161998 0.105999
0.00161998 0.107449
0.00161998 0.107636
0.00161998 0.108684
0.00161998 0.107099
0.00161998 0.106488
0.00161998 0.107975
0.00161998 0.108357
0.00161998 0.109163
0.00161998 0.107461
...

my channel mesh is coming from Gambit (may this be the problem ?)

Of course I corrected the postChannelDict with the right value. I checked with the checkMesh the number of cells, points, ... it seems to be ok ...
I don't know if it is require but in spanwise direction I've got 2n+1 points

well, if someone has an idee, I'll be greatfull cause I've haven't got anymore now.

Thanks

Cedric

[maka]

To my knowledge postChannel is written to process fields under the following constrains:

1) uniform dx, dz.

2) multi-blocks are only used in y direction.

3) "the mesh is made by blockMesh".
This was implied from the following code. the implementation of operator(...) member function that postChannel relays on to get cell ID imply some rules about how cells are ordered in x,y,z. This most probably matches blockMesh way of doing the job. If you want to start modifying postChannel, that is where you should look.

channelIndex::operator()
scalarField channelIndex::y()

look at channelIndex.C in postChannel src folder. I hope that helps.

[cedric_duprat]

Hi Maka,
thank you for your answer.
so, in my case:
1- is ok
2- also
3- ..... because I'm using a gambit mesh I get such problems ?

I'll try to see again what happened in channelIndex.C :o), or re-create my mesh using blockMesh.

My last question is nobody tryed postChannel with a mesh which is not coming from blockMesh ?


Regards,

Cedric

[maka]

My experience is that there are few people out here that use postChannel. I use it frequently but always with blockMesh. Sorry, I did not try it with other mesh generators but if the other mesh respect the implied ordering of the cells as described by operator() member function, it may work.

I guess it would be easier to generate your mesh with blockMesh than to control the output format of you mesh generator. This makes sense since postChannel works only on plane channel flow for which blockMesh is a good option. Have a nice day!

Best regards,
Maka.