[JayDeeUU]

Please see my earlier post at

Mesh embraces only one of four specified domain sub-volumes

for background on what I am doing - attempting to simulate buoyancy-driven flow in a closed container, with an imposed, inhomogeneous wall temperature distribution.

Since that earlier post I have been able to create a hex mesh (adequate as a starting point, anyway) using one of (distressingly) many variants of snappyHexMesh that I've tried (see attached Dict filement).

The flow domain is split into four layers (see attached Dict files). After mesh creation, the file .../constants/polyMesh/boundary contains the six (irrelevant) faces of the original domain specified in blockMeshDict, but, and I suspect this is a problem if not the problem, it does not contain any information pertaining to the four component layers (shell1, shell2, cylinder1, cylinder2).

Overlooking this worry, I delete the six irrelevant faces from .../constants/polyMesh/boundary. I then specify distinct initial and boundary conditions on temperature for the four layers (attached file "T" from the 0 folder), set up the other files in 0, and run buoyantSimpleFoam. The run completes... and the computed fields are present in folders at the times requested. The numbers for T and U do not immediately seem implausible. But, when I attempt to view the volume fields in paraFoam, there is an immediate crash:

--> FOAM FATAL IO ERROR:
size 125000 is not equal to the given value of 621678

file: /home/johnd/OpenFOAM/johnd-8/run/snoplus3/120/T at line 18.

From function Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
in file /home/ubuntu/OpenFOAM/OpenFOAM-8/src/OpenFOAM/lnInclude/Field.C at line 210.



Can anyone please suggest what might be wrong with my Dict files, causing there to be no reference in .../constants/polyMesh/boundary to the walls of my mesh regions (and their face count)?... or determine any other problem inferred from what I've conveyed here? Thanks, John.


Added later: as a work-around, I've found that after running snappyHexMesh the information about the wall patches (cyl1, cyl2,...) is available inside polyMesh/boundary at later time levels, and so can be copy/pasted back to .../constants/polyMesh/boundary. That action, however, causes paraFoam to crash immediately.

[Ship Designer]

Hi John,

the snappyHexMeshDict as you posted it has the regions subdictionary commented out, thus there is no valid patchInfo entry in the file. That would explain, why the patches are not created. The patchInfo entry needs to be either in the subdictionary of the *.stl file in geometry {} or where you put it, in the regions subdict.

From your description it is unclear how the domain looks like and what you are trying to simulate. If you could provide pictures of your *.stl file or a sketch of the domain, with indicating which part is fluid, which are the walls etc. that would help to understand what you are trying to accomplish.

Removing the boundary faces from the domain and leaving in place only the walls sounds very odd to me… I'm surprised it calculates at all, but then again I've never used the type of simulation you are using. The error you get "size x not equal…" occurs whenever the number of cells in the polyMesh and in a field file do not match, in your case the field T.

Are you running snappyHexMesh with or without the option -overwrite? Without it, the mesh will be written to some time folder, whereas with the option the polyMesh in constant/ will be overwritten, which is the typical method. Having snappyHexMesh write to different times is only useful for inspecting the mesh between meshing steps or if you want to keep the original mesh made with blockMesh. It is best if the mesh can be made in such a way that no manual editing of the file boundary is necessary to avoid sources of errors. Hope this helps.

Cheers, Claudio

[JayDeeUU]

Hi Claudio,


Thanks for responding. I'm quite a bit further ahead now than I was when I posted, albeit mostly by trial and error, so your reply will help me to avoid repeating earlier mistakes. I generally was not running snappyHexMesh with the -overwrite option, but did pick up enough from forum entries


Size *** is not equal to the given value of ***

https://www.cfd-online.com/Forums/openfoam-pre-processing/185587-fatal-error-patchsummary-size-not-equal-given-value.html
to have progressed. I had been puzzled by the business of the mesh being written to several time folders (or not, depending on the details of my floundering about), so many thanks for clarifying.


Just for clarity, in case others should peruse this entry, what I'm attempting is to simulate buoyancy-driven circulation in a vessel containing a scintillator fluid atop of water (the physical case being a neutrino detector, Snoplus). The detector is a sphere (6 m radius) with a cylindrical access neck (0.75 m radius) aligned to the vertical. For the moment I'm treating it as a single fluid problem, i.e. the scintillator only (the water being more dense than the scintillator). The experimental objective is to keep the temperature stratification in the detector stable, so as to avoid mixing radioactive impurities down the neck- but the means of control is rather indirect (via the temperature stratification of exterior water in the cavity that surrounds the detector).



I'm trying to establish the circulation that would result for realistic disturbances to the stratification. To that end it would be useful to be able to decompose the temperature into a stratified background T0 (varying with height) and a perturbation T', as is commonly the case under (and indeed, I would have said, implicit in) the Boussinesq approximation. I would then impose a steady distribution of T' on the vessel walls and see what circulation results (I have done exactly this using my own Fortran code, but with a uniform Cartesian mesh that doesn't adequately resolve the wall boundary layers).

So far with OpenFoam I have taken the tack of splitting the detector into four layers, assigning each layer its own (total) wall temperature, and having buoyantSimpleFoam solve for the (3D, steady state) flow (I hope to eventually be able to use "groovyBC" to get a more continuous vertical profile of wall temperature). The solution is looking not unreasonable, but, after days of calculation (with halts to look at the fields) I see it does not exhibit the axial symmetry it should possess. At first I thought it was just a case of needing more iterations, or more demanding convergence parameters, but I've begun to suspect it may be the result of some asymmetry in the mesh created by snappyHexMesh. I did run checkMesh, and the mesh failed two tests ("2 highly skew faces detected which may impair the quality of the results... 2 faces with concave angles between consecutive edges") but I was so happy to finally be able to do a run that I didn't pause to try to remedy those issues.

I'll tack in a few images to give a sense of the geometry & imposed wall temperature, the mesh, and the emerging (asymmetric) mean flow. Thanks again, John.

[JayDeeUU]

Unfortunately it had never occurred to me that the gravity vector "g" might be defined to align with the y (or x2) axis rather than with z (or x3)! My axis of symmetry is z, but I had carried over a "g" file that has gravity aligned with y! As a meteorologist I'm habituated to using z as vertical coordinate... but was well aware that's not the case in other fields, so ought to have checked.