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

strange behaviour in the "interface" between two reference frames (simpleFoam MRF)

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

Reply
 
LinkBack Thread Tools Display Modes
Old   December 3, 2015, 11:59
Default strange behaviour in the "interface" between two reference frames (simpleFoam MRF)
  #1
New Member
 
Carla
Join Date: Jun 2015
Posts: 16
Rep Power: 3
cvillescas is on a distinguished road
Hi Foamers!

I have been exploring the use of the Multiple Reference Frame in OpenFoam but there's something I am doing wrong and I couldn't find what it is. I was hoping you could help.

I did the mixerVessel2D tutorial and I wanted to try a simple 3D example. I am simulating a propeller in a circular domain (I know I could simulate this in a single reference frame but I want to learn about MRF).

My problem is I get a strange velocity field close to the "interface" between the rotating and stationary part. I have attached an image for the mesh and vertical velocity. The rotating part of the mesh is the shaded area.

By the way, I am using OpenFoam-3.0.

Anyone can tell me what is wrong with the simulation? Thank you.

Carla

0/U file:
Code:
#include "../system/runConditions"

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform $flowVelocity;

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform $flowVelocity;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform (0 0 0);
        value           uniform (0 0 0);
    }
    propeller
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    outerCylinder
    {
        type            symmetry;
        // value           uniform $flowVelocity;
    }
}
0/p file:
Code:
#include "../system/runConditions"

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform $pressure;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }
    outlet
    {
        type            fixedValue;
        value           uniform $pressure;
    }
    propeller
    {
        type            zeroGradient;
    }
    outerCylinder
    {
        type            symmetry;
    }
}
Boundary file:
Code:
4
(
    inlet
    {
        type            patch;
        nFaces          448;
        startFace       1688089;
    }
    outlet
    {
        type            patch;
        nFaces          448;
        startFace       1688537;
    }
    propeller
    {
        type            wall;
        inGroups        1(wall);
        nFaces          16167;
        startFace       1688985;
    }
    outerCylinder
    {
        type            symmetry;
        inGroups        1(symmetry);
        nFaces          2304;
        startFace       1705152;
    }
And MRFproperties file:
Code:
MRF1
{
    cellZone    cellZoneCyl;
    active      yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches (inlet outlet outerCylinder);

    origin    (0 0 0);
    axis      (1 0 0);
    omega     627.1247;
}
Attached Images
File Type: png Uy.png (108.0 KB, 38 views)
cvillescas is offline   Reply With Quote

Old   August 17, 2016, 02:42
Default
  #2
New Member
 
DavidTran
Join Date: Aug 2016
Posts: 10
Rep Power: 2
davidtran is on a distinguished road
Hi,

I am testing simple geometry using MRFSimpeFoam and AMI interface. However, my solution was diverged due to a large value of "time step continuity errors". I wonder if you can share your experience to solve this issue.

I looking forward to hearing from you soon.

Quote:
Originally Posted by cvillescas View Post
Hi Foamers!

I have been exploring the use of the Multiple Reference Frame in OpenFoam but there's something I am doing wrong and I couldn't find what it is. I was hoping you could help.

I did the mixerVessel2D tutorial and I wanted to try a simple 3D example. I am simulating a propeller in a circular domain (I know I could simulate this in a single reference frame but I want to learn about MRF).

My problem is I get a strange velocity field close to the "interface" between the rotating and stationary part. I have attached an image for the mesh and vertical velocity. The rotating part of the mesh is the shaded area.

By the way, I am using OpenFoam-3.0.

Anyone can tell me what is wrong with the simulation? Thank you.

Carla

0/U file:
Code:
#include "../system/runConditions"

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform $flowVelocity;

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform $flowVelocity;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform (0 0 0);
        value           uniform (0 0 0);
    }
    propeller
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    outerCylinder
    {
        type            symmetry;
        // value           uniform $flowVelocity;
    }
}
0/p file:
Code:
#include "../system/runConditions"

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform $pressure;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }
    outlet
    {
        type            fixedValue;
        value           uniform $pressure;
    }
    propeller
    {
        type            zeroGradient;
    }
    outerCylinder
    {
        type            symmetry;
    }
}
Boundary file:
Code:
4
(
    inlet
    {
        type            patch;
        nFaces          448;
        startFace       1688089;
    }
    outlet
    {
        type            patch;
        nFaces          448;
        startFace       1688537;
    }
    propeller
    {
        type            wall;
        inGroups        1(wall);
        nFaces          16167;
        startFace       1688985;
    }
    outerCylinder
    {
        type            symmetry;
        inGroups        1(symmetry);
        nFaces          2304;
        startFace       1705152;
    }
And MRFproperties file:
Code:
MRF1
{
    cellZone    cellZoneCyl;
    active      yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches (inlet outlet outerCylinder);

    origin    (0 0 0);
    axis      (1 0 0);
    omega     627.1247;
}
davidtran is offline   Reply With Quote

Old   August 17, 2016, 03:57
Default
  #3
New Member
 
Carla
Join Date: Jun 2015
Posts: 16
Rep Power: 3
cvillescas is on a distinguished road
Hi davidtran,

I am not sure I understand what you are trying to achieve. As fas as I am aware, you don't need to use AMI with MRFsimpleFoam (what OF version are you using?). AMI is used when you've got a part of the mesh moving and a stationary one. In MRFsimpleFoam nothing is moving, simply Navier Stokes equations are solved in two different reference frames: for the cells in the rotating region (which are defined by a cellZone in OF) NS equations are solved in a rotating reference frame, and for the cells outside the rotating region, stationary (same as ever) NS equations are solved.

Regarding my issue I had to refine more the rotating region and the region around the rotating region. But I am not sure you've got the same issue. If you could post your case I might be able to tell if it's the set up, mesh, boundary conditions or numerics what is causing your divergence.
cvillescas is offline   Reply With Quote

Old   August 17, 2016, 08:43
Default
  #4
New Member
 
DavidTran
Join Date: Aug 2016
Posts: 10
Rep Power: 2
davidtran is on a distinguished road
Hi cvillescas,

Thank you for your response.
I want to perform MRFSimpleFOAM with AMI because the convergence result of MRF simluation will be used for unsteady simulation later (pimpleDyMFoam solver). I think that AMI technique is to interpolate flux between two interfaces of different fluid region. So it does not matter as a fluid domain is modeled as rotationary or stationary. Am I right?
I uploaded both cases including MRFSimpleFoam only and MRFSimpleFoam with AMI interface. Both of them was not converged. Please help me figure out the problem.

1. MRFSimpleFoam only
https://www.dropbox.com/s/xs3ooxsjdw...ly.tar.gz?dl=0
2. MRFSimpleFoam with AMI interface
https://www.dropbox.com/s/r8jcnssyw4...am.tar.gz?dl=0

I looking forward to hearing from you.


Quote:
Originally Posted by cvillescas View Post
Hi davidtran,

I am not sure I understand what you are trying to achieve. As fas as I am aware, you don't need to use AMI with MRFsimpleFoam (what OF version are you using?). AMI is used when you've got a part of the mesh moving and a stationary one. In MRFsimpleFoam nothing is moving, simply Navier Stokes equations are solved in two different reference frames: for the cells in the rotating region (which are defined by a cellZone in OF) NS equations are solved in a rotating reference frame, and for the cells outside the rotating region, stationary (same as ever) NS equations are solved.

Regarding my issue I had to refine more the rotating region and the region around the rotating region. But I am not sure you've got the same issue. If you could post your case I might be able to tell if it's the set up, mesh, boundary conditions or numerics what is causing your divergence.
davidtran is offline   Reply With Quote

Old   August 17, 2016, 09:26
Default
  #5
Member
 
Bruno Blais
Join Date: Sep 2013
Location: Canada
Posts: 62
Rep Power: 5
blais.bruno is on a distinguished road
Do you still have this problem?

If so,
Can I ask you how do you create your mesh?
I feel like it seems the mesh interface is ill-defined and this is why you get spurious velocities at the interface.
Have you tried using the same mesh for AMI? AMI usually gives you a better idea if somehting is going wrong because you can do a transient analysis and you can also see the mesh motion (which makes everything much more clear).

I suggest you try and design your own 2D test case first before moving to 3D. The tutorials for AMI and MRF are quite poor I find.
I have one lying around for a Taylor-Couette flow, I could try to find it!

Cheers
BB


Quote:
Originally Posted by cvillescas View Post
Hi Foamers!

I have been exploring the use of the Multiple Reference Frame in OpenFoam but there's something I am doing wrong and I couldn't find what it is. I was hoping you could help.

I did the mixerVessel2D tutorial and I wanted to try a simple 3D example. I am simulating a propeller in a circular domain (I know I could simulate this in a single reference frame but I want to learn about MRF).

My problem is I get a strange velocity field close to the "interface" between the rotating and stationary part. I have attached an image for the mesh and vertical velocity. The rotating part of the mesh is the shaded area.

By the way, I am using OpenFoam-3.0.

Anyone can tell me what is wrong with the simulation? Thank you.

Carla

0/U file:
Code:
#include "../system/runConditions"

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform $flowVelocity;

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform $flowVelocity;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform (0 0 0);
        value           uniform (0 0 0);
    }
    propeller
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    outerCylinder
    {
        type            symmetry;
        // value           uniform $flowVelocity;
    }
}
0/p file:
Code:
#include "../system/runConditions"

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform $pressure;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }
    outlet
    {
        type            fixedValue;
        value           uniform $pressure;
    }
    propeller
    {
        type            zeroGradient;
    }
    outerCylinder
    {
        type            symmetry;
    }
}
Boundary file:
Code:
4
(
    inlet
    {
        type            patch;
        nFaces          448;
        startFace       1688089;
    }
    outlet
    {
        type            patch;
        nFaces          448;
        startFace       1688537;
    }
    propeller
    {
        type            wall;
        inGroups        1(wall);
        nFaces          16167;
        startFace       1688985;
    }
    outerCylinder
    {
        type            symmetry;
        inGroups        1(symmetry);
        nFaces          2304;
        startFace       1705152;
    }
And MRFproperties file:
Code:
MRF1
{
    cellZone    cellZoneCyl;
    active      yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches (inlet outlet outerCylinder);

    origin    (0 0 0);
    axis      (1 0 0);
    omega     627.1247;
}
blais.bruno is offline   Reply With Quote

Old   August 17, 2016, 09:32
Default
  #6
New Member
 
Carla
Join Date: Jun 2015
Posts: 16
Rep Power: 3
cvillescas is on a distinguished road
That makes sense Let's focus on converging the case without AMI and we can move on from there then.

I had a quick look at your case and I reckon your boundary conditions at the inlet are not quite right. If you fix pressure and velocity at the same time the solver might not be able to find a solution that complies with all the restrictions (that would explain the continuity errors). Try zeroGradient for pressure at the inlet.

If you still have problems after this we can have a look at the numerics.
cvillescas is offline   Reply With Quote

Old   August 17, 2016, 09:44
Default
  #7
New Member
 
Carla
Join Date: Jun 2015
Posts: 16
Rep Power: 3
cvillescas is on a distinguished road
Hi Bruno,

I created the mesh with snappyHexMesh and I overcame the problem refining. Also, I later found out that my omega velocity was an order of magnitude greater of what it was meant to be. I reckon decreasing the omega also helped.

Later on, I started using AMI and I started seeing again some spurious velocities, but not as high as the ones I showed here. I've been told GGI in foam-extend is much better than AMI but haven't tried yet. And yes, it would probably be better to study a 2D case first Thanks for your answer!

CV
cvillescas is offline   Reply With Quote

Old   August 17, 2016, 09:49
Default
  #8
New Member
 
DavidTran
Join Date: Aug 2016
Posts: 10
Rep Power: 2
davidtran is on a distinguished road
Hi cvillescas,

I have followed your guide by changing zeroGradient BC for pressure at the inlet. In addition, I also reduced "relTol" in fvSolution to 1e-5. However, the solution was blow-up at Time = 22. You can see from the attached file.
I looking forward to hearing from you.



Quote:
Originally Posted by cvillescas View Post
That makes sense Let's focus on converging the case without AMI and we can move on from there then.

I had a quick look at your case and I reckon your boundary conditions at the inlet are not quite right. If you fix pressure and velocity at the same time the solver might not be able to find a solution that complies with all the restrictions (that would explain the continuity errors). Try zeroGradient for pressure at the inlet.

If you still have problems after this we can have a look at the numerics.
Attached Files
File Type: txt log.simpleFoam.txt (22.9 KB, 1 views)
davidtran is offline   Reply With Quote

Old   August 17, 2016, 10:50
Default
  #9
New Member
 
Carla
Join Date: Jun 2015
Posts: 16
Rep Power: 3
cvillescas is on a distinguished road
Hi davidtran,

Can you try with this fvSchemes?
Code:
ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         cellLimited leastSquares 1;
}

