CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

attachDetach Topology Modifier: Proper Turbulent Boundary Conditions

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

Reply
 
LinkBack Thread Tools Display Modes
Old   May 2, 2012, 21:13
Default attachDetach Topology Modifier: Proper Turbulent Boundary Conditions
  #1
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 686
Rep Power: 17
mturcios777 will become famous soon enough
Hello Foamers!

I've been playing around with the attachDetach topology modifier and have been itching to get it working with turbulence. I've got two cases that I've tried with laminar flow, both of which work well (in the sense that they don't crash) which I've uploaded with this thread. They are based on the TJunction case for pimpleFoam, with the extra feature of a "valve" that closes off flow into one of the branches.

I would be more than happy to make this a wiki page once I get it working to help other users. This is for OF21x, but the procedure is the same for anything since 16ext as well

To run both cases (TJunctionClosedFirst and TJunctionOpenFirst) under 21x, you'll need to unpack attachDetachFvMesh.tar.gz to $FOAM_SRC/topoChangerFvMesh and add
Code:
attachDetachFvMesh/attachDetachFvMesh.C
to the Make/options file right after the line for rawTopoChangerFvMesh. This is simply the attachDetachFvMesh from 16ext adapted to work with 21x. Recompile the topoChangerFvMesh library and you are good to go.

Both cases use pimpleDyMFoam, and have a Allrun script that creates the meshes and run the simulations. TJunctionClosedFirst has to merge two meshes (unless there is an easier way of creating walls for the valve), so after the simulation has run there will be a new directory TJunction which contains the actual data.

