On May 2, 2012, at 11:35 AM, Daniel Wheeler wrote: > On Tue, May 1, 2012 at 8:38 PM, Yun Tao <[email protected]> wrote:
>> 2. Out of the other six, the Central Different Convection Term appears to >> partially fail with the following message: >>> >>> MaximumIterationWarning: Iterations: 1001. Relative error: 1.61715 > > Try switching the solver to LU "solver=LinearLUSolver()" in the solve > arguments. You're at a Peclet number above 2 so Central Difference > will break down. > >> 3. Explicit Upwind produces something vastly different from the rest while >> the regular Upwind generates something much closer. > > As I said, explicit is nonsense without a sensible time step. > >> These results make me worry about the package's numerical accuracy, >> especially as I'm more interested in the transient, rather than >> steady-state, solutions. > > They are all known issues for those particular first order schemes. > First order schemes are good because they are completely implicit and > so you can use large time steps when spatial accuracy is less of a > consideration. Often when you just want to see the trends of a problem > and can't solve with small time steps and when you > are not solving interface tracking problems but smooth fields. For > high accuracy you are restricted by the cfl (at least fot finite > volume) Just to clarify what Daniel is saying, CentralDifference assumes that the problem is diffusion dominated (Peclet is small), whereas Upwind assumes that the problem is convection dominated (Peclet is large). The parameters you have are neither large nor small so neither scheme does very well. Exponential, Hybrid, and PowerLaw all interpolate between CentralDifference and Upwind depending on the Peclet number, so all do OK for this problem. Explicit and VanLeer just don't make sense for a steady-state problem. >> On a more trivial note, as seen in adv-dif_fipyQ.py, the placement of the >> solvers setup relative to the viewers setup (# PRE-solver vs. # >> POST-solver) changes the presentation of the graphical outputs, although the >> numerical solutions remain the same. Is there then an optimal way to >> illustrate the results? Either call viewer.plot() after creating the viewer to provoke auto-scaling (which is what's happening in your POST case) or explicitly set datamin and datamax when you create the viewers. _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