divSchemes
{
    default         none;
    div(phi,U)                   bounded Gauss linearUpwind grad(U);
    div(phi,k)                   bounded Gauss linearUpwind grad(k);
    div(phi,epsilon)             bounded Gauss linearUpwind grad(epsilon);
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default             no;
    p            ;
}


// ************************************************************************* //
I've changed gradSchemes to leastSuqares because it's more accurate, particularly for tetrahedral meshes, and it doesn't add much computation time. I add the limiter because I've never managed to converge a simulation without the limiter.
I am not 100% sure of this but I think linear scheme is a central differencing scheme, which wouldn't be suitable for velocity. You need and upwind-biased scheme. linearUpwind is as accurate as limitedLinear and is upwind-biased. If this doesn't work, upwind is only first order accurate but will most certainly work. You could run upwind for the first iterations and then switch to linearUpwind.

I hope that helps!!
cvillescas is offline   Reply With Quote

Old   August 18, 2016, 01:57
Default
  #10
New Member
 
DavidTran
Join Date: Aug 2016
Posts: 10
Rep Power: 2
davidtran is on a distinguished road
Hi cvillescas,

I am sorry for my late response.
Firstly, there is a good new. I got a good convergence as the leastSquares of gradScheme was used only. Now I am trying to test the second case which involves the use of MRFsimpleFoam and AMI interface. In this case, the solution was converged up to roughly 500 time step. After that, it was gradually diverged due to time step continuity error. Any idea?

