[asaha]

Musa:

(1) Pick up patch like wall - not internal mesh
(2) If your are using paraview 3.3 you get the plot over line with some default coordinates which you can change
(3) You may not get gamma=0.5 if you are at time step 0, so take some higher time step or you may remove the available entry of gamma and add a new value of gamma=0.5
(4) When you apply the integrate variables from filters menu you will see some data displayed in a spreadsheet which may not be useful so keep the Contour1 flag visible by making the data visible (eye) - just above IntegrateAttributes1. When you make this you will observe change in the data in spreadsheet which is the one required.
(5) Select a row in the spreadsheet with mouse to highlight and then plot selection over time from filter menu. But before you apply you must copy the active selection which you can see below the apply button. Then apply to get the displacement with time.

[musahossein]

Gentlemen:

Can someone direct me to where mesh refinement is performed. For example if I want mesh refinement at say evey 5th timestep,then where in the documentation is this discussed or where do I need to put this info?

Also where is cell expansion discussed? Does cell expansion mean the originial cells are being increased in size or is it implying mesh refinement, ie, more cells are being added?

Comments appreciated! Thanks
Musa

[pbohorquez]

Replace

functionObjectLibs("libsampling.so");

by

functionObjectLibs ("libsampling.so");

Please note the blank space.

If you were also interested in indicating the number of iterations between one probe and the next one, add this line:

// E.g. write probes each 10 iterations
interval 10;

Cheers
Patricio

[lin]

Hi
just read musaddeque's post.I have one question.In his post:


// Name of the directory for the probe data
name probes;

I could find these lines in the interDyMFoam tutorial case.From the comment it seems that it is related to the output.

while from the source code,it seems that it is exclusively used by sampledSurface,not related to output.

could somebody make me clear?

[musahossein]

patrico:

Many thanks for pointing out the error!. The block mesh and set fields now run without a problem. However, when I execute interFoam, the following error is sent to the screen:

time step continuity errors : sum local = 0, global = 0, cumulative = 0
DICPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Courant Number mean: 0 max: 0

Starting time loop

Courant Number mean: 0 max: 0
deltaT = 0.00119048
--> FOAM Warning :
From function probes::read()
in file probes/probes.C at line 72
Did not find location (0.035 0.01 0.05) in any cell. Skipping location.
Time = 0.00119048

The analysis continues and the probe file records the same gamma value for each time step. This should not be the case since the gamma will be a 1 or 0 depending if there is "water" on the probe or "air" as the water sloshes over the probe.

However, the probe point is right at the phase interface - between the water and air (I am running the damBreak problem). How am I supposed to figure out whether this point is in a cell or not?

Any suggestions?

Musa

[pbohorquez]

checkMesh -case damBreak =>

Checking geometry...
Domain bounding box: (0 0 0) (0.584 0.584 0.0146)

Your error:

Did not find location (0.035 0.01 0.05) in any cell.

I would say that 0.05 > 0.0146, i.e. your probe is out of the computational domain.

[musahossein]

Patrico:

Sorry - I hade made modifictions to the box geometry as follows:

convertToMeters 0.01;

vertices
(
(0 0 0) // 0
(14 0 0) // 1
(14 10 0) // 2
(0 10 0) // 3
(0 10 0.1) // 4
(0 0 0.1) // 5
(14 0 0.1) // 6
(14 10 0.1) // 7
);

Based on above the probe location of 0.035, 0.01 and 0.05 should be within the box. let me know what you think. Thanks,
Musa

[pbohorquez]

I wonder if you have already read the User Guide?

5.3.1 Writing a blockMeshDict file

The blockMeshDict file is a dictionary using keywords described in Table 5.5. The convertToMeters
keyword specifies a scaling factor by which all vertex coordinates in the mesh description
are multiplied. For example,
convertToMeters 0.001;
means that all coordinates are multiplied by 0.001, i.e. the values quoted in the blockMesh-
Dict file are in mm.

In your case, 0.01*0.1=0.001 < 0.05.

[musahossein]

Patrico:

You were right about the error. Many thanks.

Musa

Time = 0.0038

