[Muhammad Omer Mughal]

Hi all

I am using terrainBlockMesher for meshing a complex terrain.I am facing problem in defining the dimensions of the terrain and the bounding box due to the fact that the terrain is 27 km in EW direction and is 18 Km in NS direction. Any help will be appreciated

[wyldckat]

Greetings Muhammad,

Have you managed to solve this issue?
If not, please provide more information regarding what you've already managed to understand and use so far.

Best regards,
Bruno

[Muhammad Omer Mughal]

Hi Bruno

Thanks for the reply .I am stuck in the same issue till now.I will share what I have learnt till now and see if you can help me out in this problem.the terrain block mesher generates a blockMeshDict for an arbitrary terrain, using splines.It has its own dictionary called terrainBlockMesherDict.In this dictionary one can define the size of the domain and the bounding box and the geometry in stl format is located in trisurface directory.I have imported an SRTM dat file in the stl format and used its lower left corner for defining the lower left box corner.you can see the changes that I have made in the terrainBlockMesherDict below.


// Specification of the over all box. Height values will be adjusted to stl.
// p_corner is the lower left box corner, the above base vectors span the box.
// Dimensions are lengths scales of the box, wrt base vectors given above.
p_corner (36750778 2376356 1000);
dimensions (195418 214167 7000);

// a point well above the stl.
p_above (0 0 10000.0);

The problem is when the file is generated the bounding box is dragged up and down with the size of the domain and I want the bounding box to be a bit larger in the height direction so that I can define my boundary conditions.If you require any additional queries let me know and may be together we can fix this issue

Regards
Omer

[wyldckat]

Hi Omer,

For reference for other forum members, this utility is documented here: http://openfoamwiki.net/index.php/Si...g_Terrain_Data

I've finally managed to give a quick look into this and I tried a couple of the tutorial cases provided at https://github.com/jonasIWES/terrainBlockMesher

When I ran the tutorial "iwesol/OF/OF-2.1.1/tutorials/utilities/mesh/terrainBlockMesher/largerThanSTL", I got the a strange mesh as shown in attachment. Essentially, the STL was not fully respected and is floating high above, possibly because the splines needed to compensate a bit for the estimation of the curvature of the terrain.

Is this the kind of situation you're getting? If not, can you provide one or more images of what you're getting?


Beyond this, why don't you define the STL to start somewhere closer to the origin of the referential, as well as the bounding box?
I say this because this strategy will reduce cumulative errors when generating the mesh and when running the simulation.

You can translate the STL by using surfaceTransformPoints and the mesh later on with transformPoints. Use the "-help" option for more information on how to use each utility.

Best regards,
Bruno

[Muhammad Omer Mughal]

Hi Bruno

Thanks for the reply and the time you had taken to solve the issue of meshing with tbm.I fianlly managed to mesh the geometry correctly and I am now willing to put the correct boundary conditions.The mesh contains top,bottom,N,S,W,E,internal mesh patches .I have taken the bottom as a wall with no slip condition .While the E is taken as velocity inlet with wind entering at 10 m/sec uniformly. The west patch is outlet with 0 gradient boundary condition ,others are velocity inlets with wind entering at 10 m/sec inside the domain . Do you suggest these boundary conditions to be correct or not.
The tbm has a problem that its blockmeshdict doesnot have a line called convert to meters and when I add this line myself it creates error .Do you suggest any solution to this problem as well

[wyldckat]

Hi Omer,

Sorry for taking so long to answer, but only today did I manage to come by to your questions.

I believe the N and S boundary conditions can either be the exact same flow speed vector you have for E, so that you force all of the flow to go from E to W. Or use "slip" for N and S, in case you don't want to force the speed.

Beyond this, you might want to have a look into the tutorial case "incompressible/simpleFoam/turbineSiting" for more ideas on this kind of case set-up for exterior wind simulations.

As for the terrainBlockMesher utility, I believe it works under the assumption that the user knows that one should always use SI units (metre/meter in this case), to avoid any and all confusions with units, since the cases set-up for OpenFOAM are usually in SI units. Otherwise, it's a very big risk of having a domain that is either 1000 times smaller or larger than desired.

Best regards,
Bruno

[Muhammad Omer Mughal]

Hi Bruno

Thanks for the help again .I was using Rhino to correct my stl file .When I checked the coordinates in Rhino they were seeming to be 10 times larger.I therefore scaled geometry down to 1/10 but the problem now I am having is that the snappyHexMesh is showing 5 mesh check fails including the non orthogonality which is causing my solver to crash.Can you suggest any thing which I can use to correct this problem.