I looking forward to hearing from you.


Quote:
Originally Posted by cvillescas View Post
Hi davidtran,

Can you try with this fvSchemes?
Code:
ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         cellLimited leastSquares 1;
}

divSchemes
{
    default         none;
    div(phi,U)                   bounded Gauss linearUpwind grad(U);
    div(phi,k)                   bounded Gauss linearUpwind grad(k);
    div(phi,epsilon)             bounded Gauss linearUpwind grad(epsilon);
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default             no;
    p            ;
}


// ************************************************************************* //
I've changed gradSchemes to leastSuqares because it's more accurate, particularly for tetrahedral meshes, and it doesn't add much computation time. I add the limiter because I've never managed to converge a simulation without the limiter.
I am not 100% sure of this but I think linear scheme is a central differencing scheme, which wouldn't be suitable for velocity. You need and upwind-biased scheme. linearUpwind is as accurate as limitedLinear and is upwind-biased. If this doesn't work, upwind is only first order accurate but will most certainly work. You could run upwind for the first iterations and then switch to linearUpwind.

I hope that helps!!
davidtran is offline   Reply With Quote

Old   August 18, 2016, 02:53
Default
  #11
Member
 
Bruno
Join Date: Jun 2016
Location: Siegen, Germany
Posts: 59
Rep Power: 2
MBttR is on a distinguished road
Hi Carla,