Courant Number mean: 2.09671 max: 1060.3
DILUPBiCG: Solving for Ux, Initial residual = 0.919624, Final residual = 1.67874e-06, No Iterations 37
DILUPBiCG: Solving for Uy, Initial residual = 0.901699, Final residual = 2.47234e-06, No Iterations 36
DILUPBiCG: Solving for Uz, Initial residual = 0.938489, Final residual = 4.1829e-06, No Iterations 36
DICPCG: Solving for p, Initial residual = 0.879601, Final residual = 0.00364827, No Iterations 1001
time step continuity errors : sum local = 0.0259577, global = 9.6956e-08, cumulative = 3.94409e-06
DICPCG: Solving for p, Initial residual = 0.666183, Final residual = 0.000557632, No Iterations 1001
time step continuity errors : sum local = 0.0113467, global = 8.28394e-06, cumulative = 1.2228e-05
DILUPBiCG: Solving for T, Initial residual = 0.64382, Final residual = 6.68318e-08, No Iterations 59
ExecutionTime = 378.29 s ClockTime = 381 s

Time = 0.0039

Courant Number mean: 9.857 max: 30723.2
DILUPBiCG: Solving for Ux, Initial residual = 0.992898, Final residual = 7.52633e-06, No Iterations 52
DILUPBiCG: Solving for Uy, Initial residual = 0.990041, Final residual = 4.81015e-06, No Iterations 55
DILUPBiCG: Solving for Uz, Initial residual = 0.995945, Final residual = 7.08196e-06, No Iterations 51
DICPCG: Solving for p, Initial residual = 0.943505, Final residual = 0.00279098, No Iterations 1001
time step continuity errors : sum local = 0.133287, global = 0.000834918, cumulative = 0.000847146
DICPCG: Solving for p, Initial residual = 0.511564, Final residual = 0.000185419, No Iterations 1001
time step continuity errors : sum local = 0.0590576, global = -0.0111944, cumulative = -0.0103473
DILUPBiCG: Solving for T, Initial residual = 0.906877, Final residual = 6.47856e-08, No Iterations 76
ExecutionTime = 392.06 s ClockTime = 395 s

Time = 0.004

Courant Number mean: 114.419 max: 474556
DILUPBiCG: Solving for Ux, Initial residual = 0.997831, Final residual = 5.29673e-06, No Iterations 199
DILUPBiCG: Solving for Uy, Initial residual = 0.995946, Final residual = 2.97571e-06, No Iterations 208
DILUPBiCG: Solving for Uz, Initial residual = 0.997078, Final residual = 7.97488e-06, No Iterations 198
DICPCG: Solving for p, Initial residual = 0.967972, Final residual = 0.244505, No Iterations 1001
time step continuity errors : sum local = 357.75, global = -0.0473633, cumulative = -0.0577106
DICPCG: Solving for p, Initial residual = 0.43629, Final residual = 0.000865386, No Iterations 1001
time step continuity errors : sum local = 78.2216, global = -0.0380752, cumulative = -0.0957858
DILUPBiCG: Solving for T, Initial residual = 0.96816, Final residual = 8.15618e-08, No Iterations 88
ExecutionTime = 411.14 s ClockTime = 414 s

Time = 0.0041

I have such a problem that courant number increasing after a while...I can t find out the problem...I have decrease time steps and it is working longer but again crash...
can someone help me?

best regards

emo

[ngj]

Hi Emo

This is not an interFoam-related question, as you are using a different solver. Thus please use approapriate threads in the future. Further, when you are not informing which solver you are using, you cannot expect qualified help.

Your timestep must be too large, thus either adjust your solver to use a Courant-limited timestep or lower your time step. If that is not helping, there might be problems with your mesh and/or initial conditions/BC.

Best regards,

Niels

hi Niels,

Sorry about that,I see...
I am using turbFoam and I have include transport equation but there is something wrong...

I can t find out...

regards

Emo

[marc_w]

Dear users

