Here is the script, if you have time to take a look, note that I don't have this error if I remove the noise line 106 in the deposition rate.
#depositionrate #no noise: #depositionRateVariable = (abs(v0*c.getGrad().dot(phi.getGrad())) + v0*c.getGrad().dot(phi.getGrad()) ) /2.0 + 1E-18 #with noise depositionRateVariable = abs(GaussianNoiseVariable(mesh=mesh, mean=1., variance=0.02))*( (abs(v0*c.getGrad().dot(phi.getGrad())) + v0*c.getGrad().dot(phi.getGrad()) ) /2.0 ) + 1E-18 On Mon, May 2, 2011 at 2:46 PM, Jonathan Guyer <[email protected]> wrote: > > > On May 2, 2011, at 8:00 AM, Julien Derr wrote: > > > I have a program which seems to run fine, but after quite a long time, it > randomly stops with always the same error : > > > > RuntimeError: maximum recursion depth exceeded > > WARNING: Failure executing file: <levelset.py> > > > > what is the meaning of this error ? > > Well, the literal meaning is that some function or method has called itself > too many times. E.g. In its simplest form: > > def A(): > return A() > > print A() > > A is a recursive function, because it calls itself. This will go on ad > infinitum (or ad maximum recursion depth exceeded, anyway). > > > More common, and harder to immediately recognize, are sequences like this: > > def A(): > return B() > > def B(): > return C() > > def C(): > return A() > > Python (like most programming languages) places a limit on how "deep" in > the recursion you can go. This is to prevent running out of memory (each > call stores information on the stack, both so the program knows where to > return to and for debugging as in the trace dump you posted). More > importantly, while recursion is a useful programming structure, recursion > that goes too deep is usually a bug, so failing is there to alert you that > there is something wrong. While there are usually ways to increase the > limit, I've never had cause to; excessive recursion has always been a bug in > my own code. > > > > do you know if there is a general class of problems causing this ? > > Not in FiPy. While I know we have generated recursion errors while > developing FiPy, these were bugs and they were immediately resolved. I don't > recall ever seeing a recursion error in a problem script after it had been > running for awhile. FiPy basically does the same calculations over and over > again, so if the recursion isn't too deep the 1st time, there is very little > reason that it should ever be too deep the 1000th time. > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------- > > 500 if self.stale or not self._isCached() or self._value is > None: > > --> 501 value = self._calcValue() > > 502 if self._isCached(): > > 503 self._setValueInternal(value=value) > > > > > /usr/local/lib/python2.6/dist-packages/FiPy-2.2_dev-py2.6.egg/fipy/variables/operatorVariable.pyc > in _calcValue(self) > > 69 else: > > 70 from fipy.tools import inline > > ---> 71 return inline._optionalInline(self._calcValueIn, > self._calcValuePy) > > 72 > > 73 def _calcValueIn(self): > > > Given this stack, my suspicion is that you somehow have declared a Variable > expression that depends on its own value, e.g, as though you had written: > > A = B * C + A > > and it was the *same* A on both sides of the equation. You can't do that, > though (Python redefines A, so the A's are different), so I don't know how > this situation might have arisen for you. If you send me your script, I'll > attempt to figure out what's happened. > > > >
parameters.input
Description: parameters.input
levelset.py
Description: levelset.py
