CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Native Meshers: snappyHexMesh and Others

snappyHexMesh taking a lot of RAM

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

Reply
 
LinkBack Thread Tools Display Modes
Old   September 4, 2010, 12:11
Default snappyHexMesh taking a lot of RAM
  #1
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
Hi all,

I wonder if anybody can comment on the RAM consumption of snappyHexMesh. I managed to create a starting mesh of about 620,000 cells and 905,000 points. Obviously a very moderate mesh size, but is taking over 7GB of RAM!!!!! Based on my experience with other meshers such as GridGen, Pointwise and ICEM-CFD this is very large.

Any idea how one can reduce snappy's appetite?

Ziad
Attached Images
File Type: jpg screenshot.jpg (96.4 KB, 62 views)
ziad is offline   Reply With Quote

Old   September 4, 2010, 12:28
Default
  #2
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
Quote:
Originally Posted by ziad View Post
I managed to create a starting mesh of about 620,000 cells and 905,000 points. Obviously a very moderate mesh size, but is taking over 7GB of RAM!!!!! Based on my experience with other meshers such as GridGen, Pointwise and ICEM-CFD this is very large. Ziad
Ziad,

as you mentioned this is a starting mesh size. Mesh can become much larger.... You can limit both the maximum of total cells created and the maximum cells per core in snappyHexMeshDict. You can also run it in parallel. What version of sHM are you using? Which step is the problem? Castellating snapping or layer addition?
Tetra-Meshers use a different principal so this is hard to compare. From my experience sHM comsumes about 1.5GB/1Mio but it is dependent mainly on layer generation.

Regards Bastian
bastil is offline   Reply With Quote

Old   September 4, 2010, 13:28
Default
  #3
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
Quote:
Originally Posted by bastil View Post
Ziad,

as you mentioned this is a starting mesh size. Mesh can become much larger.... You can limit both the maximum of total cells created and the maximum cells per core in snappyHexMeshDict. You can also run it in parallel. What version of sHM are you using? Which step is the problem? Castellating snapping or layer addition?
Tetra-Meshers use a different principal so this is hard to compare. From my experience sHM comsumes about 1.5GB/1Mio but it is dependent mainly on layer generation.

Regards Bastian
Hi Bastian,

Thanks for your reply.

Running OpenFOAM 1.7.0 in parallel on 4 cores of a PhenomII machine. Total RAM available is 7.8GB, hence the memory concern.

The mesh is computed without any problem that I can see, but then I am fairly new to snappy so maybe a more experienced eye can notice something I missed. The output log and snappyHexMeshDict are both provided.

Increasing the minDeterminant from 0.2 (previous post) to 0.35 improved the memory consumption and reduced the mesh size to 548,511 cells and 833,114 points. Consumption is now just about 6GB, but still high.

The CAD has features that cover 3 orders of magnitude in detail (25m to 0.1m). Layer specs are not aggressive and so far I am sticking to 1 surface layer everywhere.

Ziad
Attached Files
File Type: gz output035.log.gz (13.8 KB, 8 views)
File Type: gz snappyHexMeshDict.gz (3.8 KB, 21 views)
ziad is offline   Reply With Quote

Old   September 4, 2010, 16:41
Default
  #4
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
problem solved by separating the small surfaces from the larger ones. The mesh size was reduced by 3 and the memory consumption is now about 2GB-2.5GB. still pricy but at least it's manageable.
Attached Images
File Type: jpg overhang.jpg (48.3 KB, 104 views)
File Type: jpg tab.jpg (21.1 KB, 71 views)
ziad is offline   Reply With Quote

Old   September 13, 2010, 14:41
Default
  #5
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
Thanks Ziad,

I've been having a similar problem. Can you post the decomposeParDict file?

Greg
Greg Givogue is offline   Reply With Quote

Old   September 13, 2010, 15:56
Default
  #6
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
sure thing. I am using the simple decomposition. nothing fancy there.

FoamFile
{
version 2.0;
format ascii;

root "";
case "";
instance "";
local "";

class dictionary;
object decomposeParDict;
}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

numberOfSubdomains 4;

method simple;
//method metis;
//method parMetis;

simpleCoeffs
{
n (2 2 1);
delta 0.001;
}

hierarchicalCoeffs
{
n (3 2 1);
delta 0.001;
order xyz;
}

manualCoeffs
{
dataFile "cellDecomposition";
}

metisCoeffs
{
//n (5 1 1);
//cellWeightsFile "constant/cellWeightsFile";
}

// ************************************************** *********************** //
ziad is offline   Reply With Quote

