|
[Sponsors] |
May 28, 2010, 07:01 |
|
#81 |
New Member
Join Date: Oct 2009
Posts: 15
Rep Power: 17 |
Hmm, I see. I was waaay off!
I think I'll take your approach and define it all myself. I don't mid it taking a little extra time. It's confusing enough without running scripts that I know nothing about. The fluid domain is indeed a little tricky in blockMesh so my plan now is to make two meshes in gmsh - one for the fluid domain, one for the solid and gmshToFoam them. I need some clarifications though as to what goes where? 0-folder: contains domain folders with their respective data fields and polyMesh folders? constant-folder: regionProperties file and domain folders. Each domain has properties files, no polyMeshes here? system: fv-files and a controlDict. The individual domain folders has fv-files but no changeDictionaryDict's? |
|
May 28, 2010, 07:47 |
|
#82 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
This is how I do it in the approach I propose:
0-folder: contains domain folders with their respective data fields without polyMesh folders. constant-folder: regionProperties file and domain folders. Each domain has properties files, AND polyMeshes folder. system: in main folder controlDict and individual domain folders. In domain subfolers: fv-files. (no changeDictionaryDict is required, it is used for automatic decomposition) I also note, that the polyMesh folders require only standard files in them: boundary, owner, neighbour, points, faces. All other may be thrown out (repeating after Einstein: "make everything as simple as possible, but not simpler" ) I attach a picture showing "general idea" of multi region structure I use. Hope it helps a bit |
|
May 28, 2010, 09:55 |
|
#83 |
New Member
Join Date: Oct 2009
Posts: 15
Rep Power: 17 |
Thanks a bunch for all your help, I really appreciate it! So polyMesh goes in the constant directory, makes sense. I've made a new case based on your layout, simplified it to one fluid and one solid domain, changed the files accordingly but I get an error trying to run the solver.
Code:
--> FOAM FATAL ERROR: patch type 'patch' not type 'directMappedPatchBase' for patch fluidToSolid of field T in file "~/run/0/fluid/T" From function solidWallMixedTemperatureCoupledFvPatchScalarField::solidWallMixedTemperatureCoupledFvPatchScalarField ( const fvPatch& p, const DimensionedField<scalar, volMesh>& iF, const dictionary& dict ) Code:
fluidToSolid { type solidWallMixedTemperatureCoupled; neighbourFieldName T; K K; value uniform 300; } The case can be found here for those interested. |
|
May 28, 2010, 10:23 |
|
#84 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
When you use solidWallMixedTemperatureCoupled the coupling is not only done in the data file (in T) but also at the mesh level, that is in boundary file.
I explained the needed modifications in the boundary file in the post at 15.05.10. In the end- you set things in T files exaclty as you did, and modify the boundaries as in the cited post. Good luck |
|
May 28, 2010, 10:50 |
|
#85 |
New Member
Join Date: Oct 2009
Posts: 15
Rep Power: 17 |
OK, I added the coupling to my boundary files. I had also forgot to scale the mesh (it was 3000m instead of 3000mm ) before converting it.
Also, the number nFaces in fluidToSolid and solidToFluid differ (279 vs 234). That would indicate that the two meshes do not line up properly and I'm guessing that is a big no-no? * *scratch that I just checked and they fit perfectly. Last edited by menorka; May 28, 2010 at 10:53. Reason: added comment |
|
May 28, 2010, 10:54 |
|
#86 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Exactly- mesh at the coupled patches should be 1:1
In fact I never tried to run a case with non-matching patches, maybe it would work. But I would strongly doubt in the acquired results... |
|
May 28, 2010, 11:02 |
|
#87 |
New Member
Join Date: Oct 2009
Posts: 15
Rep Power: 17 |
When I check the meshes in gmsh they fit perfectly. Should nFaces be the same number? Could it be gmshToFoam that skews them? Might have to start a new thread in the meshing subforum.
|
|
May 28, 2010, 11:16 |
|
#88 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
I looked up the the case you attached. Do the following:
run in console: Code:
paraFoam -touch -region fluid paraFoam -touch -region solid paraview The next problem that you will encounter after you repair wrong face grouping will be in data files. You did not specify dimensions of some data (for example solid cp). Best, Paweł |
|
May 29, 2010, 19:53 |
|
#89 |
Senior Member
Join Date: Jan 2010
Location: Stuttgart
Posts: 150
Rep Power: 16 |
Hi,
This thread is really good. But there is still a problem that I can not solve. I habe imported a mesh from Fluent with fluent3dMeshToFoam -writeSets -writeZones than I made setsToZones -noFlipMap and splitMeshRegions -cellZones and finally I moved all folders to their correct positions and corredted the boundarc conditions (I am thinking at least). and now I am getting this error message: Create time Create fluid mesh for region f-in for time = 0 Create fluid mesh for region f-vr for time = 0 Create fluid mesh for region f-et for time = 0 Create fluid mesh for region f-m-1 for time = 0 Create fluid mesh for region f-at for time = 0 Create fluid mesh for region f-out for time = 0 *** Reading fluid mesh thermophysical properties for region f-in Adding to thermoFluid Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>> Adding to rhoFluid Adding to KFluid Adding to UFluid Adding to phiFluid Adding to gFluid Adding to turbulence Selecting turbulence model type laminar Adding to DpDtFluid #0 Foam::error:rintStack(Foam::Ostream&) in "/root/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPOpt/libOpenFOAM.so" #1 Foam::sigFpe::sigFpeHandler(int) in "/root/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPOpt/libOpenFOAM.so" #2 Uninterpreted: #3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/root/OpenFOAM/OpenFOAM-1.6.x/lib/linuxGccDPOpt/libOpenFOAM.so" #4 void Foam::divide<Foam::fvsPatchField, Foam::surfaceMesh>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/root/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linuxGccDPOpt/chtMultiRegionFoam" #5 Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > Foam:perator/<Foam::fvsPatchField, Foam::surfaceMesh>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > const&) in "/root/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linuxGccDPOpt/chtMultiRegionFoam" #6 main in "/root/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linuxGccDPOpt/chtMultiRegionFoam" #7 __libc_start_main in "/lib/tls/i686/cmov/libc.so.6" #8 _start at /build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:122 Floating point exception It would be really great, if someone can tell me what can be the Problem in "Adding to DpDtFluid"? Thanks in advance! Regards Chrisi |
|
May 30, 2010, 11:25 |
|
#90 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Hello Chrisi,
it seems to me we have a typical "division by zero" problem. Your error is definitely at line 133 of createFluidFields.H. In there you have: Code:
132: Info<< " Adding to DpDtFluid\n" << endl; 133: DpDtFluid.set ( i, new volScalarField ( "DpDt", fvc::DDt ( surfaceScalarField ( "phiU", phiFluid[i]/fvc::interpolate(rhoFluid[i]) ), thermoFluid[i].p() ) ) ); Best, Paweł |
|
May 31, 2010, 02:59 |
Thank you
|
#91 |
Senior Member
Join Date: Jan 2010
Location: Stuttgart
Posts: 150
Rep Power: 16 |
Hi,
thank you very much. The problem was that the initial value of the pressure was set to zero at the cut surface. Best Regards Chrisi |
|
May 31, 2010, 05:40 |
|
#92 |
New Member
Join Date: Oct 2009
Posts: 15
Rep Power: 17 |
||
June 21, 2010, 06:37 |
Wall turbulence functions
|
#93 |
Member
Robertas N.
Join Date: Mar 2009
Location: Kaunas, Lithuania
Posts: 53
Rep Power: 17 |
Hi *,
I'm trying to simulate a turbulent air flow over a solid heater with kEpsilon model. The question is -- how to set up the turbulent BC between the solid and fluid regions for the respective coefficients: k, epsilon, alphat. For domain boundary walls, the BCs can be set to compressible::alphatWallFunction, etc., but not for the boundaries between the fluid and solid regions. Are the BCs like "type calculated; value uniform 0;" or "type zeroGradient" acceptable? |
|
June 21, 2010, 08:13 |
|
#94 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Hi r08n,
consider that the coupling between regions is done only on "T". All the rest of the fields exist somewhat "separately". You should be allowed to set any "standard" BC. Thats how I understand it. The practical applications may vary Best, Pawel |
|
June 24, 2010, 06:27 |
|
#95 |
Member
Michea Ferrari
Join Date: Mar 2010
Location: Switzerland
Posts: 30
Rep Power: 16 |
Hi Pawel, hi all,
I have a question related to the usage of the heat flux. I have my cell (always the one I have already show you, see images attached at my previous posts) and therefore the interface between the two regions (FLUID and SOLID (cylinder)) is the lateral surface of the cylinder. I want to insert an heat flux at the bottom of each region (FLUID_BOTTOM) and (CYLINDER_BOTTOM) using: Code:
FLUID_BOTTOM { type solidWallHeatFluxTemperature; K K; q uniform 25e04; // [W m⁻2] value uniform 293; // initial Temp [K] } Code:
CYLINDER_BOTTOM { type solidWallHeatFluxTemperature; K K; q uniform 25e04; // [W m⁻2] value uniform 293; // initial Temp [K] } I have tried with: Code:
FLUID_to_SOLID { type solidWallMixedTemperatureCoupled; value uniform 293; neighbourFieldName T; K K; } Code:
SOLID_to_FLUID { type solidWallMixedTemperatureCoupled; value uniform 293; neighbourFieldName T; K K; } So I have tried to use: Code:
type zeroGradient; Code:
type solidWallMixedTemperatureCoupled; value uniform 293; neighbourFieldName T; K K; The internal field of the temperature (in the T dictionary) is for the two cases: uniform 293 in the whole domain. Can you please help me? Many Thanks Best Regards Michea |
|
June 24, 2010, 06:39 |
|
#96 |
Senior Member
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 23 |
Hi Michea...
what version are you using? If you have 1.6, there may be a bug: http://www.cfd-online.com/Forums/ope...n-problem.html Hope it helps, mad |
|
June 24, 2010, 09:14 |
|
#97 |
Member
Michea Ferrari
Join Date: Mar 2010
Location: Switzerland
Posts: 30
Rep Power: 16 |
Hi Maddalena,
thanks for your hint, I have modified the solver! However what I asked was a bit different (or maybe I have wrong understood ), I do not know what entries I have to add in the interface between the two regions (solid and fluid) because the heat flux is set at the bottom of the fluid as well as the solid region. The the heat flux (due to convection and conduction) between the cylinder mantel (lateral surface, the interface between the two regions) and the surrounding fluid is not know and therefore I do not know what entries I have to use. Maybe can you help me... Many thanks |
|
June 24, 2010, 09:33 |
|
#98 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Hello,
first, thank you Maddalena for pointing the bug-topic out. The general idea shown there seems very important. regarding Michea's question. Remember that the only way to couple regions using chtMultiReigionFoam is to use solidWallMixedTemperatureCoupled. If you do not use this type of BC for both patches of coupled regions, then they are simply not coupled. We can not therefore discuss about proper heat flux, etc. If in addition you add constant heat flux on other patches (like you did), it should simply work. Coupling is one thing, behavior of a system due to constant heat flux from one side is another. And last "food-for-thought". I could not find much (if any) literature about "proper" way of decoupling system and solving it in an iterative method like in chtMultiRegionFoam. Even though the OF-Team made a great effort by creating the code, they did not support us with a lot of documentation I have some doubts if the proposed method is the right one. But maybe this is just me Best, Pawel |
|
June 24, 2010, 09:53 |
|
#99 | |
Senior Member
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 23 |
Hello,
well, happy to be useful, but these are really my first steps inside cht! Quote:
Cheers, mad |
||
June 24, 2010, 11:56 |
|
#100 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Hi,
I just ment using solidWallHeatFluxTemperature of course you should be able to get similar results, if you impose fixedGratient such that: FG = Qtot / Area where FG is the FixedGradient value, Qtot is the constant total Heat flux, and Area is the area of the patch that we apply the HF to. It all goes to using Neumann boundary condition types (fixed gradients). And once again I state- the coupling patches do not have anything to do with other boundaries. It also does not matter if you have solid-solid or solid-fluid connection. In fact, I would not even use the term "boundary condition" but "coupling condition", since they are inside the whole system. Maybe I am talking the thing a bit over, but consider an example: two connected square solid boxes. We create a system by coupling the connection face for each of the boxes (by using "special BC" called solidWallMixedTemperatureCoupled). From that moment, this connection becomes part of the "temperature interior" of the system. All the other patches that are pointing "outside" of the system should be considered as "boundary patches". We can apply any possible and allowed boundary condition types to them. So fixedGradient, fixedValue, solidWallHeatFlux, zeroGradient, bulkBody, you name it (I am not sure about "calculated" type). Hope I did not shade the general idea too much and that this helps you a bit Best, Pawel |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
---------Tutorial help | mech | FLUENT | 4 | May 16, 2007 03:43 |
tutorial 6 in Fluent 6.2 tutorial and Mesh | pilli4u | FLUENT | 2 | April 2, 2007 06:09 |
3D Tutorial | MJ | FLUENT | 0 | January 16, 2007 09:45 |
tutorial | masood yooceframandi | FLUENT | 1 | January 25, 2005 13:28 |
tutorial | adil | FLUENT | 0 | March 8, 2004 04:48 |