Do you have experience in varying the domain around the propeller to see how that changes results? I get very different results depending on how far I extend it up- and downstream. Would you mind sharing your case? I also still have some issues with my snappyHexMesh, which I think are memory related. Do you use a .stl cylinder to define the rotating zone? Do you add layers to that or only to the propeller?

Many thanks,
Greetings,

Bruno
MBttR is offline   Reply With Quote

Old   August 18, 2016, 07:24
Default
  #12
New Member
 
Carla
Join Date: Jun 2015
Posts: 16
Rep Power: 3
cvillescas is on a distinguished road
Hi Bruno,

I saw your question and I think it's a very interesting exercise but I've never studied how the size of the rotating region affects results.

I didn't answer your question because I don't know how to properly explain this, I was hoping some else would. The thing is I went to the last OF workshop and one of the founders and developers of foam-extend said there's a term in the equations (I think is the time derivative of phiCorrect) that is added at a given time step and substracted at the next time step. He said that when you have a rotating mesh, you are adding and substracting different things and you shouldn't be. He said that's the reason why you get different results when you run at different Courant numbers and I think that could be the reason why you are getting different results. Following this reasoning, I would say the smaller the rotating region the better, I don't know if that matches your experience. Do you have experimental data? Are you also simulating a propeller?

I've been trying to find the slides he was putting when he presented this but I haven't, sorry. He also said this would be solved with the next foam-extend release, foam-extend 4.0. It should be released shortly.

