On Fri, Nov 14, 2008 at 2:52 PM, Zhiwen Liang <[EMAIL PROTECTED]> wrote: > > From the "top", the program takes a vsize of around 2G while the available > physical RAM is >20G for the server. So I think I have enough resource.
Okay. How much memory is the machine slated to have in the specs? The machine has a 64 bit OS, I assume. The question is whether you are running out of memory. The error statement certainly seems to be suggesting that. It's possible, 80 * 80 * 80 is a fairly large problem. > I got the memory error when defining one of the source terms for the > equation. I have a second order diffusion term and several coupled source > terms (You probably might have seen those long long equations I sent you > before). I don't know if the source terms cause the trouble. It could be that you have an array multiplication that is leading to an (Ncells, Ncells) array which is huge, although you would probably notice that in top. Go to where the thing is failing "line 80 in variables/gaussCellGradVariable.py" and print numerix.shape(orientations) and numerix.shape(contributions) just to check that "orientations * contributions" is not somehow making a weird shaped massive array. Also, put a raw_input() statement right before this line and check how much memory is used right before that statement. > Yes I am using the uniform grid. All the meshes I use so far are created by > Grid3D. I am thinking to use GMSH though. Won't be as memory efficient at the moment. > I am now using the GMRES solver from pysparse. What do you recommend? That's fine. > When I look at the top, the memory usage for the program doesn't change much > throughout the definition of the equations, and it crashes somehow in It won't change much. The equations are mostly empty objects. > between. And I am solving for an equilibrium state without any time > evolution (just one time step). But I will check the variables. yeah, but you are doing some sort of sweeping to convergence, which is the same in this context. -- Daniel Wheeler