Old   September 14, 2010, 20:02
Default
  #7
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
Thanks. Are you using a specific tutorial for the basis of your case?

I've been using the motorBike tutorial as a basis for my analysis. Whenever I refine the mesh in my case or in the motorBike tutorial in snappy I get either a segmentation fault or printstack error. I thought initially it was a ram issue (as discussed above) in my virtual machine so I increased it from 3.5 GB to 11 GB but that did not get rid of these errors.

In the snappyHexMeshDict file of the motorBike tutorial if you change the refinementsurfaces level (5 6) (line 115) to level (7 8) and run it - that's when I get the error. Can someone explain this? I have spent a lot of time playing with the snappyHexMeshDict file from the motorBike tutorial and adapting it to my geometry but I can't seem to get a finer mesh.

I've read that it might have something to do with the fvsolutions and fvschemes files of the motorBike tutorial but I'm not really sure. I don't really understand what either has to do with snappy.

I'd really appreciate any suggestions you may have. I'm really stuck here.

Thanks again!

I'm running OF 1.7.0 in Virtualbox with 11 GB ram on a quad core iMac (2.66 GHz).

Last edited by Greg Givogue; September 14, 2010 at 20:36.
Greg Givogue is offline   Reply With Quote

Old   September 14, 2010, 21:02
Default
  #8
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
I actually put together my own case. Ran the motorbike tutorial the first time successfully but ended doing my own thing. In my case every single surface is defined in its own stl file and every intersection is defined by an explicit feature edge with its own refinement level. I found that it makes things easier. Still not perfect though since my geometry has nothing but perpendicular surfaces and straight edges, a very Cartesian building. Pythagoras would be proud

What you could do to reduce mesh size if to reduce the overall domain size to slightly larger than the refinement box and then merge it back with the other upstream and downstream chunks with mergeMeshes and stitchMesh. It worked for me.

As for platform I am running OpenSuSe 11.2 and OF1.7.0 on a PhenomII X4, without any virtual machines. Sorry but I am not familiar with OSX. However, 11GB of virtual RAM seems a bit exaggerated. How much physical RAM do you have? I would guess that if your virtual memory exceeds your physical memory by some amount then one should expect stack errors. Keep in mind OSX requires a minimum memory to run as well. Can you switch to a Linux box?

What kind of geometry do you need to mesh?
ziad is offline   Reply With Quote

Old   September 14, 2010, 22:33
Default
  #9
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
Thanks for response and the suggestions. I am running Virtualbox on my mac and the virtual OS is Ubuntu 10.04 in which OF resides. Virtual ram is 11 GB and the physical ram is 12 GB. I was just about to try sectioning the body into separate stl files. Right now it's one stl with regions defined within. I think that this is suppose to behave the same as separate stls but I don't think it is. I'll give that a shot and report back.

The geometry is similar to the centre line fuel tank on a fighter jet. It's cigar shape (streamlined) with a mounting frame on one side. I used the motorBike tutorial because it seemed to best fit my problem. I will post an image shortly.

Last edited by Greg Givogue; September 14, 2010 at 23:15.
Greg Givogue is offline   Reply With Quote

Old   September 14, 2010, 23:21
Default
  #10
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
Here's the geometry.
Attached Images
File Type: jpg CFD Model.jpg (37.0 KB, 81 views)
Greg Givogue is offline   Reply With Quote

Old   September 14, 2010, 23:40
Default
  #11
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
It's probably the thin plates in the attachment frame. Is that the reason why you need to go with (7 8) refinement levels?

I would do this:
* Try to separate each plate in as many separate faces as possible.
* Separate as well the thin edges and use equal min-max levels on each face. All faces do not need to have the same min-max combo so you can adjust to the local dimensions.
* Use straight lines on the edge intersections with higher level to resolve the intersection regions (example: (5 5) for the face and 7 for the edge).
* Use nCellsBetweenLevels 1

Here's an example of my setup:

