|
[Sponsors] |
November 21, 2008, 15:12 |
Wolfgang: Try "execFlowFunctio
|
#61 |
Member
Ville Tossavainen
Join Date: Mar 2009
Posts: 60
Rep Power: 17 |
Wolfgang: Try "execFlowFunctionObjects".
|
|
November 24, 2008, 05:41 |
Thanks, something works. But a
|
#62 |
Senior Member
Wolfgang Heydlauff
Join Date: Mar 2009
Location: Germany
Posts: 136
Rep Power: 21 |
Thanks, something works. But at the end I get and error message and no forces-folder is created. Since I'm not common with C++ I can not get info out of the error message.
================================================== ====== Time = 1.995 Reading phi Reading U Reading p Selecting incompressible transport model Newtonian Selecting RAS turbulence model SpalartAllmaras SpalartAllmarasCoeffs { alphaNut 1.5; Cb1 0.1355; Cb2 0.622; Cw2 0.3; Cw3 2; Cv1 7.1; Cv2 5; } Time = 2 Reading phi Reading U Reading p Selecting incompressible transport model Newtonian Selecting RAS turbulence model SpalartAllmaras SpalartAllmarasCoeffs { alphaNut 1.5; Cb1 0.1355; Cb2 0.622; Cw2 0.3; Cw3 2; Cv1 7.1; Cv2 5; } *** glibc detected *** execFlowFunctionObjects: corrupted double-linked list: 0x00000000006f20f0 *** ======= Backtrace: ========= /lib64/libc.so.6[0x2b1f578da21d] /lib64/libc.so.6[0x2b1f578da346] /lib64/libc.so.6[0x2b1f578dbd1b] /lib64/libc.so.6(cfree+0x76)[0x2b1f578dbf76] /home/projects/OpenFOAM/ThirdParty/gcc-4.3.1/platforms/linux64/lib64/libstdc++.s o.6(_ZNSt19basic_ostringstreamIcSt11char_traitsIcE SaIcEED0Ev+0xba)[0x2b1f571970c a] /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libOpenFOAM.so(_ZN4Foam 13OStringStreamD0Ev+0x41)[0x2b1f56a22c11] /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libOpenFOAM.so(_ZN4Foam 5errorD2Ev+0x33)[0x2b1f569e22b3] /lib64/libc.so.6(__cxa_finalize+0x85)[0x2b1f5789f6f5] /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libOpenFOAM.so[0x2b1f56 9e1d46] ======= Memory map: ======== 00400000-00433000 r-xp 00000000 08:07 6521925 /home/projects/OpenFOAM/OpenFOAM-1.5/applications/bin/linux64GccDPOpt/execFlowFu nctionObjects 00633000-00634000 r--p 00033000 08:07 6521925 /home/projects/OpenFOAM/OpenFOAM-1.5/applications/bin/linux64GccDPOpt/execFlowFu nctionObjects 00634000-00635000 rw-p 00034000 08:07 6521925 /home/projects/OpenFOAM/OpenFOAM-1.5/applications/bin/linux64GccDPOpt/execFlowFu nctionObjects 00635000-0092f000 rw-p 00635000 00:00 0 [heap] 2b1f544fe000-2b1f5451a000 r-xp 00000000 08:06 1786045 /lib64/ld-2.6.1.so 2b1f5451a000-2b1f5451c000 rw-p 2b1f5451a000 00:00 0 2b1f54719000-2b1f5471b000 rw-p 0001b000 08:06 1786045 /lib64/ld-2.6.1.so 2b1f5471b000-2b1f551b9000 r-xp 00000000 08:07 6328395 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libfiniteVolume.so 2b1f551b9000-2b1f553b9000 ---p 00a9e000 08:07 6328395 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libfiniteVolume.so 2b1f553b9000-2b1f553ee000 r--p 00a9e000 08:07 6328395 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libfiniteVolume.so 2b1f553ee000-2b1f553f6000 rw-p 00ad3000 08:07 6328395 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libfiniteVolume.so 2b1f553f6000-2b1f553fa000 rw-p 2b1f553f6000 00:00 0 2b1f553fa000-2b1f5545c000 r-xp 00000000 08:07 6328391 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleTransp ortModels.so 2b1f5545c000-2b1f5565b000 ---p 00062000 08:07 6328391 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleTransp ortModels.so 2b1f5565b000-2b1f5565d000 r--p 00061000 08:07 6328391 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleTransp ortModels.so 2b1f5565d000-2b1f5565e000 rw-p 00063000 08:07 6328391 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleTransp ortModels.so 2b1f5565e000-2b1f5584d000 r-xp 00000000 08:07 6328431 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleRASMod els.so 2b1f5584d000-2b1f55a4c000 ---p 001ef000 08:07 6328431 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleRASMod els.so 2b1f55a4c000-2b1f55a51000 r--p 001ee000 08:07 6328431 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleRASMod els.so 2b1f55a51000-2b1f55a54000 rw-p 001f3000 08:07 6328431 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleRASMod els.so 2b1f55a54000-2b1f55a55000 rw-p 2b1f55a54000 00:00 0 2b1f55a55000-2b1f55b9f000 r-xp 00000000 08:07 6328420 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleLESMod els.so 2b1f55b9f000-2b1f55d9e000 ---p 0014a000 08:07 6328420 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleLESMod els.so 2b1f55d9e000-2b1f55da5000 r--p 00149000 08:07 6328420 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleLESMod els.so 2b1f55da5000-2b1f55da7000 rw-p 00150000 08:07 6328420 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libincompressibleLESMod els.so 2b1f55da7000-2b1f55da8000 rw-p 2b1f55da7000 00:00 0 2b1f55da8000-2b1f55df4000 r-xp 00000000 08:07 6328409 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libbasicThermophysicalM odels.so 2b1f55df4000-2b1f55ff3000 ---p 0004c000 08:07 6328409 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libbasicThermophysicalM odels.so 2b1f55ff3000-2b1f55ff5000 r--p 0004b000 08:07 6328409 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libbasicThermophysicalM odels.so 2b1f55ff5000-2b1f55ff6000 rw-p 0004d000 08:07 6328409 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libbasicThermophysicalM odels.so 2b1f55ff6000-2b1f5603a000 r-xp 00000000 08:07 6328398 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libspecie.so 2b1f5603a000-2b1f5623a000 ---p 00044000 08:07 6328398 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libspecie.so 2b1f5623a000-2b1f5623c000 r--p 00044000 08:07 6328398 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libspecie.so 2b1f5623c000-2b1f5623d000 rw-p 00046000 08:07 6328398 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libspecie.so 2b1f5623d000-2b1f5623e000 rw-p 2b1f5623d000 00:00 0 2b1f5623e000-2b1f563c9000 r-xp 00000000 08:07 6328401 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libcompressibleRASModel s.so 2b1f563c9000-2b1f565c9000 ---p 0018b000 08:07 6328401 /home/projects/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libcoAbgebrochen |
|
November 25, 2008, 10:05 |
@Wolfgang:
have alook at ht
|
#63 |
Guest
Posts: n/a
|
@Wolfgang:
have alook at http://www.cfd-online.com/cgi-bin/Op...how.cgi?1/9986 Maybe useful for you. Paul |
|
November 25, 2008, 16:03 |
Wolfgang: I guess there's some
|
#64 |
Member
Ville Tossavainen
Join Date: Mar 2009
Posts: 60
Rep Power: 17 |
Wolfgang: I guess there's something wrong with the application. Try to recompile it by going to "/applications/utilities/postProcessing/miscellaneous/execFlowFunctionObjects" and type "wmake". Hope it works!
|
|
November 28, 2008, 05:43 |
yes, thank you. after "wmake"
|
#65 |
Senior Member
Wolfgang Heydlauff
Join Date: Mar 2009
Location: Germany
Posts: 136
Rep Power: 21 |
yes, thank you. after "wmake" and copying the function (here: forces) to the end of the controlDict it workt. it wrote me a folder with "force" an "forceCoeffs". unfurtunately it created for each timestep one folder with one file inside with the forces.
hmm, well, one could write a tool to combine them in one file. So better insert the function into the controlDict before :-) |
|
November 28, 2008, 06:18 |
Is there any way for OpenFOAM
|
#66 |
Member
Terry Barnaby
Join Date: Mar 2009
Location: Beam Ltd, UK
Posts: 44
Rep Power: 17 |
Is there any way for OpenFOAM to calculate the value of Aref from a named patch ?
I am trying to get a VWT to work using OpenFOAM and have a simple car design produced using Blender. To get a useful value for Cd I need to determine Aref for that design ... I guess what would be nice, for me, is to allow Aref to be calculated for the maned patch in forceCoeffs if Aref is not given ... |
|
December 11, 2008, 06:03 |
Hi everybody,
Did anyone c
|
#67 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
Hi everybody,
Did anyone compare the force calculation in OF-1.5.x with the calculation (using liftDrag code) of OF-1.4.1. I see little differences, so I wonder if anyone did make some comparison. Regards, Frank
__________________
Frank Bos |
|
December 11, 2008, 09:10 |
Hello All,
A very interesting
|
#68 |
Senior Member
Mark Couwenberg
Join Date: Mar 2009
Location: Netherlands
Posts: 130
Rep Power: 17 |
Hello All,
A very interesting subject. One question / remark: I use OF1.5. I noticed that force functions are not available when using interFoam. I get exactly the same error messages as Wolfgang copied in. Rebuilding execFuntion... did not work. However, now I use rasInterFoam with turbulence switched off if I want the functions. Funny though, looking in the code I can't really see where the difference is made. Brgds, Mark |
|
December 11, 2008, 12:04 |
I mean,
Output of forces us
|
#69 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
I mean,
Output of forces using liftDrag library from OF-1.4.1 gives different results compared to the forceObjects in OF-1.5. I can't see any real difference in the implementation. Could someone please comment on this? Thanks, Frank
__________________
Frank Bos |
|
December 11, 2008, 13:18 |
Allright guys, I found where t
|
#70 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
Allright guys, I found where the difference comes from, but I don't see why. The pressure component gives exactly the same result, but the viscous force component doens't. So what is the correct implementation OF1.4.1 or OF-1.5.x?
The viscous component is defined as: OF-1.4.1: -mu.value()*U.boundaryField()[patchLabel].snGrad() *mesh.magSf().boundaryField()[patchLabel] OF-1.5.x: mesh.Sf().boundaryField()[patchLabel] & -*nu*dev(twoSymm(fvc::grad(U)))[patchLabel]; btw, I dropped the rho wince I work laminar incompressible. Could anyone please comment on this different implementation? Thanks, Frank
__________________
Frank Bos |
|
December 12, 2008, 07:25 |
This is probably a rather stup
|
#71 |
Member
Leonardo Honfi Camilo
Join Date: Mar 2009
Location: Delft, Zuid Holland, The Netherlands
Posts: 60
Rep Power: 17 |
This is probably a rather stupid question but do the functions (force and forceCoeff) support multiple patch inputs,if so these should be separated by commas right?
|
|
December 12, 2008, 08:24 |
Hey Frank,
My guess is that
|
#72 |
Member
Pierre Le Fur
Join Date: Mar 2009
Location: UK
Posts: 60
Rep Power: 17 |
Hey Frank,
My guess is that with: viscous Stress = 2*mu*S - 2/3*mu*div(U)*delta S = grad(U) + grad(U).T 1.4.1: sngrad() = n.grad(U) magSf = Area 1.5 Sf() = Area*n twoSymm(grad(U)) = 2*(grad(U)) (assuming grad(U is symmetric)) = grad(U) + grad(U).T takeaway normal contribution with dev() = -1/3 *I so 1.5 is the more accurate implementation, I think. Pierre |
|
December 12, 2008, 08:53 |
I noticed that the viscous dra
|
#73 |
Member
Terry Barnaby
Join Date: Mar 2009
Location: Beam Ltd, UK
Posts: 44
Rep Power: 17 |
I noticed that the viscous drag component in by VWT simulation, which uses simpleFoam, when haywire when I used the LaunderSharmaKE RASModel in OpenFOAM 1.5.
Using the kEpsilon RASModel the results were closer to the liftDrag utility I was using in 1.4.1. |
|
December 12, 2008, 09:25 |
LaunderSharmaKE is a low-Re mo
|
#74 |
Member
Pierre Le Fur
Join Date: Mar 2009
Location: UK
Posts: 60
Rep Power: 17 |
LaunderSharmaKE is a low-Re model, where you need expected to have a adequate mesh resolution near the wall, i.e. no wall function. That might be your problem.
Pierre |
|
December 12, 2008, 09:32 |
I still don't know what is mor
|
#75 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
I still don't know what is more accurate. I think that the new formulation uses all stress components, but they should reduce to snGrad(U) at the wall. This is not the case when you mesh is not fine enough in the main direction of U.
This is what I found. Personally I prefer the new model, since it contains all stress terms from the Navier Stokes equations, it just more complete. Regards, Frank
__________________
Frank Bos |
|
December 12, 2008, 09:39 |
Hi Pierre,
Thanks for that
|
#76 |
Member
Terry Barnaby
Join Date: Mar 2009
Location: Beam Ltd, UK
Posts: 44
Rep Power: 17 |
Hi Pierre,
Thanks for that information. That makes sense as it had the most effect when the car was near the road surface "wall". |
|
January 12, 2009, 09:29 |
I've got one question regardin
|
#77 |
Member
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 17 |
I've got one question regarding the forceCoeffs output.
How can I write Cd and Cl not only in the forceCoeffs directory but also in the log file? Since there is an if-loop [if (log_) ...], I assume it should be possible without further scripting. |
|
January 12, 2009, 14:18 |
Hi guys,
just a theoretical
|
#78 |
Member
Patrick Bourdin
Join Date: Mar 2009
Posts: 40
Rep Power: 17 |
Hi guys,
just a theoretical comment about the viscous stress computation. for incompressible flow, the divergence of the transpose of Grad(U) is zero (because of div(U)=0), ie, using Einstein's convention and permutation of the spatial derivatives: div(grad(U).T) = d_i (d_j U_i) = d_j (d_i U_i) = 0 So for a Newtonian fluid with mu=constant, you end up with: div[mu*(grad(U)+grad(U).T)]=mu*div(grad(U)) Using the Green theorem when integrating over a control volume, you end up with: viscous force = mu * // n.grad(U) dS (where // stands for the double integral symbol) which is consistent with the library implemented in 1.4.1 for incompressible Newtonian flow. the force library in 1.5 is more general and can therefore handle compressible flow, nevertheless in incompressible flow they should give the same answer (@Pierre: I think the operator twoSymm takes the symmetric part of a tensor and multiply it by two, hence twoSymm(grad(U)) = 2*(0.5*(grad(U)+grad(U).T)) = grad(U) + grad(U).T, no symmetry assumption here). Patrick |
|
February 4, 2009, 17:17 |
Can someone comment on the for
|
#79 |
Member
Cem Albukrek
Join Date: Mar 2009
Posts: 52
Rep Power: 17 |
Can someone comment on the forces and forceCoeffs reported in a multi-phase solution output?
As there are multiple densities involved, I believe the force coefficients reported have to be tied to one of the media, as directed by the density chosen in the dictionary. How about forces? At first I found it strange that the disctionary required density input. Then I read in another thread that P output by OpenFOAM is P_true/density, which explains it all. In the same discussion, Pd turned out to be P_true. So in the interFOAM solution forces output, can I assume the "forces" output is based on Pd and correct? Thanks. Cem |
|
February 13, 2009, 13:54 |
Hi..I am a new user & I am usi
|
#80 |
Member
Join Date: Mar 2009
Posts: 41
Rep Power: 17 |
Hi..I am a new user & I am using OF-1.5.I am doing numerical study of flow past square cylinder for laminar-2D incompressible flow.I tried to simulate this using icoFoam.My simulation configuration was
Domain:15.5x12; Grid:51x62; Block:1x1 UInf=1m/s, Re = 250, deltaT = 0.001 run for 24s(as per the paper).I got vortex shedding but Cd Cl value what I got was unexpected!!! Pls...raise your hands to ur new friend. Give suggestion. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
CoupledFvScalarMatrix in OF15 | fisher | OpenFOAM Running, Solving & CFD | 9 | May 27, 2020 10:40 |
Fan type BC in OF15 | hsieh | OpenFOAM Running, Solving & CFD | 31 | July 30, 2015 13:22 |
Bug in patchIntegrateC OF15 | anger | OpenFOAM Bugs | 8 | May 29, 2009 05:36 |
OpenFOAMdev migration to OF15 | fisher | OpenFOAM Installation | 1 | November 25, 2008 15:39 |
Bug or a feature of OF15 | rafal | OpenFOAM Bugs | 5 | July 25, 2008 06:25 |