[Bahram]

Dear foamers

Hi

I was checking the pitzDaily case included in pisoFoam tutorials, the only change which I did was changing the "writeInterval" from 100 to 1 to see the results at first time step. Surprisingly the velocity values in the first cell after velocity inlet are half of the boundary and also next cell values (attached picture) . I checked the same case with pimpleFoam and also a very simple solver which just solves pressure and velocity coupling, the same thing happens. This error fades during time (after a few time steps, in the pitzDaily case after about 50 time steps). Any idea about what is happening here is appreciated.

Pictures:
First time step:
http://therm.vt.tuwien.ac.at/tvtclou...1858ba2fe89e79
After 100 time steps:
http://therm.vt.tuwien.ac.at/tvtclou...29e3dd951f9be9

Bests
Bahram

[Bahram]

Am I the first one who faced this ?

[vatavuk]

Hi Bahram,
I also saw something like that. Paraview uses the stored values for the internal field and for the patches. If you compare the U files in the 0 directory and in the others, you will notice that the inlet patch information is stored in a different way in the 0 directory. It seems that Paraview is not being able to interpret correctly this information.
To get the correct values you could use the sample utility.
Best Regards,
Paulo

[Bahram]

Dear Paulo

Thanks for your idea. but the thing is that even if you check the U file of the first time step, you will see the values on the inlet patch are 10, in the cells next to patch are around 5, and in the second row of cells after after patch the values are very close to 10. so there is flactuation in these values 10-5-10 ??? That is what I don't understand. I also checked this with a very simple case, with a few number of cells.

Bests
Bahram

[vatavuk]

Hi Bahram,
So the problem that you are referring happens in directory 1 not 0 as i thought. In that case you have to consider that PisoFOAM can give a solution that is not time accurate depending on time interval that you are using. This is a characteristic of the PISO algorithm. If you want a correct solution for 1 second you should decrease the time step ( use 0.5, 0.25, 0.125 and so on) until you notice that the solution for 1 second is not affected anymore by the time step. For a time accurate solution without using very small time steps you may consider using PimpleFOAM.
Best Regards,
Paulo

[Bahram]

Again thanks! But I also tried it using pimpleFoam and also with smaller time stepping (1e-6), and the results are the same. The error exists in the first time steps and then fades. The strange thing is that these values are some how exactly half of boundary and adjacent cell values???!!!

[Blanco]

I think what you get in this case it's due to initial conditions and time discretization used.

If you try to initialize the velocity field with (10 0 0) you will get correct value of velocity in the first cell next to inlet boundary, even at the first iteration.

Basically I think there is a sort of "first order" approximation of the correct velocity value next to the boundary, due to a poor init. and the specific time scheme. The effect of this error disappear as the simulation goes on.

Best

Andrea

[Bahram]

Dear Andrea

Thanks for suggestion, but I have a fluctuating boundary with high frequency, so all the time the value from boundry is different from internal field, therefore I cannot wait for field to get stable!!! Any other ideas or any suggestions regarding schemes to improve it?

Best regards
Bahram

[Blanco]

Hi Bahram,

I think that the problem is very limited to first time-step only, because of the backward time scheme which should try to read at the two previous time level, even if they are not available...you have only the 0 time available indeed at the beginning.

After the first time-step, you get the 2nd order accuracy of the implicit backward time scheme.

I think you would have a real fine mesh near the boundary if you want to catch the high frequency variations coming from it, otherwise the fluctuation will be missed/smeared in the domain.

Best,

Andrea

[Bahram]

As I mentioned in the first post, the error don't disappear after first iteration it needs a few iterations (in this case 50) to disappear. Even with very fine mesh exactly the same effect exists

Best regards
Bahram