3D grids much slower than 1D/2D with similar number of cells

[CalebDmArcher]

Hi, I am trying to modify the code from examples/diffusion/mesh1D.py to a simple 3D case. The code is shown below, which is however not working. I also tried the steady-state equation which is not working, either.

I noticed that it gets stuck at eq.solve(var=phi, dt=timeStepDuration) at the very beginning.
Could anyone point out where I got it wrong?

from fipy import *
from mayavi import mlab

nx = ny = nz = 50
dx = dy = dz = 1.
Lx = Ly = Lz = nx * dx

mesh = Grid3D(nx=nx, ny=ny, nz=nz, dx=dx, dy=dy, dz=dz)

phi = CellVariable(name="solution variable", mesh=mesh, value=0.)

D = 1.
eq = TransientTerm() == DiffusionTerm(coeff=D)

phi.constrain(0., mesh.facesLeft)
phi.constrain(1., mesh.facesRight)
phi.constrain(0., mesh.facesTop)
phi.constrain(0., mesh.facesBottom)

timeStepDuration = 0.01
steps = 100

for step in range(steps):
    print(f"I am running at step {step}")
    eq.solve(var=phi, dt=timeStepDuration)
    print(f"I have finished the calculation at step {step}")
    if step % 10 == 0:
        mlab.clf()
        mlab.contour3d(phi.value, contours=[0.5], transparent=True)
        mlab.colorbar()
        mlab.show()

[CalebDmArcher]

Turns out that 50 * 50 * 50 grids require a huge amount of time for calculation.
if it is 20 or 30 nodes on each direction, it is fine.

[guyer]

I've found the same thing. I haven't had time to figure out why. My laptop can readily handle 2D problems with an order of magnitude more degrees of freedom.

[CalebDmArcher]

I've found the same thing. I haven't had time to figure out why. My laptop can readily handle 2D problems with an order of magnitude more degrees of freedom.

I did a simple experiment on it and the results are shown in the image below.

The increase in time cost for grid size from 10 to 40 is phenomenal.
It has a very hard time to calculate the solution for the 40 * 40 * 40 mesh. And thus it is not practical at all for a larger grid number.

I am trying to figure out a way to do non-uniform mesh, maybe with Gmesh. If you have any good resources about FiPy with non-uniform mesh, will really appreciate it if you could let me know.

[guyer]

Why did you close this? It's a legitimate issue.

[CalebDmArcher]

Why did you close this? It's a legitimate issue.

I'm sorry! New to this forum and not very familiar with how the threads work.
I will never close a case by myself and wait for any official assistant to do it.

I thought my investigation was enough to explain the phenomenon, plus there was no updated conversation, so I thought I should close it as I, the questioner, had gotten the answer.

It will never happen again.

[guyer]

Understood. If it's a question about how to do things, it's fine for you to close it when you think it's been addressed, but when there's a problem with FiPy, we prefer to keep them open so we don't lose sight of them. I realize it may not always be obvious which-is-which, which is one reason I've been shunting the former over to discussions.

In this case, while I haven't had time to troubleshoot, and I really don't understand what's happening, there's definitely a problem.