[wyldckat]

Originally Posted by Muhammad Omer Mughal

but the problem now I am having is that the snappyHexMesh is showing 5 mesh check fails including the non orthogonality which is causing my solver to crash.Can you suggest any thing which I can use to correct this problem.

Quick answer:

1. Isolate and conquer: http://openfoamwiki.net/index.php/Sn...te_and_Conquer
2. Visually diagnose the mesh: http://openfoamwiki.net/index.php/FA...is_in_ParaView
3. Asking questions about problems with snappyHexMesh - ask here: http://www.cfd-online.com/Forums/ope...snappyhexmesh/
4. I and anyone else is unable to see what you're seeing. See this thread to see what I'm referring to: http://www.cfd-online.com/Forums/ope...-get-help.html

[Muhammad Omer Mughal]

Hi Bruno

Thanks for the reply .I fixed the problem regarding geometry .SRTM data is in Geographical lat lon projection so it had to be changed to UTM in order to correct the units of STL geometry.
TBM does not understand distances given with 2 or three decimal places .Therefore when rounding off the digits a certain cushion has to be kept for the first corner of the geometry.
TBM follows Cartesian coordinate system

Now I have to correct the boundary conditions.Till that time please keep in touch and keep on posting me with your invaluable guidelines

[Muhammad Omer Mughal]

Hi Bruno
After a long battle with the boundary conditions I managed to correct them.The problem now being faced is that results have to be optimised.I therefore traced back the errors and found two mesh check fails as given below.Can you suggest any thing to correct these errors

Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 9864283
faces: 22598789
internal faces: 19854035
cells: 6482017
boundary patches: 7
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 4855807
prisms: 80854
wedges: 0
pyramids: 0
tet wedges: 2132
tetrahedra: 0
polyhedra: 1543224

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
west 5215 6569 ok (non-closed singly connected)
east 4243 5433 ok (non-closed singly connected)
south 5410 6938 ok (non-closed singly connected)
north 5404 6851 ok (non-closed singly connected)
bottom 282423 526899 ok (non-closed singly connected)
top 22500 22801 ok (non-closed singly connected)
turkana_proj_turkana_proj2419559 2706071 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (249559 266460 616.632) (277422 286589 2611)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (-4.60137553642e-17 2.15207721653e-16 0) OK.
Max cell openness = 3.96967361966e-16 OK.
Max aspect ratio = 22.1606648199 OK.
Minumum face area = 0.0235000000001. Maximum face area = 90763.35. Face area magnitudes OK.
Min volume = 23.445546165. Max volume = 12159868.885. Total volume = 1.01543714381e+12. Cell volumes OK.
Mesh non-orthogonality Max: 84.6254953489 average: 27.5955128662
*Number of severely non-orthogonal faces: 2120.
Non-orthogonality check OK.
<<Writing 2120 non-orthogonal faces to set nonOrthoFaces
***Error in face pyramids: 30 faces are incorrectly oriented.
<<Writing 30 faces with incorrect orientation to set wrongOrientedFaces
***Max skewness = 9.07995703853, 353 highly skew faces detected which may impair the quality of the results
<<Writing 353 skew faces to set skewFaces
Coupled point location match (average 0) OK.

Failed 2 mesh checks.

End

[Muhammad Omer Mughal]

Hi Bruno

As per my previous email there were orthogonality and skewness issues after using snappyHexMesh after tbm. I therefore considered to use just tbm with and without larger than stl option.I found as you did that the mesh is some what exaggerated at near the boundary of the terrain in larger than stl option.I have attached all the pictures of the mesh in order to give you a better idea of what I am talking about .
I am using the modified ABLSOLVER developed buy NREL and I had to change the boundary condition to be cyclic for north south and east and west patches. I have changed the boundary file in constant/polymesh developed by tbm as it cannot generate the cyclic patch and also my block mesh dict. I had to change the matching tolerance from 0.001 to 0.4 as the mismatch between the patches was 11.56 %. When I did all these changes and used the mesh develoeped by tbm without larger than stl option and without snappyhexMesh the solver runs upto the stage where it starts to do the first iteration and than it hangs there and there is no error shown but the solver doesnot perform the first iteration. Will you be able to help me in this situation asap .I shall be grateful to you for your help

[Txinsoulkg]

Dear user,
I can't fixed that problem until now.
What should I do?
I've been already used Meshlab and Admesh.
Plz help me.