[bendel_boy]

Settling tank.

Instead of a feed pipe discharging into a centre well, and the centre well discharging c. 50% of the tank depth, the inlet is mounted on the floor, and takes up c. 1/8 of the tank radius at the inlet. The effluent leaves by a weir, also 1/8 of the tank radius at the periphery, and diametrically opposite to the inlet. Sludge takeoff is near the centre, and again diametrically opposite the inlet.

The system is supposed to promote flow distribution.

Untitled.png

[bendel_boy]

I used as my coordinates (X Y Z). while settlingFoam normally uses (X Z Y) - just had to change the directed vector for g and the settling velocity to correct for this.

[RodriguezFatz]

It's hard for me to check the settings from your files, because I don't know half of the technical terms you are using in your explanation. Also I don't know this special application "settling tank". To me it looks strange that you only use fixedValue velocity boundary conditions. I thought this is numerically unstable and you normally have at least one inlet or outlet with some zeroGradient velocity to get the correct mass flux. But as I said I can't say if it is ok here.
Also, for checking the inlet vector directions I need a sketch with a coordinate plane.

[bendel_boy]

settlingFoam was created to model the conditions in a settling tank. A conventional settling tank looks like this


Mine differs in that it is not axi-symmetric; both outlets take up 1/8 of their respective circumference, as does the inlet. And the inlet is floor-mounted, rather than at c. 1/2 depth and the cascading down into the tank.

I have tried with one outlet set to pressureInletOutletVelocity. This failed with an accumulating mass defect. Only by setting the velocity at the two outlets to ensure that I had volumetric outflow equalling volumetric inflow did I get a simulation that did not crash.

The image shows a slice from the blockMesh created grid. Not sure why the blocks are split up as triangles. I can post the blockMesh file.

[bendel_boy]

