Discussion Forum

November 16, 2009 6:51am UTC

outofmemory

Hello
I have a model of contact, when the grid have done very fine , it cannot solve. it posts an error


Exception:
com.femlab.jni.FlNativeException: Out of memory during assembly
Messages:
Out of memory during assembly

Stack trace:
at xmodel.cpp, row 2320, ()
at com.femlab.solver.FlSolver.femStatic(Native Method)
at com.femlab.solver.FemStatic.run(Unknown Source)
at com.femlab.server.FlRunner.run(Unknown Source)
at com.femlab.util.i.run(Unknown Source)
at com.femlab.util.aa.run(Unknown Source)


I need your council to deal with this problem,
thank you

Reply  |  Reply with Quote  |  Send private message  |  Report Abuse

November 17, 2009 5:24pm UTC in response to Hoa Ngan NGUYEN

Re: outofmemory

Hi Hoa,

I also had some experiences with the problem. Let try with the following things:
- Make mesh less fine with sub-domains not important or all of sub-domains
- Using symmetrical geometry properties to model for only small parts of device or machine, so you can reduce required memory significantly and your program will run faster.

Good luck!

Hung Vu Xuan

Reply  |  Reply with Quote  |  Send private message  |  Report Abuse

December 13, 2009 11:38pm UTC in response to Hoa Ngan NGUYEN

Re: outofmemory

On Page 124 of v3.5a User's Guide there is a description of how to increase the default Java heap space by changing the MAXHEAP variable in the file comsol.opts, which is loaded on launch. The default value that came with v3.5 was 256 MB. Try increasing this, taking into account how much memory you have in your machine. Let us know how this works.

Reply  |  Reply with Quote  |  Send private message  |  Report Abuse

March 19, 2010 2:12pm UTC in response to Davis Sentman

Re: outofmemory

Hi - since I am running into the sampe problem of too little memory I am looking for answers and found your comment. I dont't think that increasing Java's heap space does solve the problem because the solvers don't use the heap as far as I know. Therefore, it might even be better to decrease the size of the heap to free more RAM for the solver. Any experiences with that?
Pardiso out-of-core also ran out of memory in one of my problems and I cannot make the mesh coarser or else the solution is not correct. I keep trying other solvers...

Reply  |  Reply with Quote  |  Send private message  |  Report Abuse

March 19, 2010 5:57pm UTC in response to R. Faycal Hamou

Re: outofmemory

I have received similar error with very few and coarse mesh on a very simple geometry. I have 3GB available memory and >2Ghz dual core CPU! Isn't it odd? I have used to run other commercial programs with much more mesh and more complicated geometry with a weaker machine. So, I think it may not be necessarily only a memory problem.

Reply  |  Reply with Quote  |  Send private message  |  Report Abuse

March 21, 2010 9:23am UTC in response to James D. Freels

Re: outofmemory

Since posting my comment above I bought a new quad-core machine with 24 GB memory, and am running Win7-64bit. The old our-of-memory problems disappeared, but it's easy to make them reappear again with a fine enough mesh. Hit the refine-mesh enough times and eventually you run out of memory. For me now it is at 38M nodes. Even for "only" 8M nodes, the solvers ramp up the memory usage all the way up to 24GB, and then it starts swapping.

However, there is now another problem not directly related to solving a particular problem, but rather rendering it on the screen. For mesh sizes that are too large you can get another, but different, kind of out-of-memory problem that reflects the size of your VRAM. However, this can be solved by turning off the automatic rendering, running your problem, then reducing the size of the mesh for the solution so that it will display.

Reply  |  Reply with Quote  |  Send private message  |  Report Abuse