Thanks so much, Jonathan, makes a lot of sense !!!! and working fine now !!!
On Mon, May 2, 2011 at 7:44 PM, Jonathan Guyer <[email protected]> wrote: > > > 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(). > > > >