Run both cases as-is to see the laminar behaviour, which proves the topology modifier works as it should. To run turbulent, change the appropriate line in constant/RASProperties (for TJunctionClosedFirst, you'll need to change it in TJunction1/constant/RASProperties). The error occurs somewhere in the turbulence->correct() call after the faces go from being internal to boundary patches. This seems to be related to values of k or epsilon being zero somewhere:
Code:
Courant Number mean: 0.220134 max: 0.499147
deltaT = 0.000298507
Time = 2

bool attachDetach::changeTopology() const  for object valve : Triggering attach/detach topology change.
Current time: 2 current trigger time: 2 trigger index: 0
Modifier 0 named valve morphing
void attachDetach::detachInterface(polyTopoChange& ref) const  for object valve : Detaching interface
void attachDetach::detachInterface(polyTopoChange& ref) const  for object valve : Finished detaching interface
DILUPBiCG:  Solving for Ux, Initial residual = 0.00368108, Final residual = 1.66437e-06, No Iterations 2
DILUPBiCG:  Solving for Uy, Initial residual = 0.00279846, Final residual = 1.53383e-06, No Iterations 2
DILUPBiCG:  Solving for Uz, Initial residual = 0.00188171, Final residual = 4.48494e-07, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.520347, Final residual = 0.214301, No Iterations 1000
time step continuity errors : sum local = 0.00113155, global = -1.20446e-05, cumulative = -1.37368e-05
GAMG:  Solving for p, Initial residual = 0.135724, Final residual = 0.0419013, No Iterations 1000
time step continuity errors : sum local = 0.000493047, global = -2.032e-05, cumulative = -3.40569e-05
#0  Foam::error::printStack(Foam::Ostream&) in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigFpe::sigHandler(int) in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2  Uninterpreted: 
#3  Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#4  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libincompressibleRASModels.so"
#5  Foam::incompressible::RASModels::RNGkEpsilon::correct() in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libincompressibleRASModels.so"
#6  
 in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/bin/pimpleDyMFoam"
#7  __libc_start_main in "/lib/libc.so.6"
#8  
 at /usr/src/packages/BUILD/glibc-2.11.3/csu/../sysdeps/i386/elf/start.S:122
I've tried adding a limiter to the turbulence model by bounding k and epsilon by kMin and epsilonMin which seems to allow the code to proceed further, but then I get an error about nut:
Code:
Courant Number mean: 0.22037 max: 0.498308
deltaT = 0.000299285
Time = 2

bool attachDetach::changeTopology() const  for object valve : Triggering attach/detach topology change.
Current time: 2 current trigger time: 2 trigger index: 0
Modifier 0 named valve morphing
void attachDetach::detachInterface(polyTopoChange& ref) const  for object valve : Detaching interface
void attachDetach::detachInterface(polyTopoChange& ref) const  for object valve : Finished detaching interface
DILUPBiCG:  Solving for Ux, Initial residual = 0.0038858, Final residual = 1.30384e-06, No Iterations 2
DILUPBiCG:  Solving for Uy, Initial residual = 0.00278652, Final residual = 1.56476e-06, No Iterations 2
DILUPBiCG:  Solving for Uz, Initial residual = 0.00193932, Final residual = 4.80674e-07, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.52962, Final residual = 0.243818, No Iterations 1000
time step continuity errors : sum local = 0.00127258, global = 8.9244e-07, cumulative = 8.88314e-07
GAMG:  Solving for p, Initial residual = 0.126708, Final residual = 0.0158993, No Iterations 1000
time step continuity errors : sum local = 0.000205975, global = -1.05775e-05, cumulative = -9.6892e-06
bounding k, min: -1.5986e-51 max: 1.44949 average: 0.190389
bounding epsilon, min: -1.59926e-51 max: 152.799 average: 15.3409
correct RASModel
Create new G field
Update G at wall
Dissipation equation
DILUPBiCG:  Solving for epsilon, Initial residual = 0.00342873, Final residual = 7.04553e-06, No Iterations 1
DILUPBiCG:  Solving for k, Initial residual = 0.00850805, Final residual = 7.2587e-08, No Iterations 2
#0  Foam::error::printStack(Foam::Ostream&) in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigFpe::sigHandler(int) in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2  Uninterpreted: 
#3  Foam::incompressible::RASModels::nutkWallFunctionFvPatchScalarField::calcNut() const in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libincompressibleRASModels.so"
#4  Foam::incompressible::RASModels::nutkWallFunctionFvPatchScalarField::updateCoeffs() in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libincompressibleRASModels.so"
#5  Foam::fvPatchField<double>::evaluate(Foam::UPstream::commsTypes) in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/bin/pimpleDyMFoam"
#6  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/bin/pimpleDyMFoam"
#7  Foam::incompressible::RASModels::kEpsilon::correct() in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/lib/libincompressibleRASModels.so"
#8  
 in "/home/mturcios/OpenFOAM/OpenFOAM-2.1.x/platforms/linuxGccDPOpt/bin/pimpleDyMFoam"
#9  __libc_start_main in "/lib/libc.so.6"
#10  
 at /usr/src/packages/BUILD/glibc-2.11.3/csu/../sysdeps/i386/elf/start.S:122
Floating point exception
which suggests I should try limit nuEff or nu (I'm not terribly experienced with the inner workings of the turbulence models, just enough to make some basic modifications).

Hopefully this is something small that can be dealt with through boundary conditions. Note that I've tried this case in 1.6ext and get similar errors, which again lead me to believe that its a boundary condition problem.

Thanks!
Attached Files
File Type: gz attachDetachFvMesh.tar.gz (2.5 KB, 33 views)
File Type: gz TJunctionOpenFirst.tar.gz (6.8 KB, 34 views)
File Type: gz TJunctionClosedFirst.tar.gz (12.3 KB, 23 views)

Last edited by mturcios777; May 3, 2012 at 15:26. Reason: Change in second error message
mturcios777 is offline   Reply With Quote

Old   May 7, 2012, 21:27
Default
  #2
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 686
Rep Power: 17
mturcios777 will become famous soon enough
Some good news everyone! I found the reason behind the crash. With the change in topology, the viscosity boundary conditions are incorrectly applied/interpolated because I was using a Newtonian viscosity model. One solution is to add the following to the correct() function in $FOAM_SRC/transportModels/incompressible/viscosityModels/Newtonian/Newtonian.H

Code:
nu_ = nu0_;
I think the other models calculate the viscosity every time, so its not an issue. I wish I could only do that when the mesh changes for Newtonian, but there is no access to the mesh from transportModel (that I know of, if I am wrong I would love to know how to do it to save some function calls). I've tested it with kEpsilon, but as long as you limit k and epsilon at the start of turbulence->correct when the mesh changes you should be okay.

I'm now working on compressible flow (altering rhoPimpleFoam -> rhoPimpleDyMFoam). Thus far it crashes when solving the pressure equation, because of the density field not being remade properly. I think it has to do with updating the BC's with the topology change. If anyone has more experience with the thermo models implementation, it would be greatly appreciated.

Last edited by mturcios777; May 8, 2012 at 20:02. Reason: typo
mturcios777 is offline   Reply With Quote

Old   September 12, 2012, 16:18
Default
  #3
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 686
Rep Power: 17
mturcios777 will become famous soon enough
Wow, 5 months is a long time. I've been working on other projects while taking the occasional eye to getting this to work. I've asked the developers and came to the knowledge that faces created by inflation are swept into position and thus have a mesh flux associated with them. Or at least they should be: I found that the following code needs to be added to the attachDetachFvMesh::update function

[CODE]
pointField newPoints = points();
movePoints(newPoints);
[CODE]

This ensures that the attachDetach faces have the zero mesh flux that is required. I'm not sure why the default values for meshPhi are crazy, but adding this code makes things work.

I'm doing some testing to see if the same will work for layer addition and removal, which I've also been working on off and on.
mturcios777 is offline   Reply With Quote

Old   September 13, 2012, 05:24
Default
  #4
Senior Member
 
Join Date: Oct 2009
Posts: 136
Rep Power: 7
Peter_600 is on a distinguished road
Hi! I had similar problems with the attach/detach boundaries while using turbulence models.
I am happy that you fixed the problem.

Here is the link, how I got rid of this problem.
engine simulation with mesh motion and topological changes

Do you have experiences with attach/detach boundaries in parallel ? I guess you are also interested in engine simulations.

Here is my problem

attach detach in parallel

Peter
Peter_600 is offline   Reply With Quote

Old   September 13, 2012, 05:56
Default
  #5
Senior Member
 
Join Date: Oct 2009
Posts: 136
Rep Power: 7
Peter_600 is on a distinguished road
Hi! I had similar problems with the attach/detach boundaries while using turbulence models.
I am happy that you fixed the problem.

Here is the link, how I got rid of this problem.
engine simulation with mesh motion and topological changes

Do you have experiences with attach/detach boundaries in parallel ? I guess you are also interested in engine simulations.

Here is my problem

attach detach in parallel

Peter
Peter_600 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
Integral boundary conditions turbulent intensitylength boundary conditions olesen OpenFOAM Running, Solving & CFD 0 July 27, 2006 08:18
Turbulent boundary conditions for bubble column anjai FLUENT 12 October 17, 2005 07:34
New topic on same subject - Flow around race car Tudor Miron CFX 15 April 2, 2004 06:18
Please help with flow around car modelling! Tudor Miron CFX 17 March 19, 2004 20:23
Turbulent Mass Injection Boundary Conditions B. Laubacher Main CFD Forum 6 October 16, 1999 12:56


All times are GMT -4. The time now is 23:44.