geometry
{
BigCondenser.stl
{
type triSurfaceMesh;
name BigCondenser;
regions
{
BIGCONDENSER // this is the name you just type in the stl file after keywords solid and endsolid
{
name BIGCONDENSER;
}
}
}
.
.
.
// Big Condenser lines
{
file "H0H1.eMesh";
level 6;
}
.
.
.
refinementSurfaces
{
BigCondenser
{
level (4 4);
}
.
.
.
addLayersControls
{
relativeSizes true;

// Per final patch (so not geometry!) the layer information
layers
{
BIGCONDENSER // this is the patch name
{
nSurfaceLayers 1; // you can add more with refineMesh later
}

going to bed now. let me know how it works.
ziad is offline   Reply With Quote

Old   September 15, 2010, 01:21
Default
  #12
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
Exactly, the support frame is where I get poor meshing results. I played around with surface/region refinements and surface layers. I have set up my stl files and snappyHexMeshDict file as recommended.

I like your suggestion of using the 'features' refinement and focusing on the edges and faces. I had read that it effectively doesn't work but I will give it a shot. I'm a little confused about the file type it requires to describe an edge, .eMesh? edgeMesh? Do you have an example?

I'd be happy to provide you with my stl files if you'd like to take a look at them - just send me your email address. Thanks again for all your help.

Here's my snappyHexMeshDict;


// List steps to run
castellatedMesh true;
snap true;
addLayers true;


// Geometry. Definition of all surfaces. All surfaces are of class
// searchableSurface.
// Surfaces are used
// - to specify refinement for any mesh cell intersecting it
// - to specify refinement for any mesh cell inside/outside/near
// - to 'snap' the mesh boundary to the surface
geometry
{
pod.stl //stl file located in constant/trisurface
{
type triSurfaceMesh;
name pod;
regions
{
POD
{
name POD;
}
}
}

bracket1.stl
{
type triSurfaceMesh;
name bracket1;
regions
{
BRACKET1
{
name BRACKET1;
}
}
}
bracket2.stl
{
type triSurfaceMesh;
name bracket2;
regions
{
BRACKET2
{
name BRACKET2;
}
}
}
bracket3.stl
{
type triSurfaceMesh;
name bracket3;
regions
{
BRACKET3
{
name BRACKET3;
}
}
}

bracket4.stl
{
type triSurfaceMesh;
name bracket4;
regions
{
BRACKET4
{
name BRACKET4;
}
}
}

frame.stl
{
type triSurfaceMesh;
name frame;
regions
{
FRAME
{
name FRAME;
}
}
}

// refinementBox// geometry is bound by this region in environment
//{
// type searchableBox;
//min (-0.5 -0.475 0.0);
//max ( 8.0 0.925 2.0);
//}
};



// Settings for the castellatedMesh generation.
castellatedMeshControls
{

// Refinement parameters
// ~~~~~~~~~~~~~~~~~~~~~

// If local number of cells is >= maxLocalCells on any processor
// switches from from refinement followed by balancing
// (current method) to (weighted) balancing before refinement.
maxLocalCells 1000000;

// Overall cell limit (approximately). Refinement will stop immediately
// upon reaching this number so a refinement level might not complete.
// Note that this is the number of cells before removing the part which
// is not 'visible' from the keepPoint. The final number of cells might
// actually be a lot less.
maxGlobalCells 2000000;

// The surface refinement loop might spend lots of iterations refining just a
// few cells. This setting will cause refinement to stop if <= minimumRefine
// are selected for refinement. Note: it will at least do one iteration
// (unless the number of cells to refine is 0)
minRefinementCells 10; //changed from 10

// Allow a certain level of imbalance during refining
// (since balancing is quite expensive)
// Expressed as fraction of perfect balance (= overall number of cells /
// nProcs). 0=balance always.
maxLoadUnbalance 0.10;


// Number of buffer layers of cells between different levels of refinement.
// 1 means normal 2:1 refinement restriction, larger means slower
// refinement.
nCellsBetweenLevels 1;



// Explicit feature edge refinement
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// Specifies a level for any cell intersected by its edges.
// This is a featureEdgeMesh, read from constant/triSurface for now.
features
(
//{
// file "someLine.eMesh";
// level 2;
//}
);



// Surface based refinement
// ~~~~~~~~~~~~~~~~~~~~~~~~

// Specifies two levels for every surface. The first is the minimum level,
// every cell intersecting a surface gets refined up to the minimum level.
// The second level is the maximum level. Cells that 'see' multiple
// intersections where the intersections make an
// angle > resolveFeatureAngle get refined up to the maximum level.

refinementSurfaces
{
pod
{
level (2 3);
}

bracket1
{
level (2 3);
}

bracket2
{
level (2 3);
}

bracket3
{
level (2 3);
}

bracket4
{
level (2 3);
}

frame
{
level (2 3);
}
}

// Resolve sharp angles
resolveFeatureAngle 60;


// Region-wise refinement
// ~~~~~~~~~~~~~~~~~~~~~~

// Specifies refinement level for cells in relation to a surface. One of
// three modes
// - distance. 'levels' specifies per distance to the surface the
// wanted refinement level. The distances need to be specified in
// descending order.
// - inside. 'levels' is only one entry and only the level is used. All
// cells inside the surface get refined up to the level. The surface
// needs to be closed for this to be possible.
// - outside. Same but cells outside.

refinementRegions
{
//refinementBox
//{
//mode inside;
// levels ((1E15 5)); // distance is ignored (1E15) but must be listed
// }
//pod
//{
// mode distance;
//levels ((0.01 6)); // refined mesh near surface (1 cm) at refinement level
//}
}


// Mesh selection
// ~~~~~~~~~~~~~~

// After refinement patches get added for all refinementSurfaces and
// all cells intersecting the surfaces get put into these patches. The
// section reachable from the locationInMesh is kept.
// NOTE: This point should never be on a face, always inside a cell, even
// after refinement.
locationInMesh (3 3 0.43);
}



// Settings for the snapping.
snapControls
{
//- Number of patch smoothing iterations before finding correspondence
// to surface
nSmoothPatch 10; //was 3

//- Relative distance for points to be attracted by surface feature point
// or edge. True distance is this factor times local
// maximum edge length.
tolerance 1; // was 4

//- Number of mesh displacement relaxation iterations.
nSolveIter 30; //was 30

//- Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 5; //was 5
}



// Settings for the layer addition.
addLayersControls
{
// Are the thickness parameters below relative to the undistorted
// size of the refined cell outside layer (true) or absolute sizes (false).
relativeSizes true;

// Per final patch (so not geometry!) the layer information
layers
{
POD
{
nSurfaceLayers 1;
}
BRACKET1
{
nSurfaceLayers 1;
}
BRACKET2
{
nSurfaceLayers 1;
}
BRACKET3
{
nSurfaceLayers 1;
}
BRACKET4
{
nSurfaceLayers 1;
}
FRAME
{
nSurfaceLayers 1;
}
}

// Expansion factor for layer mesh
expansionRatio 1.5; //was 1.0

//- Wanted thickness of final added cell layer. If multiple layers
// is the thickness of the layer furthest away from the wall.
// See relativeSizes parameter.
finalLayerThickness 0.8; //was 0.3

//- Minimum thickness of cell layer. If for any reason layer
// cannot be above minThickness do not add layer.
// Relative to undistorted size of cell outside layer.
minThickness 0.001;//was 0.1

//- If points get not extruded do nGrow layers of connected faces that are
// also not grown. This helps convergence of the layer addition process
// close to features.
nGrow 1; //was 1


// Advanced settings

//- When not to extrude surface. 0 is flat surface, 90 is when two faces
// make straight angle.
featureAngle 30;//was 30

//- Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 3;// was 3

// Number of smoothing iterations of surface normals
nSmoothSurfaceNormals 1;//was 1

// Number of smoothing iterations of interior mesh movement direction
nSmoothNormals 3;//was 3

// Smooth layer thickness over surface patches
nSmoothThickness 10;

// Stop layer growth on highly warped cells
maxFaceThicknessRatio 0.5;// changed from 0.5

// Reduce layer growth where ratio thickness to medial
// distance is large
maxThicknessToMedialRatio 0.3;// changed from 0.3

// Angle used to pick up medial axis points
minMedianAxisAngle 130;

// Create buffer region for new layer terminations
nBufferCellsNoExtrude 0;

// Overall max number of layer addition iterations
nLayerIter 50;
}



// Generic mesh quality settings. At any undoable phase these determine
// where to undo.
meshQualityControls
{
//- Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 65;

//- Max skewness allowed. Set to <0 to disable.
maxBoundarySkewness 20;
maxInternalSkewness 4;

//- Max concaveness allowed. Is angle (in degrees) below which concavity
// is allowed. 0 is straight face, <0 would be convex face.
// Set to 180 to disable.
maxConcave 80;

//- Minimum projected area v.s. actual area. Set to -1 to disable.
minFlatness 0.5;

//- Minimum pyramid volume. Is absolute volume of cell pyramid.
// Set to a sensible fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1E30) to disable.
minVol 1e-13;

//- Minimum face area. Set to <0 to disable.
minArea -1;

//- Minimum face twist. Set to <-1 to disable. dot product of face normal
//- and face centre triangles normal
minTwist 0.02;

//- minimum normalised cell determinant
//- 1 = hex, <= 0 = folded or flattened illegal cell
minDeterminant 0.001;

//- minFaceWeight (0 -> 0.5)
minFaceWeight 0.05;

//- minVolRatio (0 -> 1)
minVolRatio 0.01;

//must be >0 for Fluent compatibility
minTriangleTwist -1;


// Advanced

//- Number of error distribution iterations
nSmoothScale 4;
//- amount to scale back displacement at error points
errorReduction 0.75;
}


// Advanced

// Flags for optional output
// 0 : only write final meshes
// 1 : write intermediate meshes
// 2 : write volScalarField with cellLevel for postprocessing
// 4 : write current intersections as .obj files
debug 0;


// Merge tolerance. Is fraction of overall bounding box of initial mesh.
// Note: the write tolerance needs to be higher than this.
mergeTolerance 1E-6;
Greg Givogue is offline   Reply With Quote

Old   September 15, 2010, 14:37
Default
  #13
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
Looks good but you still need to separate the brackets in individual faces. I use salome and this is best done with the explode function under the new entity menu. I don't think it makes a difference whether you pick shell or face as the sub-entity type.

Another trick to reduce the number of cells is to jack up the minDeterminant parameter. The higher it is the more hexahedra you have and hexahedral meshes have a number of cells roughly equal to the number of points. For my case the optimum range was 0.1 < minDeterminant < 0.3.

You should use *.eMesh files in the triSurface folder. See example attached. You can email me at ziad dot boutanios at gmail dot com.
Attached Files
File Type: gz A1A0.tar.gz (417 Bytes, 12 views)
ziad is offline   Reply With Quote

Old   September 15, 2010, 18:24
Default
  #14
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
Thanks again. I'll give those a shot and report back. I'm trying to get snapEdge to work as well for my case - I'm getting moderate results so far. I'll send you an email later tonight with my case. I really appreciate the help - otherwise I'd be really stuck and losing my mind!

I'm not sure if increasing the minDeterminant is the best idea for my case because of the contours along the pod surface.
Greg Givogue is offline   Reply With Quote

Old   September 15, 2010, 19:09
Default
  #15
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
Don't worry about it. We all learn from each other on the forums.

I tried snapEdge before and did not really like the result since my geometry has nothing but perpendicular edges. A really extreme case. The mesh did not pass the checkMesh after snapEdge and I found that it was better to minimize the problem with the eMesh edges. It might work better for you though. Looking forward to see the result.

Why should the contours suffer from increasing minDeterminant?

BTW how big is your mesh so far?

Last edited by ziad; September 15, 2010 at 20:37.
ziad is offline   Reply With Quote

Old   September 15, 2010, 21:18
Default
  #16
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
The last attempt I made produced about 200k cells. I had originally dabbled with Salome but I found it couldn't produce stl files with a high enough degree of tessellation. This is important in my case for contoured shapes to be reasonably smooth. It would probably be sufficient for the brackets and frame of my problem if/when I go down the face/edge path. I found that SolidWorks can produce high quality stl files. Anyway, I will email you my latest attempt shortly.
Thanks again!
Greg Givogue is offline   Reply With Quote

Old   September 15, 2010, 22:01
Default
  #17
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
here is my snappyHexMeshDict for reference if it can help.
Attached Files
File Type: gz snappyHexMeshDict_medium.tar.gz (5.1 KB, 16 views)
ziad is offline   Reply With Quote

Old   September 16, 2010, 16:47
Default
  #18
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
thanks - just for everyone else - Ziad ran my case with no errors. We both think that it has something to do with my Virtualbox 3.2.6 or Ubuntu 10.04 ....
Greg Givogue is offline   Reply With Quote

Old   September 16, 2010, 22:47
Default Ahah!
  #19
Senior Member
 
Ziad Boutanios
Join Date: Mar 2009
Location: Montréal, Canada
Posts: 113
Rep Power: 8
ziad is on a distinguished road
why use a virtual machine when you can run native...

http://www.cfd-online.com/Forums/ope...?highlight=osx
ziad is offline   Reply With Quote

Old   September 26, 2010, 13:08
Default
  #20
Member
 
Greg Givogue
Join Date: Aug 2010
Location: Ottawa Canada
Posts: 57
Rep Power: 7
Greg Givogue is on a distinguished road
I downloaded VMWare Fusion 3 and it seems to be working really well with Ubuntu 10.04 as the guest.
Greg Givogue 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
stitchMesh and snappyHexMesh gdbaldw OpenFOAM 0 December 23, 2009 03:09
SnappyHexMesh samiam1000 OpenFOAM 0 October 5, 2009 10:32
Problem with snappyHexMesh samiam1000 OpenFOAM 0 October 3, 2009 05:08
SnappyHexMesh not generate mesh first time mavimo OpenFOAM Mesh Utilities 4 August 26, 2008 07:08
Can FLUENT run under Linux with 2 Gb of RAM? Paul Gregory FLUENT 0 February 13, 2001 21:10


All times are GMT -4. The time now is 23:53.