I have a question relating to the simulation of a 2-phase flow using the interFoam solver. My problem consists of a gravity driven liquid film falling down a vertical wall in a quiescent gaseous atmosphere. Due to its instability the falling film develops surface waves which in their developed state cause the velocity and pressure distribution in the liquid phase to be periodic in streamwise direction (the periodicity of pressure is due to the fact that the film is driven by gravity and not by pressure). As I'm focusing on the developed state of the film I'm simulating only one surface wave using a cyclic boundary condition in streamwise direction. My computational domain has a length of one wavelength. I have previously simulated the full film with interFoam under the given conditions and have therefore a pretty good understanding of what the flow should look like.

In the simulation with the cyclic boundary condition I have observed that the face values for pd on the cyclic boundary differ considerably for the cells on either side of it. Indeed, the data files for pd contain a list of values associated with the cyclic boundary with a length of two times the amount of faces on that boundary. As far as I can tell this list is not one of matching value pairs. The same is true for the values of the other variables U and gamma although the difference between values associated with different sides of the cyclic boundary is smaller. Further, I observe an abrupt pressure change between the last interior cell face and the corresponding face on the cyclic boundary for both "sides" of the domain. This erroneous pressure distribution is causing dynamics that do not correspond with the simulation of the full film. I assume that the cause of this problem is the use of a cyclic boundary condition. I would be grateful for any help in this matter.

Yours faithfully

Marc

[pbohorquez]

Dear Marc

are you simulating Kapitza instabilities?

For sake of simplicity, we must first think in the uniform stream falling down the vertical wall. The momentum equation along the direction of the gravity (z) establishes that the vertical gradient of the reduced pressure (pd) is balanced with the viscous forces, where the reduced pressure is related with the absolute pressure (P) by pd = P - rho g z. I mean, the reduced pressure is not periodic, but the absolute pressure. interFoam solves pd, not P!

Good luck
P

[marc_w]

Dear Patricio

Thank you for your swift reply. Yes I am simulating Kapitza instabilities.

Your remark about the definition of pd was most helpful. I have checked the data files for pd and p and observed that the cyclic condition is applied to the variable pd which leads to a jump in p over the cyclic boundary. Is there a way to explicitly or implicitly achieve that the cyclic condition is applied to p and not to pd?

Yours sincerely

Marc

[ep4]

Hi,

i'm also very interested in the question of Marc Wainwright: "Is there a way to explicitly or implicitly achieve that the cyclic condition is applied to p and not to pd?".

Any idea?

Thank you

Eric

[pbohorquez]

You just need to re-write the PISO-Loop as a function of p instead of pd. This means that the flux prediction in pEqn.H is to be modified, as well as the momentum predictor in UEqn.H, replacing -ghf*fvc::snGrad(rho) by the discretisation of rho*g.

[ep4]

Hi,

thank you for the answer. If i have well understood what you said, as the PISO loop is now done (based on pd), i could impose a non cyclic boundary condition to the p field only. However, when trying it just as a test, i receive the following error, due to the fact, i think, that i declare not a patch but cyclic in my blockMeshDict file:

inconsistent patch and patchField types for
patch type cyclic and patchField type calculated

file: /net/ric_home/ep4/OpenFOAM/ep4-1.5/run/free_convection_channel/Mesh_coarse/0/p:: inout1 from line 47 to line 48.

From function fvPatchField<type>::New(const fvPatch&, const DimensionedField<type,>&, const dictionary&)
in file /home/dm2/henry/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude/newFvPatchField .C at line 140.

FOAM exiting

Is there something else i should also do?
If i want a steady solution, have you advices? How modify the SIMPLE alogorithm or something else?

Thank you

Eric

[ep4]

Hi,

Any comment on my previous post ? It could be really interesting for to be able to impose a cyclic boundary condition for all fields, except for the pd field.

Thank you

Eric

[chegdan]

Eric,

I have pondered over this before and there is a limitation in OF (in my humble opinion) that If you define a patch as cyclic then you cannot use a non-cyclic patch type on another field. OF sees that you are trying to do this and spits out some errors, as it should. i have seen posts that discuss options to fix this, but they seem somewhat difficult. personally I see some utility in allowing a patch to be cyclic in some equations and non-cyclic in others. For instance once might want cyclic flow (momentum only) and watch the evolution of heat in the system by no cyclic behavior. Solving this type of problem is of great importance to my thesis and I will pick this up after the hollidays and try to figure it out.

Dan