2017-10-22 00:09 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002713OpenFOAMPatchpublic2017-10-20 15:27
Reporterbjoern.pfeiffelmann 
Assigned Tohenry 
PrioritynormalSeveritymajorReproducibilityalways
StatusassignedResolutionreopened 
PlatformGNU/LinuxOSOpenSuSEOS Version42.3
Product Version5.0 
Target VersionFixed in Version 
Summary0002713: Harmonic surface interpolation scheme predict the boundary face values wrong
DescriptionAs I have posted already here: https://www.cfd-online.com/Forums/openfoam-solving/192948-chtmultiregionsimplefoam-nonlinear-heat-conduction-wrong-temperature-prediction.html
is the number of cells required to predict a nonlinear diffusion problem with the chtMultiRegionSimpleFoam solver quite high.

To improve this behavior the harmonic surface interpolation scheme for interpolating the diffusion coefficient seems to be the right choice as described by e.g. “Numerical heat transfer and fluid flow. S. V. Patankar (1980)”
But there is a bug in the interpolation of the boundary patch values in the harmonic scheme, more precisely in the reverse Linear scheme. As can been seen in the figure attached, I would expect that the interpolated boundary field value is equal to the internal field value and not equal to the boundary field if the harmonic scheme is applied.


We have created a patch for the problem which is attached including the validation case. We modified the reverse Linear scheme, so that it corrects the interpolated boundary field afterwards. This helped to be able to predict the solution only with 3 cells but is rather less elegant.

What is the reason to ignore the weighting factor in surfaceInterpolationScheme.C:308 for the boundary patch? Shouldn’t be the weighting factor dependent on the interpolation scheme instead of setting it equal to 1 like in fvPatch.C:152

best regards
Björn
Steps To Reproducedownload harmonicPatch.zip
unzip
run Allrun
Tagsharmonic, Heat transfer, Surface Interpolation
Attached Files

-Relationships
+Relationships

-Notes

~0008825

henry (manager)

Adapting the harmonic interpolation to override the boundary value is not appropriate in general; for example if it were used for a transported field the value on the boundary is the correct value for convective transport into the domain.

What you really need is a wall-function BC for the diffusion coefficient which sets the value on the boundary appropriate for the transport between the boundary and cell-centre.

~0008829

StephanG (reporter)

I have cleaned up your case and added an automatic graph creation to it. Might make resolving this issue faster. @henry wouldn't it make sense to add such an alpha correction to every (non coupled) boundary by default?

~0008830

henry (manager)

What you really need is a wall-function BC for the diffusion coefficient which sets the value on the boundary appropriate for the transport between the boundary and cell-centre.

~0008831

StephanG (reporter)

Yes, but what I meant is: Shouldn't this be part of thermo.correct()? Or am i missing something?

~0008832

henry (manager)

It would be a boundary condition and updated as a boundary condition.

~0008833

bjoern.pfeiffelmann (reporter)

I think that it is not necessary to develop an additional boundary condition. The problem is that the harmonic scheme is not implemented consistently (in the internal field yes, but on the boundary not). The present scheme aim to correct this. I think that this does not have any implications for the convective transport, since the harmonic scheme is not used for the convective therm anyway.
For my understanding linear and reverseLinear are opposite in the sense that the linear scheme weights the cell center higher which is closer to the face center for which the field is interpolated. reverseLinear weights the cell center higher which is further away from the face center. But why should this be only valid for internal fields or coupled boundaries? Since the boundary patch field (not interpolated) is positioned exactly on the boundary face the boundary patch field shouldn’t influence the interpolated boundary patch field in the case of using the reverseLinear scheme. So the result is that the interpolated boundary field is equal to the internal field because in comparison with the boundary patch field it has a distance to the boundary face.

Here is my proposal to implement this behavior
https://github.com/OpenFOAM/OpenFOAM-dev/pull/13

Implemented in that way it should not influence any other scheme, because the weighting for the boundary for all other schemes is 1. It also includes additional flexibility in the implementation of other schemes.

~0008834

henry (manager)

Last edited: 2017-10-09 08:51

View 2 revisions

The harmonic interpolation is run-time selectable and could be used for convective transport or anything else and should not override BCs which are fixed or specifically evaluated in some way. Boundary values are boundary values and not interpolated unless they are coupled with another domain, e.g. processor boundaries which which case they are not real boundaries anyway.

If you want to extrapolate the internal field values to the boundary for whatever reason you can simply apply the 'zeroGradient' BC, you do not need to change the interpolation scheme into an extrapolation scheme to do this.

~0008835

bjoern.pfeiffelmann (reporter)

>The harmonic interpolation is run-time selectable and could be used for convective transport or anything else and should not override BCs which are fixed or specifically evaluated in some way. Boundary values are boundary values and not interpolated unless they are coupled with another domain, e.g. processor boundaries which which case they are not real boundaries anyway.

I understand the doubts, but there is also a disadvantage in creating separate boundary conditions for the harmonic interpolation scheme: When the user on run time level specifies the harmonic interpolation scheme, without the (new) harmonic boundary condition. In that case the intended improvement would be ineffective.

>If you want to extrapolate the internal field values to the boundary for whatever reason you can simply apply the 'zeroGradient' BC, you do not need to change the interpolation scheme into an extrapolation scheme to do this.

