|
[Sponsors] |
March 11, 2009, 11:25 |
Since some time I have been tr
|
#41 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Since some time I have been trying to work with multi region cases, also with chtMultiRegionFoam. As it was written in this topic, one needs some effort to view results in paraview. The way of doint it was described by Andrea Barbera on 24.07.2008. It works fine, but generates files with the same names for each region. In the end one can open every mesh in paraview, but working with them is a bit tricky... I allowed myself ot write a little bash script to help in this matter ;)
It uses foamToVTK for conversion (or is supposed to do so) and changes the filenames in each region to its name. Hope some of you will find it usefull ;) Pawel |
|
March 11, 2009, 12:07 |
the file:
|
#42 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
the file:
|
|
March 31, 2009, 01:56 |
|
#43 |
Member
Join Date: Mar 2009
Posts: 41
Rep Power: 17 |
hi..friends.
I am new to chtMultiRegionFoam. I want to change geometry as per my problem. I am not getting how to setup whole problem? I made outer domain using blockMeshDict file but not getting further...I think I have to make changes in makeCellSets.setSet file as per regionProperties. But setup of makeCellSets.setSet is not clear. Please guide me if any one have idea!!! Mehulkumar |
|
April 1, 2009, 04:20 |
|
#44 |
Member
Join Date: Mar 2009
Posts: 41
Rep Power: 17 |
hi...I was able to make geometry using makeCellSets.setSet.
Now as per Allrun it wants to read changeDictionaryDict file. Can anybody share information regarding this file.How to make it?How domains are define? Pls raise your hands for beginner. Thanks Mehulkumar |
|
April 6, 2009, 07:51 |
|
#45 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
hello mehulkumar,
this is my interpretation of how the changeDictionaryDict works, check it, I belive it is ok first of all you specify which fileds (files) to change: dictionaryReplacement { T {...} field2 {...} } In each of them you specify what to change so, if you write inside T: T { minY { type fixedValue; value uniform 500; } new_boundary { type calculated; } } It it will change minY and new_boundary to what you specify. Note that if there are no fields named minY or new_boundary nothing will happen. Is also appears that dict understands words like region0, solid2, fluid4 etc. I belive the numbers refer to alphabetical order in constant/regionProperties or simply from folder listing (you will have to check it) The other thing is that you need to have changeDictionaryDict in each of your system folder for each region you want to change. In the end, I prefer to change those things manualy and now I have one question: I have notticed that fields K are a bit different in fluid and solid regions. In solid ones, they are beeing read from files K and have dimension [ 1 1 -3 -1 0 0 0 ], when in fluid regions, they are beeing calculated: [I]thermof[i].alphaEff() * thermof[i].rho() * thermof.Cp() and their dimension is [2 -2 -3 -1 0 0 0] It seems that multiplication by rho is wrong. why is it like that? is it because solidWallHeatFluxTemperatureCoupled and solidWallTemperatureCoupled boundaries need it like that or is it some kind of mistake? Please give me some light on that matter. |
|
April 7, 2009, 07:55 |
Tutorial Case giving Problem
|
#46 |
Member
Velan
Join Date: Mar 2009
Location: India
Posts: 50
Rep Power: 17 |
Hi All,
I tried the tutorial case of MultiRegionFoam. But i got the following error message. vc@velan:~/OpenFOAM/vc-1.5-dev/tutorials/chtMultiRegionFoam/multiRegionHeater> chtMultiRegionFoam /*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 1.5-dev | | \\ / A nd | Web: http://www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ Exec : chtMultiRegionFoam Date : Apr 07 2009 Time : 16:31:07 Host : winslet PID : 18172 Case : /home/vc/OpenFOAM/vc-1.5-dev/tutorials/chtMultiRegionFoam/multiRegionHeater nProcs : 1 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create fluid mesh for region bottomAir for time = 0.001 Create fluid mesh for region topAir for time = 0.001 Create solid mesh for region heater for time = 0.001 Create solid mesh for region leftSolid for time = 0.001 Create solid mesh for region rightSolid for time = 0.001 *** Reading fluid mesh thermophysical properties for region bottomAir Adding to pdf Adding to thermof Selecting thermodynamics package hThermo<pureMixture<constTransport<specieThermo<hC onstThermo<perfectGas>>>>> Not Implemented Trying to construct an genericFvPatchField on patch bottomAir_to_leftSolid of field h From function genericFvPatchField<Type>::genericFvPatchField(con st fvPatch& p, const DimensionedField<Type, volMesh>& iF) in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 45. FOAM aborting Aborted I downloaded the case which send by Mattijs. Its working fine without any problem. - Velan |
|
April 7, 2009, 09:14 |
|
#47 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
hi Velan,
it seems that your basicThermo model can not create h field. if you look in the code, you will notice that h is created usually by class hThermo. The constructor is here: http://foam.sourceforge.net/doc/Doxy...ce.html#l00030 this field is generated from temperature filed T and other coeffs you specify in thermophysicalProperties. in my opinion you have some trouble with T filed. did you split mesh properly? did you change dictionaries properly? are the boundaries (and the field) of T correct? (maybe you have some misspeling?) (at the beginning check bottomAir region in 0.001 time) hope you will find this usefull and I repeat my question from 2 posts below: what is going on with K field in chtMultiregionFoam ? why the dimensiones do not match for fluid and solid fields? Pawel |
|
April 8, 2009, 01:37 |
solidWallMixedTemperatureCoupled is the problem
|
#48 |
Member
Velan
Join Date: Mar 2009
Location: India
Posts: 50
Rep Power: 17 |
Hi Pawel,
Thanks for your reply. I found the where is the problem. T file having the type bottomAir_to_leftSolid { type solidWallMixedTemperatureCoupled; SImulation running, If i changed the type to solidWallTemperatureCoupled, Any ideas ? - Velan |
|
April 8, 2009, 06:50 |
|
#49 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
hello Velan,
in chtMultiRegoinFoam you can select two specific wall types: solidWallTemperatureCoupled (swtc). solidWallHeatFluxTemperatureCoupled (swHFtc) and The swtc replaced its own boundary values with those of the neighbour region. It also gives you a new function: flux() which returnes the heat flux in W/m^2 calculated using values at the cell next to boundary: return Tw.snGrad()*patch().magSf()*Kw; Tw is this patch, snGrad() returnes gradient of the value between the cell center of the cell next to the boundary and the point at the boundary (it has a dimension!). patch().magSf() returnes dimensionless magnitude of face area Kw returnes dimensioned K value of the filed (thermal conductivity) The swHFtc sets the gradient function of the value at the wall. As far as I am concerned the solve() function calls the gradient function at some level to determine it for the matrixes. Usually it is determined somewhere else, but I swHFtc it is replaced by a new function. it looks like this: gradient() = refCast<const solidWallTemperatureCoupledFvPatchScalarField> (neighbourField).flux()/K; as you can see, here we call the flux() function that I described in swtc. We devide it by this fileds K (thermal conductivity) and get the gradient value between the regions scaled by their thermal conductivities. The conclusion is: if you want swHFtc to work, you will need swtc on the neighbour patch. You can have two swtc on bot regions, but this way you will set both boundaries as the value of the second filed (in fact they will not be coupled). This is just my interpretation of the code, I would be very grateful for verification by someone more expirienced but I hope it helps a bit. and in the end... my question about the solver and tutorial case! (will not let it go ) can anyone help me understand why the dimensiones of K does not match for solid and fluid? is this a bug or should it be like this? Pawel |
|
May 13, 2010, 10:49 |
|
#50 |
Member
Michea Ferrari
Join Date: Mar 2010
Location: Switzerland
Posts: 30
Rep Power: 16 |
Hi all,
As I can see there are all expert in cht, so I could ask some help for my problem related to the Mesh region: I have imported the mesh with Code:
fluent3DMeshToFoam Code:
splitMeshRegions Code:
Mapping field S terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast Aborted http://www.cfd-online.com/Forums/ope...shregions.html but nobody responds. Maybe here could I have more chance Another important things I would like to ask is why does the command Code:
fluentMeshToFoam Code:
fluent3DMeshToFoam (My .msh has already the regions specified, I need already to insert the commands [-writeSets] [-writeZones]?) Please help me... Thank you Best Regards Michea |
|
May 13, 2010, 13:49 |
|
#51 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
I recall we had a similar problem with exporting multi-region mesh from Fluent to OF.
Now, the thing depends on what do you want to achieve In my case, I did not work on Sets and Fields. Each region had its own mesh. (maybe this is obvious, but I am a bit out of touch with newest approaches used in this solver). In the end, if you simply want to get each region as a "separate" case connected by some coupling boundary condition, here is what we did: We used Ansys CFX to create the whole mesh. Then in the generator, we decomposed it into regions, and exported each region independently as a .msh file (fluent format). I am sure simmilar thing can be done in Gambit. Then, for each region we used fluent3DmeshToFoam in a tmp, non-multi-region OF study (i.e. icoFoam ), and moved acquired "polyMesh" folder to the final OF study. In the end, we had to play a bit with "boundary" files (but you will have to do it anyhow). If you have 100 regions, I recommend you to look for other method, but for up to 10 it works fine About the difference between fluent3DMesh… and fluentMesh…- I am not sure, but believe that the 3D one is just the first one with some pre-defined options. Just to shorten work |
|
May 15, 2010, 19:03 |
|
#52 |
Member
Michea Ferrari
Join Date: Mar 2010
Location: Switzerland
Posts: 30
Rep Power: 16 |
Hi all,
thank you Pawel for the advices, I have try but I have always some problem with boundary conditions... For the problem I had before: Code:
mapping field "S" In the 0 folder (or the one, which represent the start time in our case) one has only to create a folder for each region and put the file inherent the variable inside this folders. Another possibility is to create the region separately as proposed by Pawel. My actual problem is the generation of the interfaces "coordinates" inside the boundary conditions in 0.001/<region>/polyMesh folder. My case is a cell which represent a quarter (in order to reduce the computational time) of a bigger domain containing a cylinder in cross-flow with water. My cell is an half in length and an half in height, than i "compensate" with "symmetryPlane" boundary condition. I have only two regions: SOLID and FLUID. With the command Code:
splitMeshRegions -cellZones As example I put here the boundary from "heater" Code:
... heater_to_topAir { type directMappedWall; nFaces 40; startFace 172; sampleMode nearestPatchFace; sampleRegion region0; samplePatch none; offset (0 0 0); } ... Can someone please help me? How have you done (Pawel)? (I have to much nodes and faces to make it "by hand") Thank you Best Regards Michea |
|
May 15, 2010, 19:51 |
|
#53 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
The thing is actually quite simple
When you do create fields using split mesh, I am sure you get in the boundary files something like this: Code:
patchName { type <typeName>; nFaces <some_number>; startFace <some_number>; } Code:
sampleMode nearestPatchFace; sampleRegion <name_of_neighbour_region>; samplePatch <name_of_patch_to_be_coupled_with>; offset (0 0 0); sampleMode is the algorithm used to map one patch to another. In general, meshes do not have to mach 1:1, and probably there are some other algorithms of which I do not know. This boundary type is also used for parallel decomposition and was adopted for coupling. I am not sure what exactly "offset" does, but I believe it is not directly used and is there just to provide consistency with the earlier created general type. Leave it as it is The only thing you have to specify in the file is sampleRegion and samplePatch. Summing up, you take generated patches and modify them to get something like this: Code:
patchName { type directMappedWall; // !! here you have to change the type generated by splitMesh to the "directMappedWall" nFaces <some_number>; // do NOT change this number, it is fine startFace <some_number>; // same with this one, just leave it and do not worry // this is what you add: sampleMode nearestPatchFace; sampleRegion <name_of_neighbour_region>; samplePatch <name_of_patch_to_be_coupled_with>; offset (0 0 0); } Best, Pawel |
|
May 16, 2010, 08:35 |
|
#54 |
Member
Michea Ferrari
Join Date: Mar 2010
Location: Switzerland
Posts: 30
Rep Power: 16 |
Hi,
I tried to do what you said but there is still something, which doesn't work. First I have forgotten to ask you if you run Code:
changeDictionary -region <region> If I run "changeDictionary -region" in accord with the file changeDictionaryDict located in system/<region> adds at the end of the file boundary located in 0.001/<region</polyMesh the following code: Code:
... FLUID_to_SOLID { offset ( 0 0 0 ); sampleMode nearestPatchFace; sampleRegion SOLID; samplePatch SOLID_to_FLUID; } ... I need this or not? Because if one doesn't run "changeDictionary -region" one doesn't obtain this "additional" patch in the file boundary. First I tried to add the type as well as nFaces and startFace taking the data from the only common patch among the tworegions (FLUID and SOLID) and this is the "mantle" of the cylinder (named CYL_INTER in my case). So I become: Code:
FLUID_to_SOLID { type directMappedWall; nFaces 5733; startFace 828884; offset ( 0 0 0 ); sampleMode nearestPatchFace; sampleRegion SOLID; samplePatch SOLID_to_FLUID; } Typing directly "chtMultiRegionFoam" the error is: see attached file error 1 The second method I have try is to change all the type of patches in directMappedWall and add the simpleRegion and Patch: (see example) Code:
... CUBE_RIGHT { type directMappedWall; nFaces 2891; startFace 852306; sampleMode nearestPatchFace; sampleRegion SOLID; samplePatch SOLID_to_FLUID; offset ( 0 0 0 ); } ... See attached error2 file. If I don't run "changeDictionary -region <region>" I don't obtain SOLID_to_FLUID (as example) in the boundary file but if I change the other as specified sais always that in intial conditions are defined as symmetryPlane and one can not change their type in directMappedWall. So I hope is clear what I have explained, is not so easy be really clear! If one needs also the mesh can I provide it... Can you help me (again)? Thank you Best Regards Michea |
|
May 16, 2010, 09:50 |
|
#55 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
The truth is that I did not use "splitMesh" directly, just looked at it in the chtMult... example. I did the thing "by hand". "changeDictionary" is just a smart way of automaticaly altering data fields and all other "needed" stuff in newly obtained folder with new mesh. I did not like the way data and meshes were stored after the „splitMesh”. For me, mesh should be stored in „constant” folder, not in any time directory, especially if you do not alter the grid during computations. The thing is, that if you use "splitMesh" you obtain additional "polyMesh" folders in new initial directory 0.001. And those are the meshes used by solver, and which should be modified and prepared for work etc. It always confused me and gave a lot of trouble for debugging and post processing, so I always created "tmp" case for decomposition, and "runCase" for the simulation, which had the mesh in "const" folder (copied from 0.001 tmp folder), and no meshes in 0 starting folder.
Now regarding the error files. It seems to me, that in the first case the mesh is OK, and the error is not caused by the coupling thing. (please next time send logs with line numbers, will be easier to describe what is what ) Just after "Adding thermoFluid" line you have several "warnings". They do not cause solver to crash, but tell about some inconsistance. In your case, in the data files of the initial time folder, you should add the keyword "uniform" after "value" entry and before the value. You probably have: Code:
value <some_number>; Code:
value uniform <some_value>; But as I mentioned, this is just a cosmetic thing. The real problem is at the end of the log, in the section containing #1, #2... Look at the fist line of this section: incomputable dimensions for operation [U[0 1 -2 0 0 0 0 ] ]+ [U[1 -2 -2 0 0 0 0] ] (...) You specified wrong dimensions of your data. Look to the solver and check the velocity equation. The second term probably has some coefficient in it (viscosity?). And it seems that coefficient should be divided by density /OR/ its dimension in "const" folder should be divided by density dimension. You can also modify the solver And now regarding the second case. The procedure of adding some lines and modifying the type of a patch should be only used for the patches that are to be coupled. So if you have some simmetry planes, just leave then as they are after „splitMesh”. In the end, I believe that when you fix the problems with the first error file, things should go smooth. Best regards, Pawel |
|
May 16, 2010, 11:19 |
|
#56 |
Senior Member
Ben K
Join Date: Feb 2010
Location: Ottawa, Canada
Posts: 140
Rep Power: 19 |
Hi, I have a question about this solver.
Usually the coupling is done between different regions. For example, bottomAir_to_leftSolid couples between the fluidRegionNames and the solidRegionNames. This is only 2 regions. How can I use this solver to couple between 3 regions? I need to model a geometry that looks like a sandwich with heat flowing through 3 different regions (ie. the middle region is coupled to both the left and the right regions, but the left region is only coupled to the middle region and the right region is only coupled to the middle region). To do this, can I define a single region in the regionProperties file like: Code:
regionName ( left middle right ); left_middle middle_left and middle_right right_middle OR would I need to define three new regions in the regionProperties file like: Code:
leftRegionNames ( left ); middleRegionNames ( middle ); rightRegionNames ( right ); |
|
May 16, 2010, 12:50 |
|
#57 |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Hello Ben,
well, if you take a closer look at the regionProperties file in the exaple of chtMultiMultiRegionFoam, you will see that there are in fact only two dictionaries: Code:
fluid( fluidName1 fluidName2 ... ); solid( solidName1 solidName2 ... ); Now, when we say "couple regions" in fact we mean to couple the temperature fileds. Observe that we never make connections fluid-fluid. This is because ONLY temperature is coupled, no mixing is allowed. Now lets imagine 1D case, consisting of 3 solid regions: L, M and R. all of them are in general independent cases of temperature distribution with right and left boundaries. In this case lets say that the regions have the following boundaries: Code:
L: L_leftB, L_rightB; M: M_leftB, M_rightB; R: R_leftB, R_rightB; Code:
// pseudoCode// L_leftB = fixedValue/fixedGradient/any_other_standard_BC; L_rightB = solidWallTemperatureMixed connected to region M and M_leftB; M_leftB = solidWallTemperatureMixed connected to region L and L_rightB; M_rightB = solidWallTemperatureMixed connected to region R and R_leftB; R_leftB = solidWallTemperatureMixed connected to region M and M_rightB; R_rightB = fixedValue/fixedGradient/any_other_standard_BC; This way we have coupled M with both L and R. If you still have some doubts, feel free to write. Best, Pawel |
|
May 16, 2010, 13:25 |
|
#58 |
Member
Michea Ferrari
Join Date: Mar 2010
Location: Switzerland
Posts: 30
Rep Power: 16 |
Hi Pawel,
I don't understand some things... You don't typ "splitMeshRegion" (because you add the regions separately) and this is OK, yet I make like you and seems it work fine. Than you don't have the file "changeDictionaryDict" in the system folder because you don't run it. You said: you do it "by hand", so if I understand correctly one has to add in each variable file (U, T, rho, ...) the condition/s inherent the interface/s as example: Code:
... bottomAir_to_heater { type calculated; value uniform 0; } ... Is right make like the tutorial: "type calculated" ? Than as suggest by you I have put the meshes (SOLID and FLUID part) in constant folder and I have created a 0 folder, which contains a folder for each regions (one for SOLID and one for FLUID) and in this "regions-folders" there are the initial values for each variable (U, T, rho, ...). So the velocity dictionary U is located in 0/FLUID and not in 0/SOLID because SOLID doesn't need it (as well as p, k, epsilon). In the other hand also FLUID doesn't need (K, cp) and therefore this "variables-dictionary" doesn't exist in 0/FLUID. Correct? You add already there (0/<region>) the interfaces in the variable-file? (Like the code above as example: FLUID_to_SOLID ...) Than in "constant" folder I have the file "regionProperties" and always a folder for each region (so FLUID and SOLID), SOLID folder contains only polyMesh and the modified boundary conditions: (in the common face I have change the type in directMappedWall and add sample...: Code:
... CYL_INTER { type directMappedWall; nFaces 5733; startFace 739451; offset ( 0 0 0 ); sampleMode nearestPatchFace; sampleRegion FLUID; samplePatch FLUID_to_SOLID; } ... Do you think it is correct? in the same way in "system" folder I have files (controlDict, decomposeParDict, fvSchemes, fvSolution) and the two folders FLUID and SOLID, which contains the same files as the folder "system" (so: controlDict, decomposeParDict, fvSchemes, fvSolution ). So if I have understood correct I don't need to add the following code: Code:
FLUID_to_SOLID { offset ( 0 0 0 ); sampleMode nearestPatchFace; sampleRegion SOLID; samplePatch SOLID_to_FLUID; } Than under samplePatch is correct to insert SOLID_to_FLUID, which are two regions and not two patches... I have try to run the above explained case typing "chtMultiRegionFoam" (I will make the decomposition when the case works) and the output is attched as log file I have name the case "pawel" because is made as you have adviced (without mesh in the time folder) can you please help me again? Many thanks Best Regards Michea (Scusa se ti carico di domande ma devo riuscire a far funzionare questa simulazione il pirma possibile! GRAZIE) |
|
May 16, 2010, 15:02 |
|
#59 |
Senior Member
Ben K
Join Date: Feb 2010
Location: Ottawa, Canada
Posts: 140
Rep Power: 19 |
Hi Pawel, thanks for your reply. If I understand you correctly, this solver only allows you to couple fields between regions and not within regions therefore, my regionProperties file would need to look like:
Code:
leftRegionNames ( left ); middleRegionNames ( middle ); rightRegionNames ( right ); Are you using 3-regions in this solver? |
|
May 16, 2010, 19:04 |
|
#60 | |
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Hello you both
in the order of questions, regarding Michea's post: The questions- yes, you are correct. But I will try to write step-by-step tour to make everything clear.
Now, the error that you have comes from some wrong data assignment... It seems to me there is something wrong with the pressure or the density of the fluid. I think the program breaks on the line 133 of the createFluidFields.H file. At the same time, there can be something with creating solid fields. I suggest to add line Code:
Info << “fluid is done” << endl; Last remark, the procedure I described is indeed a bit tricky, and requires a bit work. Using splitMesh and changeDict can save you some time. Unfortunately I did not force myself to study it in a way so I could use it, and at present time I am not working with OF much (hope to get back to it soon). That is why I do not feel qualified to help you with splitMesh procedure. Wow, that will be a big post Now to your question Ben, I run a modified version of cthMultiRegionFoam for nine regions, 4 fluid and 5 solid I did not fully understand your statement: Quote:
I will try to clear the things out on an example. Suppose we want to simulate heat transfer in a computer. We will take a look at following components: air in the computer, metal radiator (fully covering the processor) and plastic motherboard. The processor is a ''viod'' space and is represented as a fixed temperature BC. In the regionProperties file for this case we will have something like that: Code:
fluidRegionNames ( AIR ); solidRegionNames ( MOTHERBOARD RADIATOR ); Code:
fluidRegionNames ( AIR_INSIDE AIR_OUTSIDE ); solidRegionNames ( HOUSING MOTHERBOARD RADIATOR ); Code:
RADIATOR: coupling_air_inside, coupling_motherboard, fixed_temp_processor; MOTHERBOARD: coupling_radiator, coupling_housing, coupling_air_inside; HOUSING: coupling_motherboard, coupling_air_inside, coupling_air_outside; AIR_INSIDE: coupling_radiator, coupling_motherboard, coupling_housing; AIR_OUTSIDE: coupling_housing, out_world_bc; If you still are not convinced, I can provide you with an example case which couples 3 solid regions. (tomorrow, I do not have it at home ). Woah, that was a bit writing... Hope that I helped a bit you both. 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 |