CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > General Forums > Main CFD Forum

RAM for large number of cells in CFD Simulation

Register Blogs Community New Posts Updated Threads Search

Like Tree2Likes
  • 2 Post By sbaffini

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 10, 2017, 09:39
Default RAM for large number of cells in CFD Simulation
  #1
New Member
 
saketh
Join Date: Sep 2017
Posts: 1
Rep Power: 0
saketh is on a distinguished road
For a case of 1 million cells in fluent, RAM consumption is less than 150 mb where as in our solver it is 12 gb. what is the key thing that we are missing in our data structure?
saketh is offline   Reply With Quote

Old   September 10, 2017, 20:11
Default Ram
  #2
Senior Member
 
Selig
Join Date: Jul 2016
Posts: 213
Rep Power: 10
selig5576 is on a distinguished road
Hi, what is probably missing is the fact that you are not doing memory allocation. If you are doing Fortran or C++ use dynamic arrays (or better yet if you are doing C++ use vectors.)
selig5576 is offline   Reply With Quote

Old   September 11, 2017, 04:51
Default
  #3
Senior Member
 
sbaffini's Avatar
 
Paolo Lampitella
Join Date: Mar 2009
Location: Italy
Posts: 2,152
Blog Entries: 29
Rep Power: 39
sbaffini will become famous soon enoughsbaffini will become famous soon enough
Send a message via Skype™ to sbaffini
That seems extremely low even for a 2D computation. Are you sure it is not 1.5 Gb? Because 150 Mb is just around 18 double precision floating point values per cell. Take at least 8 of them (4 variables in 3D + cell volume + 3 for cell centroid). Then consider that faces are typically 3 times the number of cells, and you need at least the face area vector (3 doubles), the face centroid (3 doubles) and the mass flux (1 double), totalling 7 x 3 = 21 doubles per cell. We already are at 29 doubles and I'm not even considering the grid nodes (3 more doubles per cell approx.), one double to store at least the current residual, one to store the current solution increment. Then you have all sort of indexing for the internal machinery. The matrix coefficients (say, approx 7 doubles per cell), etc. etc.

In contrast, your 12 Gb quote is quite high and might be due to lack of deallocation. Or, maybe, you are using more variables than needed (e.g., for a segregated solver, you only need one matrix and one solution vector).

This might be ok early in the development phase, but then you need to figure out more clever ways to retrieve some information without storing them directly.

If you give more details on your code we might help you more.
mprinkey and Stevie_1200 like this.
sbaffini is offline   Reply With Quote

Old   September 17, 2017, 13:26
Default
  #4
New Member
 
nkalkote's Avatar
 
Nikhil
Join Date: Mar 2016
Location: India
Posts: 15
Rep Power: 10
nkalkote is on a distinguished road
............

Last edited by nkalkote; September 18, 2017 at 02:39.
nkalkote is offline   Reply With Quote

Reply


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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
decomposePar problem: Cell 0contains face labels out of range vaina74 OpenFOAM Pre-Processing 37 July 20, 2020 05:38
[blockMesh] Create internal faces as patch in blockMesh m.delta68 OpenFOAM Meshing & Mesh Conversion 14 July 12, 2018 14:43
[blockMesh] --> foam fatal error: lillo763 OpenFOAM Meshing & Mesh Conversion 0 March 5, 2014 10:27
AMI interDyMFoam for mixer danny123 OpenFOAM Running, Solving & CFD 4 June 19, 2013 04:49
killed "snappyHexMesh" parkh32 OpenFOAM Pre-Processing 2 April 8, 2012 17:12


All times are GMT -4. The time now is 08:15.