CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[blockMesh] Wrong surface normals with SHM's baffle feature on varying blockMeshDict description

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 20, 2014, 18:15
Exclamation Wrong surface normals with SHM's baffle feature on varying blockMeshDict description
  #1
Member
 
Ripudaman Manchanda
Join Date: May 2013
Posts: 55
Rep Power: 13
ripudaman is on a distinguished road
Dear Foamers,

I have posted my problem on the bug reporting system here - http://www.openfoam.org/mantisbt/view.php?id=1131.

One of the managers replied and said that he was not able to reproduce the problem. I am unable to diagnose what I am doing wrong. Can you please help me?

I am creating a circular baffle (radius = 5, center = 0,0,0) using SHM. The baffle is in the YZ plane. The two faces of the normal after snapping should have normals in the opposite directions. I found that this varies with a small change in the blockMeshDict file.

Keeping everything else same if I increase the size of my blockMesh dict in the +X direction (increasing the gridblocks in +X direction proportionately) I find that the surface normals on the circular baffle (ff and ff_slave) become randomly oriented.

I have attached two cases. Sneddon_50_25_25 works perfectly while Sneddon_100_25_25 does not.
The first case has a box with dimensions (-100,-50,-50) to (100,50,50) with 50,25,25 gridblocks in X,Y and Z directions respectively.
The second case has the box with dimensions (-100,-50,-50) to (300,50,50) with 100,25,25 gridblocks in X,Y and Z directions respectively.
In both cases the disc/baffle is located at 0,0,0 and oriented in the YZ plane.

Can you please confirm if you can reproduce a random arrangement in the cell normals on the ff patch in the X direction? The normals on one side of the patch should ideally be uniformly either (1,0,0) or (-1,0,0). I get a mixed bag for the second case.

Thanks for your help.

Ripu
Attached Files
File Type: gz Sneddon_50_25_25.tar.gz (7.6 KB, 1 views)
File Type: gz Sneddon_100_25_25.tar.gz (7.6 KB, 1 views)
ripudaman is offline   Reply With Quote

Old   January 26, 2014, 10:35
Default
  #2
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
For future readers: this problem seems to have been already solved, or at least the bug has been reported as already fixed and confirmed on the indicated bug report.
wyldckat is offline   Reply With Quote

Old   January 26, 2014, 14:43
Default
  #3
Member
 
Ripudaman Manchanda
Join Date: May 2013
Posts: 55
Rep Power: 13
ripudaman is on a distinguished road
The problem was solved by using an updated version of OpenFOAM 2.2.x form the repository.
ripudaman is offline   Reply With Quote

Reply

Tags
baffle, fracture, snappyhexmesh, surface normals


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
mass flow in is not equal to mass flow out saii CFX 12 March 19, 2018 06:21
udf error srihari FLUENT 1 October 31, 2016 15:18
Cluster ID's not contiguous in compute-nodes domain. ??? Shogan FLUENT 1 May 28, 2014 16:03
Simulation of varying contact angles for a large droplet of water on a surface cp703 CFX 5 July 20, 2013 07:08
Constant velocity of the material Sas CFX 15 July 13, 2010 09:56


All times are GMT -4. The time now is 13:46.