FoamFile
{version 2.0;
format ascii;
class dictionary;
object blockMeshDict;}
convertToMeters 1.0;
vertices (
( 0.382683429610802 0.92387953365215 0.0) // 0
(-0.382683429610802 0.92387953365215 0.0) // 1
(-0.382683429610802 -0.92387953365215 0.0) // 2
( 0.382683429610802 -0.92387953365215 0.0) // 3
( 0.574025144416202 1.38581930047823 0.0) // 4
(-0.574025144416202 1.38581930047823 0.0) // 5
(-0.574025144416202 -1.38581930047823 0.0) // 6
( 0.574025144416202 -1.38581930047823 0.0) // 7
( 2.52571059893575 6.09760483399617 0.0) // 8
(-2.52571059893575 6.09760483399617 0.0) // 9
(-2.52571059893575 -6.09760483399617 0.0) // 10
( 2.52571059893575 -6.09760483399617 0.0) // 11
( 0.382683429610802 0.92387953365215 1 ) // 12
(-0.382683429610802 0.92387953365215 1 ) // 13
(-0.382683429610802 -0.92387953365215 1 ) // 14
( 0.382683429610802 -0.92387953365215 1 ) // 15
( 0.574025144416202 1.38581930047823 1 ) // 16
(-0.574025144416202 1.38581930047823 1 ) // 17
(-0.574025144416202 -1.38581930047823 1 ) // 18
( 0.574025144416202 -1.38581930047823 1 ) // 19
( 2.52571059893575 6.09760483399617 1 ) // 20
(-2.52571059893575 6.09760483399617 1 ) // 21
(-2.52571059893575 -6.09760483399617 1 ) // 22
( 2.52571059893575 -6.09760483399617 1 ) // 23
( 0.382683429610802 0.92387953365215 2.85 ) // 24
(-0.382683429610802 0.92387953365215 2.85 ) // 25
(-0.382683429610802 -0.92387953365215 2.85 ) // 26
( 0.382683429610802 -0.92387953365215 2.85 ) // 27
( 0.574025144416202 1.38581930047823 2.85 ) // 28
(-0.574025144416202 1.38581930047823 2.85 ) // 29
(-0.574025144416202 -1.38581930047823 2.85 ) // 30
( 0.574025144416202 -1.38581930047823 2.85 ) // 31
( 2.52571059893575 6.09760483399617 2.85 ) // 32
(-2.52571059893575 6.09760483399617 2.85 ) // 33
(-2.52571059893575 -6.09760483399617 2.85 ) // 34
( 2.52571059893575 -6.09760483399617 2.85 ) // 35
( 0.382683429610802 0.92387953365215 3 ) // 36
(-0.382683429610802 0.92387953365215 3 ) // 37
(-0.382683429610802 -0.92387953365215 3 ) // 38
( 0.382683429610802 -0.92387953365215 3 ) // 39
( 0.574025144416202 1.38581930047823 3 ) // 40
(-0.574025144416202 1.38581930047823 3 ) // 41
(-0.574025144416202 -1.38581930047823 3 ) // 42
( 0.574025144416202 -1.38581930047823 3 ) // 43
( 2.52571059893575 6.09760483399617 3 ) // 44
(-2.52571059893575 6.09760483399617 3 ) // 45
(-2.52571059893575 -6.09760483399617 3 ) // 46
( 2.52571059893575 -6.09760483399617 3 ) // 47
);
blocks (
hex (1 0 4 5 13 12 16 17) ( 4 4 4 ) simpleGrading (1 1 1)
hex (6 2 1 5 18 14 13 17) ( 4 4 4 ) simpleGrading (1 1 1)
hex (6 7 3 2 18 19 15 14) ( 4 4 4 ) simpleGrading (1 1 1)
hex (7 4 0 3 19 16 12 15) ( 4 4 4 ) simpleGrading (1 1 1)
hex (5 4 8 9 17 16 20 21) ( 4 4 4 ) simpleGrading (1 1 1)
hex (10 6 5 9 22 18 17 21) ( 4 4 4 ) simpleGrading (1 1 1)
hex (10 11 7 6 22 23 19 18) ( 4 4 4 ) simpleGrading (1 1 1)
hex (11 8 4 7 23 20 16 19) ( 4 4 4 ) simpleGrading (1 1 1)
hex (13 12 16 17 25 24 28 29) ( 4 4 4 ) simpleGrading (1 1 1)
hex (18 14 13 17 30 26 25 29) ( 4 4 4 ) simpleGrading (1 1 1)
hex (18 19 15 14 30 31 27 26) ( 4 4 4 ) simpleGrading (1 1 1)
hex (19 16 12 15 31 28 24 27) ( 4 4 4 ) simpleGrading (1 1 1)
hex (17 16 20 21 29 28 32 33) ( 4 4 4 ) simpleGrading (1 1 1)
hex (22 18 17 21 34 30 29 33) ( 4 4 4 ) simpleGrading (1 1 1)
hex (22 23 19 18 34 35 31 30) ( 4 4 4 ) simpleGrading (1 1 1)
hex (23 20 16 19 35 32 28 31) ( 4 4 4 ) simpleGrading (1 1 1)
hex (25 24 28 29 37 36 40 41) ( 4 4 4 ) simpleGrading (1 1 1)
hex (30 26 25 29 42 38 37 41) ( 4 4 4 ) simpleGrading (1 1 1)
hex (30 31 27 26 42 43 39 38) ( 4 4 4 ) simpleGrading (1 1 1)
hex (31 28 24 27 43 40 36 39) ( 4 4 4 ) simpleGrading (1 1 1)
hex (29 28 32 33 41 40 44 45) ( 4 4 4 ) simpleGrading (1 1 1)
hex (34 30 29 33 46 42 41 45) ( 4 4 4 ) simpleGrading (1 1 1)
hex (34 35 31 30 46 47 43 42) ( 4 4 4 ) simpleGrading (1 1 1)
hex (35 32 28 31 47 44 40 43) ( 4 4 4 ) simpleGrading (1 1 1)
);
edges (
arc 0 1 ( 0 1 0.0)
arc 1 2 (-1 0.0 0.0)
arc 2 3 ( 0 -1 0.0)
arc 3 0 ( 1 0.0 0.0)
arc 4 5 ( 0 1.5 0 )
arc 5 6 (-1.5 0.0 0 )
arc 6 7 ( 0 -1.5 0 )
arc 7 4 ( 1.5 0.0 0 )
arc 8 9 ( 0 6.6 0 )
arc 9 10 (-6.6 0.0 0 )
arc 10 11 ( 0 -6.6 0 )
arc 11 8 ( 6.6 0.0 0 )
arc 12 13 ( 0 1 1 )
arc 13 14 (-1 0.0 1 )
arc 14 15 ( 0 -1 1 )
arc 15 12 ( 1 0.0 1 )
arc 16 17 ( 0 1.5 1 )
arc 17 18 (-1.5 0.0 1 )
arc 18 19 ( 0 -1.5 1 )
arc 19 16 ( 1.5 0.0 1 )
arc 20 21 ( 0 6.6 1 )
arc 21 22 (-6.6 0.0 1 )
arc 22 23 ( 0 -6.6 1 )
arc 23 20 ( 6.6 0.0 1 )
arc 24 25 ( 0 1 2.85 )
arc 25 26 (-1 0.0 2.85 )
arc 26 27 ( 0 -1 2.85 )
arc 27 24 ( 1 0.0 2.85 )
arc 28 29 ( 0 1.5 2.85 )
arc 29 30 (-1.5 0.0 2.85 )
arc 30 31 ( 0 -1.5 2.85 )
arc 31 28 ( 1.5 0.0 2.85 )
arc 32 33 ( 0 6.6 2.85 )
arc 33 34 (-6.6 0.0 2.85 )
arc 34 35 ( 0 -6.6 2.85 )
arc 35 32 ( 6.6 0.0 2.85 )
arc 36 37 ( 0 1 3 )
arc 37 38 (-1 0.0 3 )
arc 38 39 ( 0 -1 3 )
arc 39 36 ( 1 0.0 3 )
arc 40 41 ( 0 1.5 3 )
arc 41 42 (-1.5 0.0 3 )
arc 42 43 ( 0 -1.5 3 )
arc 43 40 ( 1.5 0.0 3 )
arc 44 45 ( 0 6.6 3 )
arc 45 46 (-6.6 0.0 3 )
arc 46 47 ( 0 -6.6 3 )
arc 47 44 ( 6.6 0.0 3 )
);
boundary (
inlet {type patch;
faces ( (0 1 13 12));
}
outlet { type patch;
faces ((34 35 47 46));
}
sludge { type patch;
faces ((6 7 3 2));
}
surface { type patch;
faces (
(37 36 40 41)
(42 38 37 41)
(42 43 39 38)
(39 43 40 36)

(41 40 44 45)
(46 42 41 45)
(46 47 43 42)
(43 47 44 40)
);
}
);
mergePatchPairs ();

