On May 2, 2011, at 11:39 AM, I wrote:
> Does it really need to be such a big problem? Does it fail in a 100x100 mesh?
Answering my own question, I got it to fail after a few 245 steps on a 100x100
mesh.
The issue was obvious once I saw the beginning of the crash report:
Traceback (most recent call last):
File "levelset.py", line 182, in <module>
stepline= "step #"+str(step)+" time="+str(absolutetime)+" (dt="+str(dt)+")"
File
"/Users/guyer/Documents/research/FiPy/reconstrain/fipy/variables/variable.py",
line 360, in __str__
return str(self.value)
so the problem is in one of step, absolutetime, and dt and it was then clear
(to me, anyway) that the problem is with:
dt = min(dt0 * cellSize / extensionVelocityVariable.max(),0.01)
absolutetime=absolutetime+dt
dt is a Variable, because extensionVelocityVariable.max() is a Variable,
because extensionVelocityVariable is a Variable. As a result, absolutetime is
sequentially defined as the operator variable expressions:
0.01
((0.0025 / extension velocity.max(axis = axis)) + 0.01)
(((0.0025 / extension velocity.max(axis = axis)) + 0.01) + (0.0025 / extension
velocity.max(axis = axis)))
((((0.0025 / extension velocity.max(axis = axis)) + 0.01) + (0.0025 / extension
velocity.max(axis = axis))) + (0.0025 / extension velocity.max(axis = axis)))
:
:
and so on (it's as though in the 4th step you wrote `absolutetime = 0.01 + dt +
dt + dt` and by the 1000th step, you have "+ dt" 999 times). This is not a
recursion error, per se, but Python is apparently unable to tell the difference.
The solution is to define
dt = min(dt0 * cellSize / extensionVelocityVariable.max().getValue(),
0.01)
Now dt will just be a float and absolutetime will just be a float.
I don't know why it mattered if you included noise in depositionRateVariable. I
would guess that it just induced failure earlier due to more calls to
Variable._calcValue().
