From: Roy Stogner <roystgnr@ic...>  20060609 17:13:10

In case anyone's been wondering about the dozen or so files I've committed recently: there's now an "example 18" which uses them all to solve the problem from example 13. The good: The time stepping scheme is now factored out of the problem and included in the library. This makes writing the weak form of your equations a little simpler and a lot more flexible. Switching between steadystate and Euler (theta method) solvers takes a couple lines of code, and if anyone wants to implement adaptive Euler, Implicit RungeKutta, Adams Moulton, or whatever, it will become just as easy to switch to that without changing the user's assembly routines. The nonlinear solver is now factored out of the problem and included in the library. Currently the default (and only) solver is a badly trimmed cutandpaste of the quasiNewton I've been using privately, but it should now be easy to write better implementations or to link to PETSC's nonlinear solvers. The FEM assembly routine is now factored out of the problem and included in the library. In addition to shortening the code and preventing a few common (looping over nonactive elements, anyone?) errors, this means that we now can numerically differentiate element Jacobians; FEMSystem options are present to use numerical Jacobians either in place of or to verify analytic ones. The library now has access to time derivative and nontimederivative (which I've been calling "constraint" because I can't think of a less confusing name...) weak formulations on each element and on each side. This should make some good future ideas (e.g. physicsaware error indicators) possible, make some (e.g. multigrid solvers) easier, and make some (e.g. dialanoperator) more efficient. The bad: Even when analytic jacobians are provided, assembling timedependent problems may take longer this way, because there's no avoiding a half dozen more virtual function calls and one or two more qp/i/j loops per element/side. I'm not seeing any practical difference, though. Using this system requires deriving your own subclass. Although we could still hack together four or five APIs to allow programmers uncomfortable with OOP to attach_whatever(function), in my opinion it's reasonable to require users of a C++ library to know C++. There are still a few bugs and few bad design decisions that I'm trying to fix; ex18 appears to give good results but is still slower than it should be. The ugly: The design isn't yet set in stone, nor should it be; there are several aesthetic design flaws that may turn out to cause real problems after further experimentation. Some of these flaws may be necessary for efficiency's sake; one of the few optimizations I have made early is to try to make sure FE::reinit never gets called redundantly. The input and output from the user's element_time_derivative() and related functions are done on FEMSystem member variables, not on function arguments. Using member variables isn't any less safe and it's occasionally more efficient, but it makes some of the library code look convoluted  see euler_solver.C for a prime example.  Roy Stogner 