|
[Sponsors] |
December 15, 2010, 05:31 |
|
#161 | |||
Senior Member
Pawel Sosnowski
Join Date: Mar 2009
Location: Munich, Germany
Posts: 105
Rep Power: 18 |
Hello Sebastian,
I am happy that you found my prev post useful Now, about the thing: Quote:
This means that there is something not working in the solver and/or the case is not "set up" properly. Another possibility is that you do not provide enough corrections for solving the equations within single time step (but I am not sure about that, since I did not study deeply this algorithm). Quote:
Quote:
for this BC to work. Check them at least three times! Some explanation about the constant/.../boundary coupling is also to be found earlier in this thread. Hope you will also find this post useful Best, Pawel |
||||
December 20, 2010, 04:10 |
|
#162 |
Member
Sebastian Lang
Join Date: Aug 2009
Posts: 47
Rep Power: 16 |
Hi Pawel,
thanks again for your reply! I modified my boundary and initial conditions a bit and by now I got a converging calculation! Unfortunately the acquired solution does not seem to make much physical sense, as the velocity field does not look like the one I expected. So I think I have to return to setting better initial conditions than uniform (0 0 0) for the velocity field ;-) Pawel, I guess you were talking about the post where you describe to use a laminar solver for the fluid regions only and use this solution as an initial solution for the chtMultiRegionSimpleFoam solver. I also thought about this possibility, but I don't know an easy way to use a solver like icoFoam only for the fluid regions! How do you setup such a case? My mesh is pretty complex (I am calculating a whole pump!) and I don't think its a good way to crate a second mesh with only the fluid region and map this solution to my fluid region in the chtMRSimpleFoam case afterwards. Can you give some details about your procedure? Is it maybe possible do deactivate the calculation of the solids and the temperature without changing the solver-code? It would be ideal if I could start the simpler calculation with icoFoam from within my case folder and start the chtMRSimpleFoam-solver from within the same folder afterwards. Thanks in advance! Hope I can help other ones in the future, too! Greetings Sebastian |
|
January 7, 2011, 08:52 |
Setting initial solutions with custom function
|
#163 |
Member
Sebastian Lang
Join Date: Aug 2009
Posts: 47
Rep Power: 16 |
Hi Pawel,
Pretty much time passed since my last post and was able to make my calculations run well. My mistake was that I used the wedge boundary types for my axisymmetric simulation of the pump instead of the cyclic ones, so the momentum was not able to be transported from the impeller to the inner part of the fluid. Stupid mistake, I know, but I think thats the reason why students have to do internships ;-) Thanks you for your help! I am pretty sure I will return and post another question sometime ;-) Greetings Sebastian |
|
February 2, 2011, 10:18 |
Converging?
|
#164 | |||
Member
Join Date: Dec 2009
Posts: 39
Rep Power: 16 |
Hi there Sebastian!
I also have diverging temperatures and was always suspecting that it had something to do with the initail/booundary conditions. I see you managed to solve it: Quote:
Quote:
Quote:
Anyway, I hope you find the time to answer my qustions and thanks in advance! Best regards Marco |
||||
February 2, 2011, 16:40 |
|
#165 |
Member
Sebastian Lang
Join Date: Aug 2009
Posts: 47
Rep Power: 16 |
Hi marval!
First of all, at the moment I am at home, so I can't reach my data and therefore can't tell you what I exactly changed to make it converge. Hopefully I can find it out tomorrow when I am back at office. Unfortunately I can't post my cases in a complete way, as I signed a privacy policy. Maybe I am able to post some "abstract" things like my boundary files, I'll see what I can do for you tomorrow! But one thing I can tell from here is that the diverging temperature most likely is a result and not the cause of a diverging calculation. Be sure that you use fixedValue boundary conditions only at the fluid inlets and your conditions for temperature will exactly be as mine. For the turbulent variables it is the same: Inlets with a fixedValue and outlets with zeroGradient. at the walls I used the standard wall functions, of course. My advisor told me, that bad initial conditions for temperature are unlikely to be the cause for diverging calculations. As the energy equation is a linear equation, it's solution is relatively easy compared to Navier-Stokes and the pressure-equation, so I think you should look for your mistake in the velocity- and pressure-field. The initial solutions you should take care of are those for pressure and velocity, too. I realized a relative big sensitivity to the initial solutions of those "navier-stokes-fields" compared to those for temperature. That's what I can tell you by heart, as I said, I will look for the rest tomorrow. I don't know if I can tell you the exact changes I made in my boundary conditions, but at least I can tell you which boundary conditions I used in the final simulation. I'll post something for you tomorrow, Greetings Sebastian |
|
February 2, 2011, 23:06 |
|
#166 | |||
Member
Join Date: Dec 2009
Posts: 39
Rep Power: 16 |
Hi Sebonator!
Quote:
Quote:
Quote:
Regards Marco |
||||
February 3, 2011, 04:01 |
|
#167 |
Member
Sebastian Lang
Join Date: Aug 2009
Posts: 47
Rep Power: 16 |
Hi marval,
allright, I had a look at my case and will describe you, which boundary conditions I used. First of all, I am simulating an impeller side gap (is that the correct english word for the german 'Radseitenraum'???) where the one side is the rotating impeller and the other side is a fixed wall. There is a cold mass flow of water entering in axial direction from a gap between the fixed wall and the shaft. There is a hole in the impeller where the water can leave the impeller side gap and of course at the outer impeller diameter there is the gap to the main stream flowing through the pump. Hope this is enough for you to imagine it ;-) A general aspect is, as I stated in a former post, that a rotationally symmetric simulation of such a configuration, where a lot of fluid flows in circumferential direction, requires cyclic boundary conditions and not wedge boundary conditions!!!! But maybe you don't want to simulate it rotationally symmetric. My boundary and initial conditions:
Good luck, Greetings Sebastian |
|
February 17, 2011, 09:52 |
Coupling problem between solid and fluid (water).
|
#168 | |
Member
Join Date: Dec 2009
Posts: 39
Rep Power: 16 |
Greetings sebonator!
I am really thankful for your help in applying correct boundary conditions, I can now run my simulations without them blowing up. Quote:
However, my problem now is that the fluid and solid regions doesn't couple correctly. After 10 000 iterations the fluid temperature rises just slightly over 1 degree while the solid regions seem to rise as it should. Is there any explanation to the slow rise of the temperature? I apply a heat flux to the top of the solid with using solidWallHeatFluxTemperature Code:
cellWall { type solidWallHeatFluxTemperature; K K; // Name of K-field q uniform 19985.49; // Heat flux [W/m²] value uniform 300.15; // initial Temp [K] gradient uniform 0; // Initial gradient [K/m] } http://www.cfd-online.com/Forums/ope...implefoam.html and http://www.cfd-online.com/Forums/ope...n-problem.html. The coupling between the two solids is OK though, Code:
solid_to_channel { type solidWallMixedTemperatureCoupled; neighbourFieldName T; K K; value uniform 300.15; } One of the big difference from the tutorial is that I use a turbulence model instead of a laminar flow, could that be a reason for the coupling problem? Would be strange if that's the case. Regards Marco |
||
February 17, 2011, 15:16 |
|
#169 | ||
Member
Sebastian Lang
Join Date: Aug 2009
Posts: 47
Rep Power: 16 |
Hi marval,
cool that I was able to help you! Yes, I simulated the temperature distribution in a whole pump. The pump is heated up from the fluid that flows inside the impeller side gap and there are several solid regions through which the heat is transported by conduction. Mhm, I can only guess on the reason of your problem... But what I can tell is that there should not be a problem with turbulence, because I did a turbulent simulation with the SST-model, too. Check these things in your setup: -Is the code you posted the correct input to the solidWallMixedTemperatureCoupled? I think there is an extra entry like 'neighbourPatch' or something like that needed which tells the boundary condition, with which other patch it should exchange the temperatures! Unfortunately I am not at office, so I can't check that now... But have a look at that, I think this keyword is missing, at least in the code you posted! -Is the solidWallMixedTemeperatureCoupled applied for both the solid and the fluid region? Both regions need the definition of such a corresponding couple in order to work correctly! -Make sure you don't have something like fixedValue applied to the interface on the fluid-side! -Other possibility can be wrong material properties... for example a huge specific heat of the fluid could be a problem. But as you said Quote:
-What might play a role is: Is it possible, that you did not scale your mesh correctly? If you built up your mesh in mm in your mesh generator (blockMEsh or gambit or whatever) and you don't scale it with 0.001 during import, openfoam will think that the mesh is generated in m! My guess is: a solid area in dimensions of 100m or so might warm up by conduction in a steady-state simulation, especially if you impose a heat flux, but maybe a 100m huge reservoir of fluid does not heat up, because its thermal conductivity might be much smaller! A general word in the end: If you really do a steady-state simulation, you can not talk about Quote:
In a case of a steady-state simulation you can only seperate between converged and not converged. Did your simulations converge? It is important to monitor the residuals of a steady-state simulation. Have a look through the forum, I found a nice script for gnuplot that reads the residuals of the fluid-region from a logfile and plots them. In this way you can easily monitor the convergence and for example stop your simulation when the residuals don't change anymore. As I said in a former post, the energy equation is a linear equation and almost always converges therefore. Because of that, you only have to care about the fluid field, because you can say that the solid regions converge before the fluid regions. If a steady-state simulation converges and does not give the expected result, then -your initial conditions are wrong (velocity often is critical) or -your boundary conditions are wrong (simulation converged to a correct result, but this result belongs to incorrect boundary conditions => the computer is stupid, he can only solve what you told him!) or -your material properties are wrong or -your mesh is wrong You see,all I can do is guess. If it doesn't help you, maybe you can post a list with all your boundary conditions for all regions like I did in my former post? Hope that helps! Greetings Sebastian |
|||
February 18, 2011, 04:49 |
|
#170 |
Member
Sebastian Lang
Join Date: Aug 2009
Posts: 47
Rep Power: 16 |
Hi marval,
it's me again ;-) I just had a look at my cases and realized that I told you something wrong again: You don't have to indicate something like a "neighbourPatch" in your time directories. What I meant are the keywords "samplePatch" and "sampleRegion" which have to be set inside the constant/Region/polyMesh/boundary-files. Make sure these entries are correct to ensure that your fluid patches sample with the correct solid patches! Goog luck! Greetings Sebastian |
|
February 20, 2011, 17:19 |
Boundary conditions
|
#171 | ||||||||
Member
Join Date: Dec 2009
Posts: 39
Rep Power: 16 |
Hi sebonator!
Brief description of my case: a steel-channel with water flow contained in a steel box that is heated up by concentrated sunlight (thus I know the heat flux, need a temperature distribution of the steel-surface, or at least very close to it). The inlet and outlet are very close to each other, this means that the fluid flows in many U-turns as it heats up along the way inside the box. This makes for a quite complicated heat transfer inside since it will be by convection and conduction in all directions. The three parts consists of:
I have two solid parts for visualization purpose only. Quote:
I tried to use laminar flow just to see if something happens and the temperature of the fluid rose to around 700K which of course is not possible. That tells me at least that the fluid and solid regions are coupled and the problem is somewhere else. Quote:
Quote:
Code:
... fluid_to_solid { type directMappedWall; nFaces 37021; startFace 3025435; sampleMode nearestPatchFace; sampleRegion solid; samplePatch solid_to_fluid; offset ( 0 0 0 ); } ... Quote:
Quote:
Quote:
Quote:
Quote:
http://www.cfd-online.com/Forums/ope...residuals.html I can upload my boundary conditions so you can see if there are some errors in them. Please note that I did not use the "changeDictionary-approach" instead I used the approach which I mentioned in a former post. Best regards Marco |
|||||||||
February 21, 2011, 04:34 |
|
#172 |
Member
Sebastian Lang
Join Date: Aug 2009
Posts: 47
Rep Power: 16 |
Hi marco,
thanks for the uploaded files. The values you posted (0.6 W/mK for fluid and 16 W/mK for solid) are not the specific heat of the materials! Those are the thermal conductivities K! The specific heat usually has the symbol cp and is expressed in the unit J/(kg K). But this value is OK in your files. In contrast to that, the thermal conductivity of your water is not 0.6 W/mK as you said in your former post, in your files it is 6.62 W/mK! Maybe the problem is located in your turbulence-modelling! I have no experience with low-Re models, so you have to get informations to them from someone else. But I saw that you did not set any wall-functions in your k- and epsilon-field! As far as I know, low-Re models need wall functions, too! You use zeroGradient at the wall for those fields, but this surely isn't correct, because turbulence usually happens at the wall, so the values of k and epsilon should change dramatically in the near wall region! In general, the presence of turbulence influences the heat transfer coefficient between the wall and the fluid dramatically. Maybe you remember the calculation of heat transfer coefficients via Nusselt-relations from the lectures? One of the first steps in those calculations always is to decide if turbulence is present or not. This affect of turbulence can be found in the calculated value alphat in OpenFOAM, too: I think alpha represents the heat transfer coefficient and alphat is something like a an heat transfer coefficient, which is corrected to the extend of the additional convection caused by turbulence. My guess is: if you don't model turbulence correctly at the wall, then the heat transfer coefficients will be much too low and therefore your fluid doesn't heat up as you expect! Check carefully how the boundary conditions for your turbulence model have to be set. I can't imagine that zeroGradient is the correct wall-treatment for a low-Re model! Could you please make your question about time steps a bit more specific? Good luck! Greetings Sebastian |
|
March 4, 2011, 04:31 |
|
#173 |
Member
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 16 |
Hi all!
After a long time of absence, I'm again trying to use OpenFOAM. I'm using CAELinux which comes with OpenFOAM 1.7. For a start, I adapted some parts of the chtMultiRegionHeater tutorial case. I've managed to set up my chtMultiRegionFoam case by hand, according to the rules that Pawel suggested in this thread. Temperature coupling works very well. In my case, I've got a solid heater (region named "GAL") completely surrounded by a fluid mesh (region named "FLUID_AMB"). The case is 2D. See also the attached picture, especially for coordinates... As a first attempt, I adapted the tutorial case and therefore specified a velocity inlet and an outlet (left resp. right), while top and bottom were set up as walls, same as in the tutorial case. That seemed to work fine. What I would like to set up (for now) is: The bottom of the fluid mesh is considered to be a wall, while the left, right and top boundaries should be "open atmosphere". The starting velocity should be zero on all boundaries, while all open boundaries shall work as inlet or outlet, depending on pressure and velocity. For fluid T field, I set: Code:
dimensions [0 0 0 1 0 0 0]; internalField uniform 300; boundaryField { FLUID_AMB_to_GAL { type solidWallMixedTemperatureCoupled; neighbourFieldName T; K K; value uniform 300; } FLUID_AMB_down { type zeroGradient; } FLUID_AMB_up { type inletOutlet; inletValue uniform 300; value uniform 300; } FLUID_AMB_left { type inletOutlet; inletValue uniform 300; value uniform 300; } FLUID_AMB_right { type inletOutlet; inletValue uniform 300; value uniform 300; } } The fluid p field is all set to "type calculated" and "value uniform 1e5", same as in the tutorial case. Can this p field in this context be described as something like "ambient pressure without buoyancy effects"? The total pressure would then be p+p_rgh, is that right? For the fluid p_rgh field, I set the following: Code:
dimensions [1 -1 -2 0 0 0 0]; internalField uniform 100000; boundaryField { FLUID_AMB_to_GAL { type buoyantPressure; value uniform 100000; } FLUID_AMB_down { type buoyantPressure; value uniform 100000; } FLUID_AMB_up { type fixedValue; value uniform 100000-34.1388; // rho*g*h with h=3 } FLUID_AMB_left { type uniformDensityHydrostaticPressure; rho 1.16; pRefValue 100000; pRefPoint (-1.49 -1.49 0); //lower left corner location value uniform 100000; } FLUID_AMB_right { type uniformDensityHydrostaticPressure; rho 1.16; pRefValue 100000; pRefPoint ( 1.49 -1.49 0); //lower right corner location value uniform 100000; } } Next comes fluid U field: Code:
dimensions [0 1 -1 0 0 0 0]; internalField uniform (0.01 0 0); boundaryField { FLUID_AMB_to_GAL { type fixedValue; value uniform ( 0 0 0 ); } FLUID_AMB_down { type fixedValue; value uniform ( 0 0 0 ); } FLUID_AMB_up { type pressureInletOutletVelocity; value uniform (0 0 0); } FLUID_AMB_left { type pressureInletOutletVelocity; value uniform (0 0 0); } FLUID_AMB_right { type pressureInletOutletVelocity; value uniform (0 0 0); } } Currently, the simulation is running, gives small residuals and the numbers of iterations is between 0 and 2 for all calculated stuff. What I'm worried about, is that automatic time step adjustment produced very small time steps... therefore the simulation takes a lot of time and I don't know, whether it's a good signal or not... In former attempts, I tried inletOutlet for velocity at the open boundaries, but this is obviously not a good choice. zeroGradient in case of outflow is nice, but what to specify for possible inflow? fixedValue uniform (0 0 0) would cause the case not to suck any fluid into the domain, while just outflow is permitted. Did I get that right? So, I switched to zeroGradient... which did the same. Other possible choices maybe might be "directMappedFixedValue" and "fixedInternalValue", e.g. for mapping the velocity field for the cells next to the boundary to the boundary itself? Could this work or would it be likely to force instability? Cheers Wolle P.S.: In the fluids mesh boundary file, I set FLUID_AMB_to_GAL to directMappedWall according to the suggestions in this thread. FLUID_AMB_down is wall, all others are simply patch type.
__________________
CAELinux 2010 -- OpenFOAM 1.7 Last edited by Wolle; March 4, 2011 at 04:47. |
|
March 4, 2011, 04:45 |
|
#174 |
Member
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 16 |
After reviewing my post and having another look on the solver output, I noticed that temperature falls below ambient level.
I'm going to let it run though, I'm just curious, what the results will look like...
__________________
CAELinux 2010 -- OpenFOAM 1.7 |
|
March 8, 2011, 05:27 |
|
#175 |
Member
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 16 |
Hi all!
Seems like I can't make it from the tutorials boundary conditons to some "open to atmosphere" boundary conditions... First of all... is this boundary condition for fluid U fields on "open to atmosphere" patches right, if I don't have any ventilaton but velocity driven only by heating up some air inside the domain? Code:
SOMEPATCH { type pressureInletOutletVelocity; value uniform (0 0 0); } Code:
SOMEPATCH { type inletOutlet; inletValue uniform 300; value uniform 300; } Finally, we have pressure... Code:
SOMEPATCH { type uniformDensityHydrostaticPressure; rho 1.16; pRefValue 100000; pRefPoint (0 -1.5 0); //lower middle value uniform 100000; } Regarding this... would a fixedValue 99965,8612 at the top of the domain be appropriate or would buoyantPressure be better? Ciao Wolle
__________________
CAELinux 2010 -- OpenFOAM 1.7 |
|
March 8, 2011, 12:48 |
|
#176 |
Senior Member
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 190
Rep Power: 17 |
hey wolle,
i ve been working with open boundaries since a while and its not that easy (at least for me) to obtain a satisfiable solution with the first set of bcs, but its most of the time the bcs causing the problems. at the first look your bc seem to be ok, inletOutlet for T at the open boundaries is also ok. i experienced that the most crucial bcs for this type of set-up are those for p and U; its very important to apply bouyantPressure for p at all walls and inlets(!). for the open bcs i sometimes play with zeroGradient for p/U as uniformDensityHhydrostaticPressure/pressureInletOutletVelocity not always produced good results for me. I d try to apply fixedValue 99965,8612 for p and zeroGradient or inletOutlet for U at the top of the domain. in my case of a simple heated plate it helped to use a small value of U as initial conditions in the direction you expect the flow to move. What about turbulence? Do you apply a turbulence model? In case of standard k-eps i made the experience that its sometimes helpful to set the initial value for epsilon 2 to 3 magnitudes higher than the standard value. i use k = 1e-6 m2/s2 and epsilon = 1e-9 m2/s3 for the inletValue at the open boundary (atmosphere). It can also help to play a bit with the domain size. Furthermore, i always check the mass balance! as well as continuity errors. Search the wiki page for a description how to add calculation of mass flux to your code ( http://openfoamwiki.net/index.php/Sn...ting_mass_flow). Thats what came to my mind so far. hope that helps and looking forward to your results! cheers, aram |
|
March 9, 2011, 07:36 |
|
#177 | |
Member
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 16 |
Hi Aram,
I totally agree with you, that p and U bcs seem to be most essential. At the moment I tried to adapt the damBreak tutorial (multiphase/interfoam/laminar), which would mean: only walls, except the top boundary. In the damBreak tutorial, they use pressureInletOutletVelocity (uniform 000) for U and totalPressure for p: Code:
atmosphere { type totalPressure; p0 uniform 0; U U; phi phi; rho rho; psi none; gamma 1; value uniform 0; } Having a look at the mass flow is a very good idea indeed! Quote:
Thanks for your hints! As my case is rather abstract (although indeed with a practical background), I think I can post it, when it's nice and clean... Ciao Wolle
__________________
CAELinux 2010 -- OpenFOAM 1.7 |
||
March 10, 2011, 03:36 |
|
#178 |
Member
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 16 |
Hi Aram!
Meanwhile I tried the waveTransmissive bc and it looks good as far as the fluid now leaves the domain as expected. Temperature and velocity seem to be good although pressure raises... Therefore I tried to add mass flux calculation according to the hint you gave me. I first copied/renamed the solver, recompiled an tested: worked like the original. Then I took the files from the wiki and did, what it says there. (BTW: There's an error in the wiki. It says ' #include "computeMassFlux.H" ' but later on, the file is called calculateMassFlux.H). Sadly, I can't compile the modified solver. I tried to add the #include "buildGlobalBoundaryList.H" in various places... no luck. Here's the error message: Code:
In file included from my_chtMultiRegionFoam.C:55: buildGlobalBoundaryList.H: In function 'int main(int, char**)': buildGlobalBoundaryList.H:4: error: a function-definition is not allowed here before '{' token my_chtMultiRegionFoam.C:130: error: expected '}' at end of input make: *** [Make/linux64GccDPOpt/my_chtMultiRegionFoam.o] Error 1 Code:
\*---------------------------------------------------------------------------*/ #include "fvCFD.H" #include "basicPsiThermo.H" #include "turbulenceModel.H" #include "fixedGradientFvPatchFields.H" #include "regionProperties.H" #include "compressibleCourantNo.H" #include "solidRegionDiffNo.H" #include "SortableList.H" // added for flux calculation // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // int main(int argc, char *argv[]) { #include "setRootCase.H" #include "createTime.H" regionProperties rp(runTime); #include "createFluidMeshes.H" #include "createSolidMeshes.H" #include "buildGlobalBoundaryList.H" // added for flux calculation #include "createFluidFields.H" #include "createSolidFields.H" #include "initContinuityErrs.H" #include "readTimeControls.H" #include "readSolidTimeControls.H" #include "compressibleMultiRegionCourantNo.H" #include "solidRegionDiffusionNo.H" #include "setInitialMultiRegionDeltaT.H" Ciao Wolle EDIT: Looks like I can't put the variable/function definition in main()? Well, here they call the function seperately in the code (but where exactly?): http://www.cfd-online.com/Forums/ope...ry-values.html
__________________
CAELinux 2010 -- OpenFOAM 1.7 |
|
March 10, 2011, 03:54 |
|
#179 |
Senior Member
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 190
Rep Power: 17 |
hey wolle!
i m using OF-1.6.x, but that shouldn t matter here. for me it works like this: buildGlobalBoundaryList.H and SortableList.H have to be include before the main in applications/chtMultiRegionFoamMF/chtMultiRegionFoamMF.C. buildGlobalBoundaryList.H is stored in applications/chtMultiRegionFoamMF. wordList globalBoundaryList and calculateMassFlux.H are then added in the fluidRegions loop. calculateMassFlux.H is stored in applications/chtMultiRegionFoamMF/fluid. I attached you the main code chtMultiRegionFoamMF.C. cheers, aram |
|
March 10, 2011, 04:09 |
|
#180 | |
Member
Wolfram Kretzschmar
Join Date: Dec 2009
Posts: 71
Rep Power: 16 |
Ah, there it is...
http://www.cfd-online.com/Forums/ope...tml#post202067 Here it says: Quote:
Code:
my_chtMultiRegionFoam.C: In function 'int main(int, char**)': my_chtMultiRegionFoam.C:71: error: 'mesh' was not declared in this scope Ciao Wolle EDIT: Maybe one has to refer to the respective meshes of the several regions? Calculation (using the provided code) would then only be possible for the regions seperately, wouldn't it? In chtMultiRegionFoam... is there something like an "overall mesh"?
__________________
CAELinux 2010 -- OpenFOAM 1.7 Last edited by Wolle; March 10, 2011 at 04:49. |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
---------Tutorial help | mech | FLUENT | 4 | May 16, 2007 02:43 |
tutorial 6 in Fluent 6.2 tutorial and Mesh | pilli4u | FLUENT | 2 | April 2, 2007 05:09 |
3D Tutorial | MJ | FLUENT | 0 | January 16, 2007 08:45 |
tutorial | masood yooceframandi | FLUENT | 1 | January 25, 2005 12:28 |
tutorial | adil | FLUENT | 0 | March 8, 2004 03:48 |