[RodriguezFatz]

I had a look at your fvSolutions and fvSchemes setting from post #7, with some ideas / hints:
1) All time discretization schemes in openFoam are implicit. Your change from Euler (it's "Euler backward") to Backward (it's "2nd order backward") does not mean you change to implicit.
2) The under relaxation is not correct here, I think. You use pimple in piso-mode, because you did not set nOuterCorrectors to something larger than 1 (you didn't set it at all and your log output shows that "1" is used). Now, without outer iterations you can not use under relaxation in time dependent schemes. But your declaration of under relaxation is also not correct, you force all equations to be under relaxed, also the final iteration of each time step (since you only have one iteration in piso-mode this one is spuriously under relaxed). Someone in this forum told me that your spelling
"U.*" 0.1;
is wrong as I wrote. You need to write
"U" 0.1;
But this correct spelling is only used if you also set nOuterCorrectors to some higher number.
It's hard to explain this in english, but if you didn't get it, just ask again.

[bendel_boy]

Thank you.

I will try with nOuterCorrectors = 3.

The "U.*" syntax I took from the tutorial files - on the basis of don't change things you don't understand. But the numerical values are doing something. With an 'under relaxation factor' of 1.0 I again get a crash. At 0.1 I don't. (This was running a different geometry, the classical circular settling tank geometry.)

I didn't realise that 'Euler' was implicit, rather than explicit. if that is the case then my benefits in stability when adding 'backward' as the solver and non-orthogonal PISO correctors is probably just the PISO correctors.

[bendel_boy]

I had some success at the weekend in getting predictions of the flow and concentration field that looked like my measurements.

https://www.youtube.com/watch?v=cCxUMRIEKjA

[RodriguezFatz]

Originally Posted by bendel_boy

The "U.*" syntax I took from the tutorial files - on the basis of don't change things you don't understand. But the numerical values are doing something.

Can you tell me which tutorial? I did find this syntax but only with a value of 1.0, which practically deactivates under relaxation.

Originally Posted by bendel_boy

With an 'under relaxation factor' of 1.0 I again get a crash. At 0.1 I don't. (This was running a different geometry, the classical circular settling tank geometry.)

Then reduce the time step until it works with 1.0.

[bendel_boy]

both tutorials.

dahl

and

tank3D

The time step is adjusted, so I am not sure how I increase the relaxation factor and reduce the time step. There is an entry for a timestep, but I think it is just the initial value.

[RodriguezFatz]

In your controlDict you have something like

adjustTimeStep  on;

maxCo           0.4;

maxDeltaT       1;

You can either just switch the adjustTimeStep off and keeping the deltaT value constant or you reduce the maxCo value.
With such a low Co value of 0.4, your simulation should normally run in PISO mode. Can you post the log output, where the simulation crushes without underrelaxation (= 1)?

[RodriguezFatz]

Originally Posted by bendel_boy

both tutorials.

dahl

and

tank3D

The time step is adjusted, so I am not sure how I increase the relaxation factor and reduce the time step. There is an entry for a timestep, but I think it is just the initial value.

Yes, but the value of under relaxation is "1.0", so it is not used at all.
I would deactivate it and try to get solver in PISO mode running.

[bendel_boy]

Will do. I'll post when I have made further progress

[omid_K]

hi
i want to simulate a 3D reservoir and i dont know what is the coeffs. of simple or general in relativeVelocityModel,can anyone help me?

[bendel_boy]

simple uses the Vesilind model.
general uses the Takacs model.

Looking at the source code, the standard settling model is recast (Vesilind) as

rho_w / rho x V0 x 10^(-a x volume fraction)

compared to the more usual

V0 exp(-a x mass concentration)

[omid_K]

dear Jeremy Dudley
thanks for your reply
my problem is that what is the amount of "a" for a sediment with volume concentration=0.0013 , mean diameter=89 micromete and rho=1500 kg/m3
i calculate terminal velocity V0 with equilibrium of drag and gravity forces
but i dont know how to calculate coeff. of general or simple model

[bendel_boy]

You appear to want to use a Stokes model (discrete particle settling), rather than a flocculating solids settling model.

There is probably somewhere in the openFoam library something that looks at Stokes/discrete particles.

With flocculant settling you need to locate data for your material, or have a sample to do some batch tests - Coulson and Richardson has suitable procedures; Volume II at the third edition, but material has been re-arranged and may now be in Volume I; or you have a correlation. For activated sludge systems there are such correlations; Brennan worked on activated sludge, so there was no problem for the original problem domain.

[omid_K]

thanks again for your reply
at the present i have a problem in boundary condition for U,p_rgh,K and epsilon
i just want to know which boundary condition is suitable for surface of water in contact with air
in driftfluxfoam

[bendel_boy]

The bulk of the modelling work for clarifiers has assumed a symmetry plane for the air/water interface. By ignoring waves and wind, you want that the normal velocity at the interface is zero (water neither leaves nor enters through the surface); the tangential velocity has no constraint on it.

If you have not downloaded Daniel Brennan's PhD thesis, now is the time.

You should also be able to find many other PhD theses on clarifier modelling readily available online.