Hi, this is the same problem that occurred on another thread. They didn't post the solution and somehow I couldn't post a reply so here it is under a new thread.

running gridgen v15 on this

System info: Windows XP Pro, version 2002, SP2, 32 bit Intel Core2 Quad CPU Q6600 @ 2.40GHz, 3.25 GB of RAM

I built a 2 million cell mesh no problem and managed to save it under gridgen format. However when trying to export to fluent 6 gridgen complains that it cannot allocate 205 MB. There is plenty of memory available. How is it possible to get around this problem?

The same happened with a 6 million cell mesh where gridgen could not allocate 610 MB. Again there was plenty of memory available.

Thanks, Ziad

ok found a way:

1. export to cgns unstructured

2. start fluent and through the TUI:

2.1 type "file", then "import", then "cgns"

2.2 type "mesh"

2.3 fluent will prompt for the cgns file name, type it in

So far it worked for a 1.9 million cell mesh. The same procedure above did not work through the GUI import function in fluent 6.2 so use the TUI.

It's kinda weird cause last week I managed to export a 2.3 million cells mesh directly to fluent through gridgen. sometimes it works and sometimes it doesn't even with all other applications closed. Seems to be an asw_export_fluent bug...

Hello ziad,

Glad to hear that you've got a workaround using CGNS to get to Fluent. As for whether the behavior when exporting to Fluent is a bug or not, it depends. Exporting the mesh to Fluent takes a lot of memory due to conversion to a face-based data structure (I'm not a software developer, so that's the extent of my knowledge). Also, the amount of memory used during export depends on whether your mesh is hex, tet, or some combination thereof. A trick that seems to work well is to divide the overall flow domain into blocks and assign a different Fluent volume condition to each block. Rather than allocating all the data at once, Gridgen only allocates memory for one VC at a time during export and this reduces the memory requirement. Our technical support people can provide more details on this strategy - contact them at support@pointwise.com.

Of course, another compounding factor is that Gridgen is a 32-bit application and this limits the total amount of memory it can allocate. The new product, Pointwise, is 64-bit so there isn't a memory limit, relatively speaking.

Hope this helps.

Thanks for the advice John. Multiple fluid zones did the trick and they are much more robust than going through CGNS and converters.

I am familiar with Pointwise and to my knowledge it does not do any anisotropic layers. This is essential for our research as we are constantly working with turbulent boundary layers. We're not planning any migration to Pointwise until anisotropy becomes possible with it. Until then Gridgen will do nicely, especially now that the grid size hurdle is removed

Cheers, Ziad

Ziad,

I'm glad you have a solution to your problem.

Gridgen's anisotropic tetrahedral extrusion is definitely on the migration path to the new Pointwise software (as is all of Gridgen's functionality).

Also, there are some interesting new anisotropic meshing features coming in Gridgen V15.12.

[Maxmum]

er...very bad. I also confront the gridgen allocation problem. I have 12G RAM, but it still says cann't allocate 670MB. I try hard and hard. at the moment I am going to give up. it output successfully. oh....god.maybe I should apply for the 64bit gridgen.