Hello,

First, thank you for an outstanding finite element library.  I have only
been using deal.II for a couple of months, but am thoroughly impressed
with its capabilities.  In particular, a literature study in my problem
area described Nédélec and Raviart-Thomas elements, which I thought I
would need to implement -- but deal.II already has them!

I was so impressed, I made and uploaded a Debian package, so although it
won't make the lenny release, deal.II is likely to be part of squeeze
(planned Debian 6.0 release someday after lenny).  It's been in the NEW
queue for over a month, hopefully it will get in soon...

I have three questions and one issue:

First, I'm wondering if the DoF mapping in deal.II is flexible enough to
handle different variables, or different numbers of variables, in
different elements.  For example, if one region has elastic deformation
and the other has Navier-Stokes flow, then the latter will need a field
for pressure while the former won't.

Is this currently possible in deal.II?

Second, what is the advantage to using deal.II "native" solvers vs.
PETSc solvers?  One disadvantage I've noticed is that there doesn't seem
to be an option to printing the residual during solution, equivalent to
PETSc's -ksp_monitor command-line option -- or am I missing something?

Third, the Debian PETSc package includes wrappers for UMFPack/AMD,
SuperLU and SPOOLES solvers and hypre preconditioners.  Are there any
plans to wrap the relevant PETSc interfaces to take advantage of those
PETSc features?

As for the one issue, see the attached tiny patch against 6.1.0 which
fixes documentation bugs (may be obsolete for 6.2 pre).  The Debian
package also includes patches for:
      * Using the METIS compatibility layer of Scotch (I think linking
        with METIS itself may violate the QPL, unless there's an
        exception I didn't see)
      * Eliminating rpath which is unnecessary if libs are in /usr/lib
      * Shared library versioning
      * Relocating from the build directory to the install directory (a
        bit of a hack, not clean enough to be useful to upstream)
      * Using the Debian UMFPack package properly

If any of these interest you, see the .diff.gz files in
http://lyre.mit.edu/~powell/deal.ii/ - these are in debian/patches.
(Everything there is signed by my key which is in the Debian keyring for
verification.)

Many thanks again,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
--- deal.ii-6.1.0/doc/doxygen/options.dox.in~	2008-01-15 19:48:26.000000000 -0500
+++ deal.ii-6.1.0/doc/doxygen/options.dox.in	2008-09-10 19:08:39.000000000 -0400
@@ -770,7 +770,7 @@
 # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
 # packages that should be included in the LaTeX output.
 
-EXTRA_PACKAGES         = 
+EXTRA_PACKAGES         = amsmath
 
 # The LATEX_HEADER tag can be used to specify a personal LaTeX header for 
 # the generated latex document. The header should contain everything until 
--- deal.ii-6.1.0/examples/step-33/doc/intro.dox~	2008-05-23 13:04:06.000000000 +0000
+++ deal.ii-6.1.0/examples/step-33/doc/intro.dox	2008-09-11 00:10:15.000000000 +0000
@@ -168,7 +168,7 @@
 Newton iteration, i.e. by iterating
 @f{eqnarray*}
 R'(\mathbf{W}^k,\delta \mathbf{W})(\mathbf z) & = & -
-R(\mathbf{W}^{k})(\mathbf z) \qquad \qquad \forall \mathbg z\in V_h \\
+R(\mathbf{W}^{k})(\mathbf z) \qquad \qquad \forall \mathbf z\in V_h \\
 \mathbf{W}^{k+1} &=& \mathbf{W}^k + \delta \mathbf{W},
 @f}
 until $|R(\mathbf{W}^k)|$ (the residual) is sufficiently small. By

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________

Reply via email to