I am using gridgen15,and when I want to make a grid of more than 2000,000 cells selecting the solver Fluent, the export process has a problem which shows:asw_export_fluent:Memory allocation of 937MB failed.

Thus, I began to increase the default value for the momory setting in gridgen, however, it does not work.

Have you ever seen this problem yet?

july:

Two million cells for Fluent is well within Gridgen's capabilities. However, because of the vast difference between how Gridgen stores the mesh and how Fluent needs it written, the code has to allocate quite a bit of memory to perform that conversion.

The "trick" is to divide your mesh into several blocks and assign each one it's own volume condition. During export, all cells are exported based on their VC so that minimizes the amount of memory that has to be allocated.

However, two million cells is well below the level at which this trick is normally required so something else must be going on. How much memory does your computer have? Also, if you have any structured hex blocks, make sure they're right-handed.

If none of these ideas work, please contact our Tech Support Team at 800-4PTWISE or support@pointwise.com and they'll help you.

John:

I have tested it for several times, my computer has 2G

memory, and however I find something really interesting

that for a single .gg file with about 350 million whole structrued hex grid, sometimes it may export the grid successfully, while sometimes it may fail warning "cannot write bc files".

I really appreciate your "trick" ,it is certainly the right way to the problem. However, as the number of blocks is too large(several hundred) to assign each of them a VC condition, I wonder whether the way of assign a couple of blocks a VC condition may achieve the same "trick" effect with much less munual intervention.

Honestly saying, this fluent-related export problem also occurs while using pointwise16.0, but the same .gg file never fails even with 550 million hex in exporting cfx-type grid (.GRD) which can be correctly imported into cfx,recognized and checked with no warining).

Thank you so much.

Best regards.

July

July,

For your grid with 350 million hex cells, its memory usage depends on whether the structured blocks have only been initialized using the algebraic method or whether they have been either extruded or run through the elliptic PDE solver. The two latter methods "lock" the volume grid and retain all the points (i.e. keep the memory allocated). If you've only initialized the grid, the points aren't saved and are allocated only as necessary. Therefore, the memory usage during export will be less.

For the grid with several hundred blocks, I suggest assigning VCs using a Glyph script. And each block doesn't need a unique BC - you can use as few VCs as it takes to make the trick work. However, by doing it with a script, there's no reason you couldn't apply a unique VC to each block.

Regarding Fluent vs. CFX export, converting a grid to Fluent's storage structure takes more memory than any other CFD solver export that we have implemented. CFX export doesn't have to allocate as much memory. Also, I hope you're able to use the 64-bit version of Pointwise so that you can allocate more memory.

One last bit of information: in Pointwise, the CGNS export is the most memory efficient of any export.

John:

well, you are so proficient in gridgen and know

so much about it. Thank you so much for your help,

maybe the next thing I should to deal with is the

edition of the gridgen script. I have used it before.

Best regards.

July

http://www.pointwise.com/archive/95-01.shtml

actually we need more people like john to answer questions related to their softwares. (i should say thanks to john for his efforts).