Myself I've been focusing on how the numerics affect the results, and at the moment my simulation highly depends on the gradient scheme and limiter that I choose, which is not acceptable. I've tried both rotating mesh and rotating reference frame and I get similar variations in propeller forces depending on the grad scheme and limiter, so the stated above is not the (only) reason why I get bad results. I've uploaded the case here so that you can have a look, If you can spot anything that's wrong please tell me! I've been told it's the mesh but no luck in that front so far. I still have some things to try, though.


And davidtran,

I tried the fvSchemes that I posted here and with the BC for pressure at the inlet of zeroGradient and it runs past the 500 iterations (up to 1000 at least).

If you still want to use your settings, why don't you create the AMI from the converged solution of your run without AMI? I've never done it but it should work. You should be able to do it with
Code:
createBaffles
Code:
mergeOrSplitBaffles -split
There's an examples of createBafflesDict in the case I shared.
cvillescas is offline   Reply With Quote

Old   August 18, 2016, 07:40
Default
  #13
New Member
 
DavidTran
Join Date: Aug 2016
Posts: 10
Rep Power: 2
davidtran is on a distinguished road
Hi Caria,

Thank you so much for sharing your experience. They help me a lot. I will try to test my simulation based on your comments.

Best regards,
davidtran is offline   Reply With Quote

Old   August 18, 2016, 08:17
Default
  #14
Member
 
Mohammed Gowhar
Join Date: Feb 2014
Posts: 45
Rep Power: 4
mdgowhar is on a distinguished road
Quote:
Originally Posted by davidtran View Post
Hi cvillescas,

I have followed your guide by changing zeroGradient BC for pressure at the inlet. In addition, I also reduced "relTol" in fvSolution to 1e-5. However, the solution was blow-up at Time = 22. You can see from the attached file.
I looking forward to hearing from you.
In my experience if you use parallel with MRF, it always diverge.
But with the single core, it gives good converging without any problem.
mdgowhar is offline   Reply With Quote

Old   August 19, 2016, 09:45
Default
  #15
Member
 
Bruno
Join Date: Jun 2016
Location: Siegen, Germany
Posts: 59
Rep Power: 2
MBttR is on a distinguished road
Quote:
Originally Posted by cvillescas View Post
Hi Bruno,

I saw your question and I think it's a very interesting exercise but I've never studied how the size of the rotating region affects results.

