Hi Dean, Really appreciate all the feedback.
On Sat, May 3, 2008 at 8:28 PM, fred2 <[EMAIL PROTECTED]> wrote: > > previously i sent in some test/validation cases for the linear burgers eqn, > etc.. those cases were implicitly for fipy v. 1.2 (CURRENT tag). > attached are versions that will run under fipy 1.2 or 2.0 (trunk). there is > also a new test case (requires v. 2.0) for the nonlinear burgers eqn (thanks > much, Daniel). results look good. I'll get these test cases into the next release. I haven't got round to it just yet. > for the nonlinear case, i have tried to add a source term involving a > gradient to the equation, but sweep throws an exception. the source term > does not involve the dep var, so it is explicitly coded. not sure whether > this may be a feature which is not (re)implemented in trunk, or just a user > error. (other forms of source terms work well, as expected. attempts to use > getFaceGrad, etc., cause problems in the eqn definition itself, as might be > expected). The feature is certainly still in FiPy. > thanks in advance for any suggestions. (no urgency, as i'll be offline for > a couple weeks). Playing around in ipython I noticed the following. In [2]: from fipy import * In [3]: mesh = Grid1D(nx=10) In [4]: v = CellVariable(mesh=mesh) In [5]: a = v.getGrad().dot([1,]) In [6]: a Out[6]: (_MeshVariable._dot(_gauss_grad, [1], index)) In [7]: a.__class__ Out[7]: <class 'fipy.variables.binaryOperatorVariable.binOp'> In [8]: eqn = ImplicitDiffusionTerm() == a In [9]: eqn.solve(v) --------------------------------------------------------------------------- exceptions.ValueError Traceback (most recent call last) ... ValueError: invalid return array shape In [10]: a = v.getGrad()[0] In [11]: eqn = ImplicitDiffusionTerm() == a In [12]: eqn.solve(v) So, using "a = v.getGrad()[0]" seemed fine, while "a = v.getGrad().dot([1,])" is broken. I think I know the reason. The index method knows it is a rank 0 CellVariable and can be added to the equation as a source, while the dot way is being dotted with a vector so does not know what its result is (it does not know the result could be a CellVariable), although it still has a compatible shape. For right or wrong, I beleive we made a decision that only CellVariable types can be added to equations (Jon can confirm this). I think it substantially tidied up the code. Jon, Are the above statements correct? The other feature we need to get in is the ability to solve vector equations. This will automatically deal with all the vector scaler stuff, which is just a nuisance in 1D. > > regards, > > dean > > ---------------------------------------------------------- > > > > #fipy convterm var u > #need fipy >=v2.0 for "rank" attrib > u = CellVariable(name="u", mesh=mesh, value=0.5*u0, hasOld=1, rank=1) > #depvar ux > ux = CellVariable(name="ux", mesh=mesh, value=0.5*u0, hasOld=1, rank=0) > #fake var to test source > sv = CellVariable(name="sv", mesh=mesh, value=0.01*u0, hasOld=1, rank=0) > # > # the src term is analogous to that in the stokes eqns (user manual [v1.2] > chap. 12.1) > # intended to be a cell (rather than face) value, as per chap 6.6. > eqsrc = sv.getGrad().dot([1,]) > #(note: above line throws a "...ValueError'>: invalid return array shape" at > sweep). > eqn = TransientTerm() + VanLeerConvectionTerm(coeff=c+0.5*b*u) - \ > ImplicitDiffusionTerm(coeff=mu) + eqsrc > ... > for sweep in range(sweeps): > u[0] = ux > resid = eqn.sweep(var = ux, dt = dt, > solver = LinearLUSolver(),boundaryConditions=BC) > > > > -- Daniel Wheeler
