CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Bugs

Problem with Sngrad() operator

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By hjasak

Reply
 
LinkBack Thread Tools Display Modes
Old   March 23, 2009, 22:50
Default Problem with Sngrad() operator
  #1
Senior Member
 
Senthil Kabilan
Join Date: Mar 2009
Posts: 113
Rep Power: 7
skabilan is on a distinguished road
Hi All,

I tried a simple case, transient flow through a cylinder. I am interested in the pressure gradient in the face normal direction at the boundaries. The output from gAverage(p.boundaryField()[patchIndex].snGrad()) is way off compared to the manual pressure gradient calculation, i.e, (pressure@inlet - pressure@outlet)/length of cylinder

Any help with the Sngrad() operator to compute the pressure gradient would be appreciated.

Thanks
Senthil
skabilan is offline   Reply With Quote

Old   March 24, 2009, 07:48
Default
  #2
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 15
mattijs is on a distinguished road
You posted in the OpenFOAM-bugs forum. This does not seem to be a bug. The snGrad returns the (discretised) face-normal gradient. See programmers guide P-40.
mattijs is offline   Reply With Quote

Old   March 24, 2009, 08:04
Default
  #3
Super Moderator
 
niklas's Avatar
 
Niklas Nordin
Join Date: Mar 2009
Location: Stockholm, Sweden
Posts: 692
Rep Power: 18
niklas will become famous soon enough
may I suggest that you use your new supermoderator-powers and move the thread
niklas is offline   Reply With Quote

Old   March 24, 2009, 14:26
Default
  #4
Senior Member
 
Senthil Kabilan
Join Date: Mar 2009
Posts: 113
Rep Power: 7
skabilan is on a distinguished road
Hi Mattijs,

Shouldn't the face normal gradient at the oulet returned by the gAverage(p.boundaryField()[patchIndex].snGrad()) be closer to (pressure@inlet - pressure@outlet)/length of cylinder?

Warm Regards,
Senthil

Last edited by skabilan; March 24, 2009 at 15:57.
skabilan is offline   Reply With Quote

Old   March 24, 2009, 16:02
Default the problem with snGrad
  #5
New Member
 
Daniel Einstein
Join Date: Mar 2009
Posts: 22
Rep Power: 7
deinstein is on a distinguished road
Quote:
Originally Posted by mattijs View Post
You posted in the OpenFOAM-bugs forum. This does not seem to be a bug. The snGrad returns the (discretised) face-normal gradient. See programmers guide P-40.
Mattijs,

I think there is a bit of misunderstanding here. snGrad appears to assume that one is using a structured grid in which the front and back faces are parallel. Clearly, in the case of a tetrahedral grid, this will not work. Since the two faces will never be parallel. We have confirmed that the order of error is equal to the cosine of the angle between the two faces. If snGrad was designed ONLY to work with structured hex meshes, than this is not a bug, but this limitation is not documented. If snGrad was designed to be general, than this is a bug.

Kind Regards,
Dan
deinstein is offline   Reply With Quote

Old   March 24, 2009, 19:39
Default
  #6
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,751
Rep Power: 20
hjasak will become famous soon enough
(I got this question in an E-mail, hence the response)

Sorry, I cannot follow what you are talking about: snGrad()
is a surface normal gradient:

(p_b - p_P)/delta

where p_b is the value at the boundary and p_P the value in
the next cell. There is no assumption of th mesh structure,
apart from there being a cell in front of a boundary face
(whatever its shape may be).

The other option you have got is to use the cell-centred
gradient next to the boundary and dot it with the direction.

volVectorField gradP = fvc::grad(p);

gradP.boundaryField()[patchI].patchInternalField() & patch.n().

I must have missed the point: what are you trying to tell me?

Hrv
fumiya likes this.
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   March 24, 2009, 20:00
Default problem with snGrad
  #7
New Member
 
Daniel Einstein
Join Date: Mar 2009
Posts: 22
Rep Power: 7
deinstein is on a distinguished road
Dear Hrv.

No doubt we are doing something wrong. When we do as you suggest with a tet mesh (something we did before posting). We find that using the two cell centers and dotting with the normal we get the right answer (we are doing this on a cyclinder so we know the right answer). Instead, when we use snGrad, we get the wrong answer, and the answer appears to be off by the angle between back face and front face, where front face is on the boundary. snGrad is convenient. A workaround we have settled upon is to extrude the tet mesh a little bit such that the boundary elements are prisms with perfectly parallel front and back. We just thought it might be useful to let others know.

Dan
deinstein is offline   Reply With Quote

Reply

Thread Tools
Display Modes

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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
UDF compiling problem Wouter Fluent UDF and Scheme Programming 6 June 6, 2012 04:43
Incoherent problem table in hollow-fiber spinning Gianni FLUENT 0 April 5, 2008 10:33
natural convection problem for a CHT problem Se-Hee CFX 2 June 10, 2007 06:29
Adiabatic and Rotating wall (Convection problem) ParodDav CFX 5 April 29, 2007 19:13
problem with using colocated code Jack Main CFD Forum 0 December 15, 2002 01:15


All times are GMT -4. The time now is 14:56.