View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004154 | OpenFOAM | Feature | public | 2024-09-19 08:39 | 2024-09-19 17:26 |
| Reporter | Luca Cornolti | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 12 | ||||
| Fixed in Version | dev | ||||
| Summary | 0004154: Issue with current definition of the Diffusion number | ||||
| Description | The diffusion number defined in applications/modules/solid/solid.C use the function fvc::surfaceSum, to estimate thermal diffusivity over the square of the characteristic length of the computational cell. const volScalarField::Internal DiNumvf ( fvc::surfaceSum ( mesh.magSf() *fvc::interpolate(kappa) *mesh.surfaceInterpolation::deltaCoeffs() )()() /(mesh.V()*thermo.rho()()*thermo.Cp()()) *runTime.deltaT() ); In cells within 3D domain, this definition is good to estimate this quantity, but there are some issue related to specific boundary conditions like wedge and empty patches used for 2D computations. In these setups the faces on the unsolved direction, which does not influence the solution, are also used to compute the diffusion number. While in 2D case with empty faces, one can play with the unsolved direction thickness to avoid problems, in wedge configurations, the Diffusion number of the cells close to the axis is considerably higher that what it should be as the cell thickness is very small in the tangential direction (the term deltaCoeffs() is big). Hence, the resulting time step is very small and this control becomes useless. Instead of using fvc::surfaceSum, I suggest to exclude from the summation the faces belonging to boundary conditions which impose no flux diffusion: wedge, empty and eventually zeroGradient patches. So replace fvc::surfaceSum with an other function which does something like this: ... forAll(mesh.boundary(), patchi) { const polyPatch& pp = mesh.boundaryMesh()[patchi]; if( !isA<emptyPolyPatch>(pp) && !isA<wedgePolyPatch>(pp) && !isA<zeroGradientFvPatchField<Type>>) { const labelUList& pFaceCells = mesh.boundary()[patchi].faceCells(); const fvsPatchScalarField& pssf = ssf.boundaryField()[patchi]; forAll(mesh.boundary()[patchi], facei) { vf[pFaceCells[facei]] += pssf[facei]; } } } ... | ||||
| Tags | No tags attached. | ||||
|
|
I think your analysis shows a more general problem with the way in which the diffusion number is currently evaluated, it isn't just about the thickness of 2D domains, there will be issues with any very anisotropic cells. Also if having zero gradient BCs is a problem surely there will be problems with any internal faces at which the gradient is zero or small. It would be possible to create a time-step control based on the actual flux of the field, more similar to the way in which the Courant number is evaluated, but the estimated rate of change of the field due to diffusion would need to be normalised, i.e. the user would need to supply a normalisation level, the maximum amount the field would be allowed to change within one time-step. However, given that the diffusion is solved implicitly and there are no stability issues relating to the solution, this control only relates to temporal accuracy and it is not clear what kind of control is really needed for this; more research is required. In the meantime I will remove the current dubious diffusion number control from the solid solver and you can contact us directly to discuss further work on solid solution accuracy controls. |
|
|
Resolved by commit e748a12d18423bb5e46188800d2ba36352843f3c |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-09-19 08:39 | Luca Cornolti | New Issue | |
| 2024-09-19 15:18 | henry | Note Added: 0013415 | |
| 2024-09-19 17:26 | henry | Assigned To | => henry |
| 2024-09-19 17:26 | henry | Status | new => resolved |
| 2024-09-19 17:26 | henry | Resolution | open => fixed |
| 2024-09-19 17:26 | henry | Fixed in Version | => dev |
| 2024-09-19 17:26 | henry | Note Added: 0013416 |
