On Tue, May 1, 2012 at 8:38 PM, Yun Tao <[email protected]> wrote: > Hi dear fellow FiPy users! > > Recently I came across a discussion from 2 years ago: > http://groups.google.com/group/femhub/browse_thread/thread/92fe3954c1708851?pli=1 > The original poster was baffled by the qualitatively differential solutions > to the advection-diffusion equation under different convection terms. These > being the equations that prompted me to learn FiPy, I went ahead and > reproduced their scripts (see attachments) under Fipy version 2.2. My > observations are the following: > > 1. Missing from the attached script is the VanLeerConvectionTerm (2nd order > of accuracy). It breaks completely with a Type Error (see attachment).
This breaks on trunk, but runs with version 2.1.3. Actually, looking at the problem, the VanLeerConvectionTerm is an explicit convection term so does not make any sense at all in an equation without a TransientTerm so you need to add a TransientTerm to the equation and have a cfl less than 1. This works with version 2.1.3, but the result is baloney since there is no transient term. Sorry about the rather cryptic error message, I'll fix that on trunk so that it fails if the equation doesn't have a time step. Trunk no longer has s default time step when the transient term is not defined hence the failure on trunk. When the transient term is defined the time step must be specified. > > 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) > The original posters told me through personal > communication that they eventually resolved the issue by adopting their own > software Hemes. However, I'm wondering whether the current release of FiPy > can still be configured to reliably solve time-dependent problems. Why are you solving a time independent problem for your test case when you're interest is transient problems. > 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? Doesn't seem to do that for me. This could be caused by your matplotlib setup. If you plot twice after the solve step do you get the correct image? > Thank you all for your patience and kind assistance! No problem -- Daniel Wheeler _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
