|
[Sponsors] |
September 17, 2012, 08:32 |
snGradCorrection
|
#1 |
New Member
Eskil Aursand
Join Date: Sep 2012
Posts: 7
Rep Power: 14 |
Hello,
I am trying to modify a utility to get the normal gradient of a scalar field at boundaries. I was getting some strange results from using fvc::snGrad, and i read in the Programmers Guide that one might benefit from using fvc::snGradCorrection if the mesh is not orthogonal (which is the case here). I tried this, but when compiling the utility I get the error: error: ‘snGradCorrection’ is not a member of ‘Foam::fvc’ I'm a beginner with OpenFOAM, and haven't delved too deeply into its code yet, so I'm a little lost on how to find out what I'm doing wrong. Any help will be appreciated. |
|
September 17, 2012, 09:30 |
|
#2 |
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,091
Rep Power: 34 |
Hi,
there is no fvc::snGradCorrection, but you can use fvc::snGrad and then set snGradSchemes to corrected in your fvSchemes. This will calculate the surface normal gradient with non-orthogonal correction. As regards snGrad at the boundaries, by default OpenFOAM sets non-orthogonal correction to zero at the boundary (see Jasak Thesis) so the accuracy is only good on orthogonal grids. If you do need correction at the boundaries, you need to implement custom boundary conditions with non-orthogonal correction. Philip |
|
September 17, 2012, 10:33 |
|
#3 |
New Member
Eskil Aursand
Join Date: Sep 2012
Posts: 7
Rep Power: 14 |
Let me see if i've understood you:
fvc::snGrad may be corrected for non-orthogonal meshes, but it will be no use for me if i'm only interested in the boundaries? snGradSchemes in the system/fvSchemes of my case was already set to "corrected". Is this what is used by my custom utility? |
|
September 17, 2012, 11:07 |
|
#4 | ||
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,091
Rep Power: 34 |
Quote:
Quote:
Code:
00176 // Return gradient at boundary 00177 template<class Type> 00178 Foam::tmp<Foam::Field<Type> > Foam::fvPatchField<Type>::snGrad() const 00179 { 00180 return (*this - patchInternalField())*patch_.deltaCoeffs(); 00181 } Therefore if you are interested in orthogonal correction at the boundaries, you could implement a custom boundary condition where you define the snGrad as (taken from fixedDisplacementFvPatchVectorField.C found here): Code:
115 const fvPatchField<tensor>& gradField = 116 patch().lookupPatchField<volTensorField, tensor> 117 ( 118 "grad(" +fieldName_ + ")" 119 ); 120 121 vectorField n = this->patch().nf(); 122 vectorField delta = this->patch().delta(); 123 124 //- correction vector 125 vectorField k = delta - n*(n&delta); 126 127 return 128 ( 129 *this 130 - (patchInternalField() + (k&gradField.patchInternalField())) 131 )*this->patch().deltaCoeffs(); Philip |
|||
August 30, 2013, 06:52 |
corrected snGradient
|
#5 |
Member
Join Date: Oct 2012
Posts: 47
Rep Power: 14 |
Hi
i want to discrete momentom Eqn and i need formulation of corrected sngradient in OF. please help me |
|
October 15, 2018, 22:05 |
|
#6 |
Senior Member
Reviewer #2
Join Date: Jul 2015
Location: Knoxville, TN
Posts: 141
Rep Power: 11 |
Philip,
What could be the reason you think? Thanks, Rdf |
|
October 17, 2018, 07:05 |
|
#7 |
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,091
Rep Power: 34 |
Hi Rdf,
I am not sure of the reason; for the diffusion operator, it can make a big difference e.g. look at the gradT field with laplacianFoam on a mesh with non-orthogonal cells near the boundary. In fact, as far as I know, some forks of OpenFOAM (e.g. Caelus) enable this boundary non-orthogonal correction by default for all physics. Philip Last edited by bigphil; October 17, 2018 at 07:05. Reason: typo: replace graddT with gradT |
|
October 17, 2018, 08:48 |
|
#8 | |
Senior Member
Reviewer #2
Join Date: Jul 2015
Location: Knoxville, TN
Posts: 141
Rep Power: 11 |
Quote:
Does Foam::fvPatchField<Type>::snGrad() only excuted when the fixedValue is used? Here is my observation with fvPatchField<Type>::snGrad() and I do not exactly sure about what is the use of the fvPatchField<Type>::snGrad(). First, in the fixedValueFvPatchField.C, there is no fvPatchField<Type>::snGrad(). While, in the fixedGradientFvPatchField.H, fvPatchField<Type>::snGrad() return the gradient that you defined. Am I missing something? Second, fvPatchField<Type>::snGrad() only referenced by wall functions and snGradScheme< Type >::snGrad(). Third, where does the solver need the fvPatchField<Type>::snGrad()? I thought the BC condition only impact the solution through the function valueInternalCoeffs, valueBoundaryCoeffs, gradientInternalCoeffs(), and gradientBoundaryCoeffs(). |
||
October 17, 2018, 09:13 |
|
#9 | |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 |
Quote:
Code:
laplacian(DT,T) Gauss linear secondOrderCorrected; https://sourceforge.net/projects/ope...t-OFW10-77.pdf Note: With a fixed gradient BC it can recover 2nd order using only the least squares gradient reconstruction. Using the standard Gauss gradient reconstruction, 2nd order not possible because the boundary face value is unknown. We therefore implemented a corrected Gauss gradient, corrGauss, which iterates to improve the accuracy. The default is 2 iterations and improves the accuracy to somewhere between 1st and 2nd order. -Chris |
||
October 17, 2018, 21:24 |
|
#10 |
Senior Member
Reviewer #2
Join Date: Jul 2015
Location: Knoxville, TN
Posts: 141
Rep Power: 11 |
Here are two papers for the future reference
A case-study in open-source CFD code verification, Part I: Convergence rate loss diagnosis https://www.sciencedirect.com/scienc...78475417303774 A case-study in open-source CFD code verification. Part II: Boundary condition non-orthogonal correction https://www.sciencedirect.com/scienc...78475417303762 |
|
October 21, 2018, 13:51 |
|
#11 | ||||
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,091
Rep Power: 34 |
Hi randolph,
See my replies below. Quote:
Quote:
Quote:
Quote:
Also, I said above, it will affect the calculation of the gradient field. Hope it helps, Philip |
|||||
October 21, 2018, 14:22 |
|
#12 | |
Senior Member
Reviewer #2
Join Date: Jul 2015
Location: Knoxville, TN
Posts: 141
Rep Power: 11 |
Quote:
Thank you very much! It is much clear to me now! Rdf |
||
October 23, 2018, 10:33 |
|
#13 |
Senior Member
Reviewer #2
Join Date: Jul 2015
Location: Knoxville, TN
Posts: 141
Rep Power: 11 |
Hi Philip,
I spend some time reading the implementation of the snGrad(). However, I have some trouble with understanding the calling sequence. For example, the fixed gradient, which is defined as: Code:
//- Return gradient at boundary virtual tmp<Field<Type>> snGrad() const { return gradient_; } I am noob in both C++ and OpenFoam. I am very new to the handling of a unstrucured non-orthogonal grid. Could you please help me to understand the implementation of snGrad(). Particularly, how exactly the snGrad() work with other functions, such as valueInternalCoeffs(), valueBoundaryCoeffs(),gradientInternalCoeffs(), gradientBoundaryCoeffs(), to influent the solution. Thanks, Rdf |
|
Tags |
gradients, openfoam 2.1.x, post-processing |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
snGradCorrection | doubtsincfd | OpenFOAM | 0 | September 30, 2011 23:55 |