CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Native Meshers: snappyHexMesh and Others

SnappyHex on a decomposed case

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By hayes

Reply
 
LinkBack Thread Tools Display Modes
Old   March 13, 2013, 04:06
Default SnappyHex on a decomposed case (disappearing boundary conditions)
  #1
Pj.
Member
 
Luca
Join Date: Mar 2013
Posts: 68
Rep Power: 4
Pj. is on a distinguished road
Hi everybody,

this is my first post, so I introduce myself: I`m an engineering student attending the last year of master degree at the Politecnico of Milan.

I am having some troubles with the parallel computing of snappyHex.

I need to use both snappyHexMesh and decomposePar. If I run snappyHex and then decomposePar there are not problem. In the boundary condition of p,U etc I`ve already inserted the XXX_patch0 that snappy hex will create. So after I`ve "snapped" it, I can decompose it and solve it.

Instead if I want to run snappyHex on multiple cores I have to decompose the case first. But the files p,U etc in the folders processorX "lose" the boundary conditions XXX_patch0. So, when i do the snappyHex and then i lauch the case, it gives me the error

keyword spires_patch0 is undefined in dictionary "/[...]/B0fine/processor0/0/p::boundaryField"

while it is

keyword spires_patch0 is undefined in dictionary "/[...]/B0fine/0/p::boundaryField"

how can i say to decomposePar to keep those boundary condition even if it doesn-t sees them in the blockmesh boundary file?

thank you very much

Last edited by Pj.; March 14, 2013 at 23:34.
Pj. is offline   Reply With Quote

Old   March 13, 2013, 06:47
Default
  #2
New Member
 
Join Date: Feb 2012
Posts: 6
Rep Power: 5
hayes is on a distinguished road
Hi Luca,

the problem is, after the meshing with snappyHexMesh there are no information about your stl patches within the processor directories (processor0, processor1, ...) yet. So what you can do is reconstruct the mesh back into one master mesh, remove the processor folders and decompose again. After these commands it should run without any problems:

blockMesh
decomposePar
mpirun --hostfile YOURHOSTFILE -np ... snappyHexMesh -overwrite -parallel
reconstructParMesh -constant
rm -r processor*
decomposePar
mpirun --hostfile YOURHOSTFILE -np ... simpleFoam -parallel

Best regards,
Chris
JR22 likes this.
hayes is offline   Reply With Quote

Old   March 13, 2013, 09:02
Default
  #3
Pj.
Member
 
Luca
Join Date: Mar 2013
Posts: 68
Rep Power: 4
Pj. is on a distinguished road
I'll try this tomorrow, but I don't understand: if during the first decomposePar the boundary conditions on XXX_patch0 get lost, when does it get recovered in the proces you showed me? Is it the "-constant" option of reconstructParMesh?
Pj. is offline   Reply With Quote

Old   March 13, 2013, 12:46
Default
  #4
New Member
 
Join Date: Feb 2012
Posts: 6
Rep Power: 5
hayes is on a distinguished road
the mesh that first gets decomposed is the one created by blockMesh. SO no patch exists other than specified in your boundaryDict. And consequently during decomposePar on this background mesh there is no need for decomposePar to copy any initial boundary information for patches that do not exist yet.

After snappyHexMesh the stl surface is included as a patch, but still without boundary information in 0 for the new patch.
hayes is offline   Reply With Quote

Old   March 13, 2013, 23:04
Default
  #5
Pj.
Member
 
Luca
Join Date: Mar 2013
Posts: 68
Rep Power: 4
Pj. is on a distinguished road
Oh... so during the decomposePar it looks if the boundary conditions in 0/* are useful, since it doesn't sees any XXX_patchX it discards those boundary condition.

The second time it reads again the boundary conditions in 0/* and since now those patches exists it keeps them.

Am I correct?

Anyway I'm trying right now. I will see...
Pj. is offline   Reply With Quote

Old   March 14, 2013, 23:34
Default
  #6
Pj.
Member
 
Luca
Join Date: Mar 2013
Posts: 68
Rep Power: 4
Pj. is on a distinguished road
I did what you said and it worked perfectly.

I`ve to say that I`m a bit surprised that in the decomposeParDict there isn`t an option to say it to keep all boundary conditions that appear in the 0 forlder fields, even those that refer to patches that are not (yet) in the constant/polyMesh/boundary file.

That would save all this kind of work around.

Anyway the problem has been solved so everythig is fine.

Thank you very much for the very fast help,

Bye
Pj. is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is Playstation 3 cluster suitable for CFD work hsieh OpenFOAM 9 August 16, 2015 14:53
Superlinear speedup in OpenFOAM 13 msrinath80 OpenFOAM Running, Solving & CFD 18 March 3, 2015 06:36
sample decomposed case Phicau OpenFOAM Post-Processing 0 October 13, 2011 07:09
Error reading new case montag dp FLUENT 5 September 15, 2011 06:00
Instable natural convection case Peter88 OpenFOAM 5 August 18, 2011 01:23


All times are GMT -4. The time now is 03:07.