I didn't answer your question because I don't know how to properly explain this, I was hoping some else would. The thing is I went to the last OF workshop and one of the founders and developers of foam-extend said there's a term in the equations (I think is the time derivative of phiCorrect) that is added at a given time step and substracted at the next time step. He said that when you have a rotating mesh, you are adding and substracting different things and you shouldn't be. He said that's the reason why you get different results when you run at different Courant numbers and I think that could be the reason why you are getting different results. Following this reasoning, I would say the smaller the rotating region the better, I don't know if that matches your experience. Do you have experimental data? Are you also simulating a propeller?

I've been trying to find the slides he was putting when he presented this but I haven't, sorry. He also said this would be solved with the next foam-extend release, foam-extend 4.0. It should be released shortly.

Myself I've been focusing on how the numerics affect the results, and at the moment my simulation highly depends on the gradient scheme and limiter that I choose, which is not acceptable. I've tried both rotating mesh and rotating reference frame and I get similar variations in propeller forces depending on the grad scheme and limiter, so the stated above is not the (only) reason why I get bad results. I've uploaded the case here so that you can have a look, If you can spot anything that's wrong please tell me! I've been told it's the mesh but no luck in that front so far. I still have some things to try, though.
Hi Carla,

Thanks for the reply. I'm using MRF, not AMI, so I don't think that applies to my case. Good to know in case I do switch to AMI though. I'm just a bit scared a bit about calculation times. I'm not working on a loose propeller, I'm working on a fully modeled quadcopter, with 4 MRF zones. I do have flight data but before even attempting to calibrate/validate, I want to find out how the size of the MRF domain dictates the result. Will keep an eye on it and keep you posted! Will also have a look at your case

*edit*
Quickly comparing meshes (I haven't gotten your results in yet) there's some things that may point me in the right direction already. You have a whole lot more domain finely meshed behind the propeller. Obviously, when I increase my MRF domain size, the refinement increases as well, as my refinement is linked to my MRF cylinders, which may cause some of the differences between the cases with different MRF domain sizes. I'd say your domain overall seems relatively small though, meaning the height and width of the bounding box related to the diameter of your propeller. Also, the mesh quality of the propeller seems relatively low? Other random things I notice; Why do you have U=0 fixedValue on the side walls, is this the case in the physical, real-life scenario? Rotation speed really around 600rpm? (I'm not used to ship propellers so could be). Seems so high as U is only 3.6.

Last edited by MBttR; August 19, 2016 at 10:53.
MBttR is offline   Reply With Quote

Old   August 22, 2016, 04:05
Default
  #16
New Member
 
Carla
Join Date: Jun 2015
Posts: 16
Rep Power: 3
cvillescas is on a distinguished road
Hi Bruno,

Thank you for your answer.

Definitely not your case if you are not using AMI, sorry. Good guess with the refinement, that could be it. Let us know if you confirm this.

Thanks for your advice. I will try increasing the domain size and obviously propeller refinement (that was my main front up to now, but I find the quality of the AMI decreases when I refine and my simulation crashes, I might need to define AMI further away from the propeller). I thought I had slip walls on the sides, I don't think it makes much of a difference but thank you for spotting that. In the experiments they do have walls but I don't want to be simulating that. And yes, rotation speed is 600rpm and is a normal speed for a marine propeller, you could even have 1000rpm.

Carla
cvillescas 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
LEMOS InflowGenerator r_gordon OpenFOAM Running, Solving & CFD 90 July 5, 2016 02:54
OpenFOAM 1.6 ext - Compilation errors - Fedora 17(32bit) toolpost OpenFOAM Installation 15 September 21, 2012 09:38
error message cuteapathy CFX 14 March 20, 2012 07:45
G95 + CGNS Bruno Main CFD Forum 1 January 30, 2007 01:34
Two-Phase Buoyant Flow Issue Miguel Baritto CFX 4 August 31, 2006 12:02


All times are GMT -4. The time now is 16:54.