Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Roy Stogner <roystgnr@ic...> - 2006-06-09 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 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
steady-state and Euler (theta method) solvers takes a couple lines of
code, and if anyone wants to implement adaptive Euler, Implicit
Runge-Kutta, 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 cut-and-paste of the quasi-Newton 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 non-active 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 non-time-derivative
(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. physics-aware error
indicators) possible, make some (e.g. multigrid solvers) easier, and
make some (e.g. dial-an-operator) more efficient.
Even when analytic jacobians are provided, assembling time-dependent
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 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.