[thomas]

Hi Alejandro,rnrnyou use a spacing of h=0.01. During voxelization the geometry is shifted by h/4 to overcome some issues with floating point numbers. Thats why you get such crooked numbers.rnrnIf you look at the y- and z limits for material 1, you get a width of 0.4075-0.0075 = 0.4. Adding h/2 for each half-way bounce back boundary leads to 0.41, which is what you want.rnrnRegardsrnThomasrnrnrn

[thomas]

Hi Ivy,rnrnwe puplished a proceeding containing this simulation, which you can find here:rnhttp://link.springer.com/chapter/10.1007/978-3-642-36961-2_5rnrnIn the book containg the paper you ll find some more work on that example:rnhttp://link.springer.com/book/10.1007/978-3-642-36961-2rnrnRegardsrnThomasrnrn

[thomas]

Hi Liliana,rnrnplease excuse the late answer, we’ve been busy publishing the new release.rnrnYou’re right, charU is the characteristic velocity in SI units (m/s), that you use for computing the Reynolds number. And is usually chosen to be a maximal velocity of your system. So you’ll be fine with the mean inlet velocity, if the velocity doesn’t increase much. Better would be to take the maximal velocity.rnrnLatticeU implicitly defines the time step size and is given in lattice units. It is connected to the Mach number, as 1/latticeU is approx the number of time steps a pressure wave needs to cross one lattice node. So for latticeU = 1 you get about the speed of sound (Mach 1), which would be a bad choice for LBMs don’t work well at high mach numbers. A better choice for a start is latticeU = 0.1 and slowly decreasing for more stability.rnrnCharU and latticeU are connected in a way, that charU/latticeU is a conversion factor between lattice units and SI units. Meaning that if you choose charU = 1. [m/s] and latticeU = 0.05 and during your simulation at some point you get a lattice velocity of 0.1 your physical velocity at that point is 0.1 * 1./0.05 = 2 [m/s].rnrnFurthermore, you can use CharU and latticeU to compute the time step size in SI units (seconds) as:rn# physTime = latticeU/charU * latticeLrnon the other hand, if you want a fixed time step, you can compute latticeU:rn# latticeU = physTime * charU / latticeLrnagain be careful as for large time steps your simulation will diverge.rnrnRegardsrnThomas

[thomas]

Hi jepson,rnrnwe have been able to reproduce your problem. It could be backtraced to an incompatibility between CVMLCPP and gcc v4.6. There are 2 possibilities to solve the problem:rn1. Replace the folder “”openlb/src/external/cvmlcpp”” by the new version of CVMLCPP which can be found here: http://tech.unige.ch/cvmlcpp/ orrn2. use an older version of gcc (<4.6)rnrnWe are also working on a new release which will resolve the problem and is supposed to be published soon.rnrn

[Author]

Posts