[Coke Rivas Ordenes]

Hello everyone! Thanks in advance for the time you might take when reading this thread.

I am currently working on a Large-Eddy Simulation (LES) of the Atmospheric Boundary Layer (ABL) flow in a 1250m x 800m x 800m computer domain. I will attempt to recreate a previous simulation (available for the public), to ensure that the model i have created is appropriate (all this for academic purposes).

The work i am currently working on, involves recreating two rather complicated topics, which till to this point i thought i had managed to circumvent all issues arising from them:

1. The velocity field ought to be initialize with a power-log-law profile.
2. Three blocks (.stl object) must be insert in the domain to achieve certain values for a specific flow-parameter:

blocks.png


[IMG]file:///home/cokerivas/Desktop/forumPictures/blocks.png[/IMG]
[IMG]file:///home/cokerivas/Desktop/forumPictures/blocks.png[/IMG]To achieve the first point (power-law profile) i use swak4foam (specifically funkySetFields) to create such a profile. To achieve the second point (the three blocks) i wrote the proper snappyHexMeshDict. Following, in both cases, OF tutorials and the invaluable information share through this forum, thanks again to the contributors. And it had all went splendid, or so i thought.


To test the simulation, i run it using the PISO solver provide in OF, for scarcely 3 physical seconds with a time step of 0.1 seconds. At this point of the thread i must specify that both snappyHexMesh and the PISO solver, were run in parallel using 4 processors (snappyHexMesh used a ptscotch decomposition method, while decomposePar used hierical). The test-simulation conclude with no issues or fatal OF error messages.


The problem arose when visualizing the velocity field in paraview. I notices there were manny "velocity hot spots" in the domain, and later realize that the hot spots were there for fields nut, nuTilda and k. As the image "hotSpots_parallelRunning" illustrates:


hotSpots_parallelRunning.png


In a further analysis i could conclude that the "hot spots" coincided with the union between processors, as you can see comparing the previous image, with image "hotSpots_minusProcessor4".



hotSpots_minusProcessor4.png


Furthermore, when para-viewing the lower wall (set to fixed value of 0 in the velocity boundary field) i notice a "crack" in the interface between processor 0 and processor 1, as shown in image "lowerWall_Crack" (in this image you can also visualize the position of the three blocks):


lowerWall_Crack.png


So the question are:

1. How can i fix this issues?
2. Is it due a wrong implementation of swak4foam or a snappyHexMesh error? Or is the origin of this completely different?

Allrun scrypt:

#!/bin/sh
cd ${0%/*} || exit 1    # Run from this directory

# Source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/RunFunctions

# Make dummy 0 directory
mkdir 0

runApplication blockMesh
cp system/decomposeParDict.hierarchical system/decomposeParDict
runApplication decomposePar

cp system/decomposeParDict.ptscotch system/decomposeParDict
runParallel snappyHexMesh -overwrite -parallel

find . -type f -iname "*level*" -exec rm {} \;

ls -d processor* | xargs -I {} rm -rf ./{}/0
ls -d processor* | xargs -I {} cp -r 0.orig ./{}/0 $1

runApplication funkySetFields -case processor0 -time 0
mv log.funkySetFields log.funkySetFields1
runApplication funkySetFields -case processor1 -time 0
mv log.funkySetFields log.funkySetFields2
runApplication funkySetFields -case processor2 -time 0
mv log.funkySetFields log.funkySetFields3
runApplication funkySetFields -case processor3 -time 0
mv log.funkySetFields log.funkySetFields4

runParallel pisoFoam

runApplication reconstructParMesh -constant -mergeTol 1e-6

runApplication reconstructPar

#------------------------------------------------------------------------------#

funkySetFields file:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      funkySetFieldsDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
theVariables 
(
            "nu           = 1.5e-05;"
            "u_star        = 0.5;"
            "B        = 5.2;"
            "kappa        = 0.41;"
            "delta_nu    = 3.33e+04;"

            "Ux        = 0.0;"
            "Uy        = 0.0;"
);

expressions
(
    velocityField
    {
        field    U;
        create false;
        expression "vector((0.5)*((1/0.41)*log((pos().z)/0.00003)+5.2),0,0)";
        keepPatches    true;
        variables $theVariables;
    }
);

Thank you very much for any contributions you might do. Sorry if the problem is not well explain or for the lack of documentation. It is my first attempt in this forum and english is not my first language, hopefully i will improve with time. Thanks to people creating features such as swak4foam and openFoam itself.

[Antimony]

Hi,

Have you tried the default boundary condition for ABL in OF? atmBoundaryLayerInletVelocity? Is that not suitable for your simulation?

Also, how coarse or fine is your mesh?

Out of curiosity, why do you use separate decomposition types for decomposePar and snappy? Can you not run funkySetFields in parallel instead of running it on every processor?

Cheers,
Antimony

[Coke Rivas Ordenes]

Hello Antimony!

I tried the ABL default boundary conditions provided by OF, but as you mentioned, they do not suit to my simulation; mostly because i need a cyclic inlet/outlet condition, but for many others reason as well.

The mesh is mainly compose by 10m x 10m x 10m cubic elements, with a refinement in the height-direction (z) close to the lowerWall (ground), where the size of the cubic elements is approximately 10m x 10 m x 3 m (x, y, z).

I use two decomposition methods (one for decompose par and a second for snappy) because the All run script is base on a the LES motorBike tutorial, which uses two different decomposition methods as well. I have already try using only one decomposition method (hierical) for both decompose and snappy, but it didn't yield any good results (they were far more erratic).

It haven't occur to me to run funkySetFields in parallel, i will have to check that out. Thank you for that.

Any thoughts?

Regards,
Jorge

[Coke Rivas Ordenes]

Originally Posted by Antimony

Hi,

Have you tried the default boundary condition for ABL in OF? atmBoundaryLayerInletVelocity? Is that not suitable for your simulation?

Also, how coarse or fine is your mesh?

Out of curiosity, why do you use separate decomposition types for decomposePar and snappy? Can you not run funkySetFields in parallel instead of running it on every processor?

Cheers,
Antimony

I have tried multiple combinations of decomposing for decomposePar and snappyHexMesh: simple-ptscotch, hierical-hierical, scotch-ptscotch, but none manage to circumvent the problem describe above.

Does anyone has a clue (intuition or hunch) from where does the problem rises? Thanks everyone!