My aim, and I think that it is usually the aim when using the harmonic interpolation, is the surface interpolation of the diffusion coefficient but not the interpolation of the field variable. Is it possible, at all, to apply 'zeroGradient' BC for a diffusion coefficient?

~0008836

henry (manager)

> Is it possible, at all, to apply 'zeroGradient' BC for a diffusion coefficient?

I have not checked this but if it is not currently possible it should be made possible rather then compromising the design of the interpolation schemes.

~0008843

StephanG (reporter)

Currently the only option for solids is heSolidThermo. Which uses kappa (NO_READ NO_WRITE) to calculate alpha which the solver uses (from basic thermo).thermo:alpha is again set to NO_READ and NO_WRITE. The thermo.correct() or calculate() function updates the values for the temperature dependence. Hence my statement above. From my perspective the change should still be made there.

~0008844

henry (manager)

Agreed the interpolation scheme should not manipulate boundary values, this is what boundary conditions are for, the thermodynamics should be generalized to allow specialized BCs to be applied to kappa.

~0008846

bjoern.pfeiffelmann (reporter)

When implemented as a specialized BC, I would prefer a solution which is not limited to heat transfer problems or a wall boundary condition. This issue should occur whenever a diffusion flux is approximated at the boundary with varying diffusion coefficients e.g. species concentration at a velocity inlet.

~0008847

henry (manager)

Can you provide a patch which adds run-time selected BCs to kappa and diffusivity?

~0008851

bjoern.pfeiffelmann (reporter)

I will try it, but it will take some time

~0008865

henry (manager)

Please reopen when you can have completed the patch which adds run-time selected BCs to kappa and diffusivity.

Thanks

~0008907

bjoern.pfeiffelmann (reporter)

Here my patch for solid thermo:alpha:

https://github.com/OpenFOAM/OpenFOAM-dev/pull/15

and the modified test case attached.

Unfortunately, same problem will occur when the harmonic interpolation scheme is applied to any other diffusion coefficient.

~0008908

henry (manager)

> Unfortunately, same problem will occur when the harmonic interpolation scheme is applied to any other diffusion coefficient.

Sure, have you tried applying the same change to any other diffusion coefficient?

~0008913

bjoern.pfeiffelmann (reporter)

No, not jet. Maybe a note can be putted in the description of the harmonic scheme

~0008914

henry (manager)

> Maybe a note can be putted in the description of the harmonic scheme

This has nothing to do with the harmonic scheme which only handles interpolation; what you want to do is change the boundary conditions.
+Notes

-Issue History
Date Modified Username Field Change
2017-10-06 13:35 bjoern.pfeiffelmann New Issue
2017-10-06 13:35 bjoern.pfeiffelmann File Added: harmonicPatch.zip
2017-10-06 13:35 bjoern.pfeiffelmann Tag Attached: Heat transfer
2017-10-06 13:35 bjoern.pfeiffelmann Tag Attached: harmonic
2017-10-06 13:35 bjoern.pfeiffelmann Tag Attached: Surface Interpolation
2017-10-06 13:36 bjoern.pfeiffelmann File Added: harmonicPatch.jpg
2017-10-06 13:36 bjoern.pfeiffelmann File Added: OF_vs_ANALYTIC_T.png
2017-10-06 13:37 bjoern.pfeiffelmann File Added: OF_vs_ANALYTIC_wallHeatFlux.png
2017-10-06 14:20 henry Note Added: 0008824
2017-10-06 15:02 henry Note Deleted: 0008824
2017-10-06 15:04 henry Note Added: 0008825
2017-10-06 18:21 StephanG File Added: wall1D.tar.gz
2017-10-06 18:21 StephanG Note Added: 0008829
2017-10-06 18:31 henry Note Added: 0008830
2017-10-06 19:03 StephanG Note Added: 0008831
2017-10-06 20:12 henry Note Added: 0008832
2017-10-09 07:53 bjoern.pfeiffelmann Note Added: 0008833
2017-10-09 08:20 henry Note Added: 0008834
2017-10-09 08:51 henry Note Edited: 0008834 View Revisions
2017-10-09 09:48 bjoern.pfeiffelmann Note Added: 0008835
2017-10-09 10:04 henry Note Added: 0008836
2017-10-09 14:23 StephanG Note Added: 0008843
2017-10-09 14:28 henry Note Added: 0008844
2017-10-10 07:33 bjoern.pfeiffelmann Note Added: 0008846
2017-10-10 08:06 henry Note Added: 0008847
2017-10-10 13:46 bjoern.pfeiffelmann Note Added: 0008851
2017-10-13 09:31 henry Assigned To => henry
2017-10-13 09:31 henry Status new => closed
2017-10-13 09:31 henry Resolution open => suspended
2017-10-13 09:31 henry Note Added: 0008865
2017-10-20 12:27 bjoern.pfeiffelmann Status closed => feedback
2017-10-20 12:27 bjoern.pfeiffelmann Resolution suspended => reopened
2017-10-20 12:27 bjoern.pfeiffelmann Note Added: 0008907
2017-10-20 12:28 bjoern.pfeiffelmann File Added: wall1Dharmonic.tar.gz
2017-10-20 12:52 henry Note Added: 0008908
2017-10-20 15:23 bjoern.pfeiffelmann Note Added: 0008913
2017-10-20 15:23 bjoern.pfeiffelmann Status feedback => assigned
2017-10-20 15:27 henry Note Added: 0008914
+Issue History