snappyHexMesh doesn't see stl/eMesh file and splitMeshregions doesn't detect regions
 

Hi
i am a new openfoam user, i am stuck with a simulation of the temperature evolution of a fluid in a pipe exposed to air, but every time i try to make the mesh for it splitmeshregions says only one region, doing nothing, i think that is caused by snappyhexmesh doen't detect my stl file or emesh file, there are no errors given at any stage of creating the mesh, the only thing that it gives is a warning:
FOAM Warning :
From Foam::treeBoundBox::treeBoundBox(const Foam::UList<Foam::Vector<double> >&)
in file meshes/treeBoundBox/treeBoundBox.C at line 70
No bounding box for zero-sized pointField

i am trying for weeks now to get splitMeshregions to work i have tried toposetdict, changing locationsInMesh ( because i do not know of the coordinates you chouse must be in the middle of the region or just in the region), i tried to find anything on the internet that could help, but either they didn't give the solution or i didn't understand it, does anyone know how to solve this ?

i set the files of the case in this link: https://1drv.ms/f/s!Agflt1nDTyHxhlNo...BjJ-I?e=ktYuwb

Hello,

This is your STL bounding box, in meters:
Your locationsInMesh don't match at all the dimensions of your STL file:
I feel like your exported a STL file in millimeter and forgot to scale it to meters. (since OpenFOAM works with meters)
You can use surfaceTransformPoints for that.

About the locationsInMesh: the coordinates must be anywhere inside the volume your want to mesh. The coordinates for your pipe look wrong.

Regards,
Yann

unfortunaly that's not the cause of my problem, that was just a problem with what i submitted to the forum, i have changed it now but i still get the same problem but thanks to put my attention to the fact i forgot to scale the stl and even if i set the location of the pipe on a place the pipe should be it gives still the same problem

Can you post your fixed case then?

here is the link: https://1drv.ms/f/s!Agflt1nDTyHxhlNo...BjJ-I?e=ceDinr

but with the previous link you now get the fixed cases to, because i simply changed what is in that folder where that link refers to

Your corrected case works fine.
Re-run the meshing from scratch using:

Yann

thanks a lot now splitmeshregions works, but when i tried to run the case with manual commands i got a warning at changedictonary and a error with chtMultiRegionFoam:

warning at changedictonary:
Merging entries from 6(minX maxX minY maxY minZ maxZ)
--> FOAM Warning :
From bool merge(bool, Foam::dictionary&, const Foam::dictionary&, bool, const Foam::HashTable<Foam::List<Foam::word> >&)
in file changeDictionary.C at line 304
Reading "/home/stijn/OpenFOAM/OpenFOAM-v2012/tutorials/own_cases/pipe_heat_loss_test/system/air/changeDictionaryDict.boundary" at line 21 to 41
Ignoring non-existing entry minY
--> FOAM Warning :
From bool merge(bool, Foam::dictionary&, const Foam::dictionary&, bool, const Foam::HashTable<Foam::List<Foam::word> >&)
in file changeDictionary.C at line 304
Reading "/home/stijn/OpenFOAM/OpenFOAM-v2012/tutorials/own_cases/pipe_heat_loss_test/system/air/changeDictionaryDict.boundary" at line 21 to 41
Ignoring non-existing entry maxY


and the error at chtMultiRegionFoam:

--> FOAM FATAL ERROR: (openfoam-2012)
cannot be called for a calculatedFvPatchField
on patch pipeenclosed_internalfluid of field U in file "/home/stijn/OpenFOAM/OpenFOAM-v2012/tutorials/own_cases/pipe_heat_loss_test/0/internalfluid/U"
You are probably trying to solve for a field with a default boundary condition.

From Foam::tmp<Foam::Field<Type> > Foam::calculatedFvPatchField<Type>::gradientIntern alCoeffs() const [with Type = Foam::Vector<double>]
in file fields/fvPatchFields/basic/calculated/calculatedFvPatchField.C at line 188.

but when i tried to run my case with the Allrun-serial-pre script (just a adapted Allrun-serial script) to get log files of all commands ( i didn't have one for splitmeshregions) then itr suddenly appeared to run fine, but i thougth the simulation would take a few hours, and i was thinking of seeing how it ran and then if nessary ask it here, but that simulation is now already running for more than half a day ( about 15 hours) and i have checked of it was not running in loops and unfortenaly it was running in loops, does anyone know why the case loops around without doing anything, you can see all files of the case in the link i have previously shared

Hello,

Have you tried cleaning up your case (Allclean) and running it again?
Your case works for me when running Allrun-parallel.

Cheers,
Yann

yes i tried that but i did it with Allrun-serial-pre (copy of Allrun-serial you can find it under the link that i posted with my previous post at splitmesregions work but running case doesn't work) and i just tried with Allrun-parallel and i got this error:

--> FOAM FATAL ERROR: (openfoam-2012)
[3] On patch procBoundary3to4 trying to access out of range neighbour processor 4. This can happen if
trying to run on an incorrect number of processors
[3]
[3] From virtual void Foam::processorPolyPatch::initUpdateMesh(Foam::Pst reamBuffers&)
[3] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 368.

and i have a i7-8750H proccesor with 6 cores, and how long dit the case take to run?, and with wat proccessor did you do it ? ( i am asking this because if you have a faster proccesor it is possible that your computer did it faster, and i want a estimation of how long it would take)

I used 4 cores and I don't know how long the case run, I just checked if it was running.

The Allrun-parallel script originally meshes on 6 cores and runs on 4 cores. This is why it uses redistributePar and also why you have 2 decomposeParDict files in system.

This could be simplified if you just intend to mesh and run on 6 cores.

it does not matter of it runs on 6 cores or 4 cores i just want to get the case running, but with Allrun serial it appears to run but even after 15 hours it doesn't get anywhere, and with Allrun-parallel it gets a error ( the error i had in my previous post, and it looks that it is running but it get stuck on that error, you don't see that there is anything wrong with it until you look to the log files, i think it has to do with the boundry's, that het doesn't reconise the boundry and that openfoam tries to calculate it, but it trying for a infinite length, but i do not know for sure, it is possible that this would give a much bigger spike in ram usage, i think that because it is running far longer than i expected and somethimes i saw that it said that there are continuity erors and combine that with the fact that it hasn't even got its first timestep after 15 hours of continuos calculations lets me think that it is running in a never ending loop

ps is it better to just open another thread for this or not ?

Alright, use the Allrun-parallel script attached. This will run on 4 cores. If you want to run on 6 cores, update the numberOfSubdomains parameter in system/decomposeParDict file.

I only checked if the solver is running, it would indeed probably be better to open a new thread if you can't manage to run it, or if you have another issue with the case.