--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
+ "http://www.w3.org/TR/REC-html40/frameset.dtd">
+<html>
+ <head>
+ <link href="../../screen.css" rel="StyleSheet" media="screen">
+ <link href="../../print.css" rel="StyleSheet" media="print">
+ <title>The deal.II news page</title>
+ <meta name="author" content="the deal.II authors <authors@dealii.org>">
+ <meta name="keywords" content="deal.II"></head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<body>
+
+
+<h2>Changes after Version 3.4</h2>
+
+<p>
+This is the list of changes made after the release of
+<acronym>deal.II</acronym> version 3.4. It is subdivided into changes
+made to the three sub-libraries <a href="#base">base</a>,
+<a href="#lac">lac</a>, and <a href="#deal.II">deal.II</a>, as well as
+changes to the <a href="#general">general infrastructure,
+documentation, etc</a>.
+</p>
+
+<p>
+All entries are signed with the names of the author. Regular
+contributor's names are abbreviated by WB (Wolfgang Bangerth), GK
+(Guido Kanschat), RH (Ralf Hartmann).
+</p>
+
+
+<a name="general"></a>
+<h3>General</h3>
+
+<ol>
+ <li> <p>
+ New: <acronym>deal.II</acronym> now uses a new threading
+ scheme. The new scheme is simpler to use, and in particular
+ more flexible in some cases where only one thread is started,
+ or where a thread is completely detached, since we got rid of
+ the <code>ThreadManager</code> class and now only store handles
+ to individual threads (which can be discarded, or added to a
+ <code>ThreadGroup</code> variable that is able to wait for a
+ whole set of threads at once.
+ <br>
+ The new scheme also implements a much needed feature: calling
+ functions on a new thread that return values. Previously, such
+ functions needed to be written in a way that they return their
+ return value through an additional reference parameter. This
+ was inflexible if one wanted to call functions that already
+ exist. This restriction is now lifted: such functions can be
+ called, and the return value can be accessed once the thread
+ has finished.
+ <br>
+ Some documentation for the new scheme can be found
+ <a href="../../reports/new-threads/index.html" target="body">on this
+ page</a>.
+ <br>
+ (WB 2003/02/06)
+ </p>
+
+ <li> <p>
+ New: <acronym>deal.II</acronym> now makes use of some parts of
+ the <a href="http://www.boost.org/">boost</a> library, which is
+ supposed to be a testground for the next generation C++ standard
+ library. The parts which we use are now in
+ <code>contrib/boost/include/boost_local/</code> and can be
+ referenced from within your programs. The directory contains
+ the string <code>_local</code> since you may still want to use
+ another version or installation of boost in your own programs.
+ </p>
+
+ <p>
+ Also note that boost is large -- much larger than the subset we
+ have imported --, so we only took what we needed.
+ <br>
+ (WB 2003/02/06)
+ </p>
+
+ <li> <p>
+ Fixed: A longstanding bug in the documentation system has been fixed: if
+ a namespace was ended with <code>}</code> instead of <code>};</code>
+ (note the semicolon), then the documentation tool assumed that the
+ following entities were still part of the namespace just left. This was
+ since the closing brace alone was not accepted as ending a namespace
+ (after all, structures, classes, and enums -- the other entities that
+ can enclose other declarations -- need the semicolon). This led to some
+ classes not showing up in the class index of the sublibraries. This is
+ now fixed.
+ <br>
+ (WB 2003/02/02)
+ </p>
+
+ <li> <p>
+ Changed: Classes and structures that are declared inside namespaces named
+ <code class="class">internal</code> are now no longer shown in the class
+ index view of the documentation of each of the sublibraries. Since they
+ are supposed to be used internally only, this is no drawback for the
+ general public. However, they are documented as members of these
+ namespaces.
+ <br>
+ (WB 2003/02/02)
+ </p>
+
+ <li> <p>
+ Fixed: Some of the formulas in the step-14 tutorial were obviously
+ scrambled a little. This is now fixed.
+ <br>
+ (Roy Stogner, WB 2003/01/30)
+ </p>
+
+ <li> <p>
+ Changed: The main Makefile has been changed to sequentialize building
+ the base, lac, and deal.II sublibraries. We changed this, since on some
+ systems (notably AIX), the latter libraries need to be linked against
+ the former ones, when creating shared libraries.
+ <br>
+ (WB 2003/01/24)
+ </p>
+
+ <li> <p>
+ New: Changes have been made to support compiling and using
+ <acronym>deal.II</acronym> on AIX 5 systems.
+ <br>
+ (WB 2003/01/24)
+ </p>
+
+ <li> <p>
+ Removed: Thread support now relies solely on the use of POSIX
+ functions. The use of the
+ <a href="http://www.cs.wustl.edu/~schmidt/ACE.html" target="_top">ACE
+ (Adaptive Communications Environment)</a> library for this is now no
+ longer supported. However, application programs can of course still use
+ ACE, but they will need to generate paths to this library in their
+ makefiles themselves.
+ <br>
+ (WB 2003/01/11)
+ </p>
+
+ <li> <p>
+ New: Some changes have been made to support Mac OS X 10.2. Shared
+ libraries are not supported on this architecture, but everything else
+ should work.
+ <br>
+ (WB 2002/12/18)
+ </p>
+
+ <li> <p>
+ New: <acronym>deal.II</acronym> can be compiled with version 7.0 of
+ Intel's icc compiler, which was recently released. Since this compiler
+ finally supports the very restrictive flags <code>-Xc -ansi</code> that
+ check for close conformance with the C++ standard, we use them (previous
+ versions of icc would crash when these two flags are given). This
+ requires that we distinguish between these compiler versions, and the
+ corresponding Makefile variable <code>GXX-VERSION</code> now no longer
+ holds the non-versioned string <code>intel_icc</code> when icc is
+ detected, but rather either <code>intel_icc5</code>,
+ <code>intel_icc6</code>, or <code>intel_icc7</code>, depending on what
+ version of the compiler was detected.
+ <br>
+ (WB 2002/12/05)
+ </p>
+
+ <li> <p>
+ Changed: Previously, we just set the preprocessor variable
+ <code>DEAL_II_USE_MT</code>, when <code>--with-multithreading</code> was
+ given as argument to <code>./configure</code>. Tests in the code
+ therefore looked like <code>#ifdef DEAL_II_USE_MT</code>. This has been
+ changed so that the variable is always defined, but its value is now
+ equal to <code>1</code>
+ when multithreading was requested, and zero otherwise. The reason for
+ this is that you can now write <code>if (DEAL_II_USE_MT && ...)</code>
+ conditions, and need not interleave if-else clauses from regular code
+ and the preprocessor, if conditions involve both the state of this
+ preprocessor variable and the run-time state of your program. However,
+ this change requires that all appearances of <code>#ifdef
+ DEAL_II_USE_MT</code> be changed to <code>#if DEAL_II_USE_MT ==
+ 1</code>, since the variable is now defined unconditionally.
+ <br>
+ (WB 2002/11/14)
+ </p>
+
+ <li> <p>
+ New: Object files are now named according to the local defaults
+ on the system we are running on. On Unix systems, this is
+ usually a <code>.o</code> suffix, while on Windows it is
+ <code>.obj</code>. Likewise for executables, which have no
+ suffix on Unix, but <code>.exe</code> on Windows.
+ <br>
+ (WB 2002/11/11)
+ </p>
+
+ <li> <p>
+ New: <acronym>deal.II</acronym> can now also be compiled with Red Hat's
+ version of the gcc compiler, gcc 2.96. However, some problems remain;
+ for more information, refer
+ to the <a href="../../faq.html" target="body">Frequently Asked
+ Questions</a> section.
+ <br>
+ (WB 2002/10/14)
+ </p>
+
+ <li> <p>
+ Fixed: On CygWin, one header files has a <code>#define quad
+ quad_t</code>. This is annoying, since we have local variables and
+ member functions with the name <code>quad</code>, and in fact it breaks
+ compilation on those versions of CygWin that has this. Fortunately, the
+ define is only active if a preprocessor variable
+ <code>_POSIX_SOURCE</code> is not set. Thus, we now check for the define
+ when configuring the library, and if necessary set the preprocessor
+ variable. However, while this allows to compile the library on these
+ systems, it may otherwise affect your code, if you use functions or
+ other features of the system that are not available when the flag is
+ set.
+ <br>
+ (Stephen Kolaroff, WB
+ 2002/09/28)
+ </p>
+
+ <li> <p>
+ New: Since <code>math.h</code> only defines the values of PI or E (as
+ <code>M_PI</code> and <code>M_E</code>) when certain defines are set (on
+ Linux, these are <code>__USE_BSD</code> or <code>__USE_XOPEN</code>),
+ portable programs usually defined these constants themselves. In
+ <acronym>deal.II</acronym>, this happened at 6 different places. To
+ avoid this in the future, <code>base/config.h</code> now exports a
+ namespace <code>deal_II_numbers</code> that defines these two, and a
+ number of other numerical constants.
+ <br>
+ (WB 2002/09/12)
+ </p>
+
+ <li> <p>
+ New: <code>base/config.h</code> now exports the
+ <acronym>deal.II</acronym> base directory through the
+ <code>DEAL_II_PATH</code> preprocessor variable.
+ <br>
+ (WB 2002/09/09)
+ </p>
+
+ <li> <p>
+ Removed: The forward declarations files have gone. We have never
+ propagated their use in the example programs, but these files have been
+ there in the base, lac, and grid include directories, and forward
+ declared all classes that were present in the respective parts of the
+ library. This, the idea was, enables you to use just this include file
+ in your own header files, rather than including the full declarations of
+ these classes. However, maintaining these forward declaration files has
+ been a constant thorn in our side, be it that the timing of their
+ generation was difficult when using parallel builds, or that they were
+ difficult to generate at first. The latter is now the reason for their
+ abolition: we had a script for their generation, but it did not take
+ into account namespaces, so we got clashes when we found that we had
+ used the same class name in two different namespaces, since the script
+ put the forward declaration incorrectly into the global namespace where
+ they conflicted. Since we do not plan to extend the script by a
+ parser that can properly handle opening and closing braces of
+ namespaces, we simply drop these files.
+ <br>
+ What you should do if you have used these forward declaration files: you
+ have two possibilities - either include the respective header file in
+ which the class is fully declared, or write the forward declaration into
+ your headers yourself.
+ <br>
+ (WB 2002/09/05)
+ </p>
+
+ <li> <p>
+ New: There is now
+ <a href="../../reports/assemble/index.html" target="body">a new report
+ on assembling matrices</a> available from the
+ <a href="../../documentation.html" target="body">documentation
+ page</a>. The main focus is assembling of matrices for
+ vector-valued problems, where shape functions are
+ vector-valued, and may have only one or more non-zero vector
+ components.
+ <br>
+ (WB 2002/06/17)
+ </p>
+
+ <li> <p>
+ Removed: The functions <code
+ class="member">FEValuesBase::get_shape_values</code>, <code
+ class="member">FEValuesBase::get_shape_grads</code>, and <code
+ class="member">FEValuesBase::get_shape_2nd_derivatives</code> are
+ now removed as they expose too much of the internal data
+ structure of their class, and interfere with plans for the
+ extension of this and related classes. These functions, which
+ had been deprecated in the previous version, are thus not
+ part of the release after version 3.4 any more. Use the <code
+ class="member">FEValuesBase::shape_value</code> and alike
+ functions as a replacement.
+ <br>
+ For more information, read
+ <a href="http://www.dealii.org/mail/msg00638.html" target="body">this mail</a>.
+ <br>
+ (WB 2002/06/10)
+ </p>
+
+ <li> <p>
+ New: <acronym>deal.II</acronym> now also supports vector-valued
+ finite elements with shape functions for which more than just
+ one vector component is non-zero. Such elements are, for
+ example, the Nedelec and Raviart-Thomas families. Previously,
+ vector-valued elements were only supported insofar as they
+ could be composed of scalar ones; in that case, each
+ (vector-valued) shape function had only one non-zero vector
+ component.
+ <br>
+ (WB 2002/06/10)
+ </p>
+
+ <li> <p>
+ New: The top-level makefile now how a target <tt>distclean</tt>.
+ <tt>clean</tt> leaves the libraries now, removing
+ everything that is not needed to use
+ <acronym>deal.II</acronym>. <tt>distclean</tt> removes even the
+ libraries, leaving the directory more or less in the state like
+ after <tt>configure</tt>.
+ <br>
+ (GK 2002/06/07)
+</ol>
+
+
+
+<a name="base"></a>
+<h3>base</h3>
+
+<ol>
+ <li> <p>
+ Fixed: A bug in the <code
+ class="class">Patterns::MultipleSelection</code> class if more
+ than two elements in a comma-separated list were given.
+ <br>
+ (Brian Carnes 2003/05/14)
+ </p>
+
+ <li> <p>
+ Changed: The <code class="class">Polynomials::Legendre</code>
+ class lost its template argument and is now just a regular
+ class. There was no real good reason for the template argument,
+ it had just crept in.
+ <br>
+ (WB 2003/05/12)
+ </p>
+
+ <li> <p>
+ New: There is now a class <code
+ class="class">AnisotropicPolynomials</code> that constructs a higher
+ dimensional polynomial space from a set of 1-d polynomials in each of
+ the coordinate directions.
+ <br>
+ (WB 2003/04/20)
+ </p>
+
+ <li> <p>
+ Changed: The <code class="class">Table</code> accessor classes
+ have been moved to a namespace <code
+ class="class">internal</code>. Since these classes are not (or should
+ not be) used directly in applications, this should not change
+ compatibility. However, they will now no longer show up in the class
+ overview of the documentation, which they were cluttering up.
+ <br>
+ (WB 2003/02/13)
+ </p>
+
+ <li> <p>
+ New: The <code class="class">Function</code> class now has an assignment
+ operator. This way, you can put function objects into
+ containers. However, the assignment operator makes sure that only
+ objects can be assigned that have the same number of vector components.
+ <br>
+ (WB 2003/02/06)
+ </p>
+
+ <li> <p>
+ New: The <code class="class">ThreadMutex</code> classes now have a
+ member class <code class="class">ScopedLock</code> that implements the
+ scoped thread-safe locking pattern of Doug Schmidt. It is also used in
+ various places of the code now.
+ <br>
+ (WB 2003/01/28)
+ </p>
+
+ <li> <p>
+ Fixed: The <code class="class">PosixThreadManager</code> called
+ its <code class="member">wait</code> function in the
+ destructor. If this had been called before already, then the
+ same threads would have been waited for twice, which invokes
+ undefined behavior. This is fixed by making sure that <code
+ class="member">wait</code> removes the id's of the threads it
+ has already waited for, and so calling it more than once will
+ not wait for threads which have already been waited for.
+ <br>
+ (Michael Anderson, WB 2003/01/16)
+ </p>
+
+ <li> <p>
+ Fixed: The <code class="class">Subscriptor</code> uses a counter to
+ count how many <code class="class">SmartPointer</code> objects subscribe
+ to the pointed-to object. This counter needs to be a volatile variable
+ in multithreaded mode, to avoid false compiler optimizations based on
+ the assumption that the variable cannot change between two subsequent
+ reads.
+ <br>
+ (WB 2003/01/11)
+ </p>
+
+ <li> <p>
+ Fixed: In multithreaded mode, when a new thread is started, the
+ arguments to the function being called need to be copied from the stack
+ of the starting thread to that of the new thread. In order to
+ synchronise this, mutexes were used that were acquired from one thread
+ and released from another thread. On Linux this does not lead to
+ problems, but POSIX functions do not guarantee that this actually works,
+ and it also leads to problems when running programs under valgrind. This
+ is now fixed with the help of condition variables.
+ <br>
+ (Michael Anderson, WB 2003/01/11)
+ </p>
+
+ <li> <p>
+ New: There are now classes <code class="class">ThreadCondition</code>
+ that implement thread condition variable operations through POSIX
+ functions (in multithreaded mode) or doing nothing (in singlethreaded
+ mode).
+ <br>
+ (WB 2003/01/11)
+ </p>
+
+ <li> <p>
+ New: Newer versions of gcc have a very nice feature: you can set
+ a verbose terminate handler, that not only aborts a program
+ when an exception is thrown and not caught somewhere, but
+ before aborting it prints that an exception has been thrown,
+ and possibly what the std::exception::what() function has to
+ say. Since many people run into the trap of not having a
+ catch clause in main(), they wonder where that abort may be
+ coming from. The terminate handler then at least says what is
+ missing in their program.
+ <br>
+ (WB 2002/12/19)
+ </p>
+
+ <li> <p>
+ New: There is now a <code class="class">Patterns::List</code> pattern
+ that matches a list of elements each of which has to satisfy a pattern
+ that was given to the constructor.
+ <br>
+ (WB 2002/11/29)
+ </p>
+
+ <li> <p>
+ Changed: In POSIX mode, when the <code
+ class="member">ThreadManager</code> class created a new thread through
+ <code class="member">pthread_create</code>, it only checked for the
+ error code and aborted if it was non-zero. Now, it checks whether the
+ error code is <code class="member">EAGAIN</code> and simply retries the
+ call if this is the case. This may, in rare cases, lead to a deadlock or
+ an infinite loop, but will usually just wait until the respective
+ resources for thread creation are available from the operating system
+ and will then succeed.
+ <br>
+ (WB 2002/11/13)
+ </p>
+
+ <li> <p>
+ Fixed: The <code class="member">write_text</code> and <code
+ class="member">write_tex</code> functions of the <code
+ class="class">TableHandler</code> class now check whether their
+ <code>ofstream</code> arguments are in a proper state before
+ using them for output.
+ <br>
+ (RH 2002/11/11)
+ </p>
+
+ <li> <p>
+ New: Added Hierarchical Polynomial (similar to Legendre class). Will
+ eventually be used in a hierarchical FiniteElement class similar to
+ FE_Q class. Included in Polynomials namespace.
+ <br>
+ (Brian Carnes 2002/10/15)
+ </p>
+
+ <li> <p> Changed: Because they became too many, the classes describing 1d
+ polynomials are now in a <code class="class">namespace
+ Polynomials</code>.
+ <br>
+ (WB 2002/10/14)
+ </p>
+
+ <li> <p> Changed: When an exception is thrown but not caught in a sub-thread,
+ this exception is not passed to the main thread by the operating
+ system. Rather, if the exception is not caught from the function that
+ was invoked by the spawning system function, the entire program is
+ terminated without an additional message. The wrapper functions which
+ are used to spawn new threads in the <code class="class">Threads</code>
+ namespace therefore now catch these exceptions and at least print the
+ message they carry, before aborting the program. This way, at least the
+ message gets displayed.
+ <br>
+ (WB 2002/10/13)
+ </p>
+
+ <li> <p> Changed: The class <code
+ class="member">Table<2>::fill</code> function, which is also
+ inherited from the <code class="class">FullMatrix</code> class, used to
+ work also when the size of the matrix was zero, by simply not copying
+ something. This led to difficult to detect errors. It is therefore no
+ more allowed to call this function when the matrix is empty. For all
+ other cases, the status of copying without checking the size of the
+ array copied from remains unchanged.
+ <br>
+ (WB 2002/09/28)
+ </p>
+
+ <li> <p> New: The classes <code
+ class="class">TableIndices<N></code> and <code
+ class="class">Table<N,T></code> are now implemented also
+ for <code>N=4,5</code> and <code>6</code>. The <code
+ class="class">Table<N,T></code> class represents an
+ <code>N</code>-dimensional array and might replace the
+ N-times-nested-use of the <code
+ class="class">std::vector</code> class.
+ <br>
+ (RH 2002/09/24)
+ </p>
+
+ <li> <p>
+ New: The <code class="member">Threads::n_existing_threads</code>
+ function returns the present number of existing threads, allowing an
+ assessment whether it is useful to spawn new threads or rather perform
+ the operation in question sequentially.
+ <br>
+ (WB 2002/09/08)
+ </p>
+
+ <li> <p> New: Global exception class <code
+ class="class">ExcIteratorPastEnd</code>, which should be used if an
+ iterator is incremented or decremented beyond its end value.
+ <br>
+ (GK 2002/09/08)
+ </p>
+
+ <li> <p>
+ Extended: Previously, the <code
+ class="class">Threads::PosixThreadBarrier</code>
+ class could not be used at all (they threw exceptions), if your system
+ did not have the respective POSIX functions. This restriction is lifted
+ for the special case that you give one as the number of parties that
+ will be waiting for the barrier: in this case, a barrier is a
+ no-operation, so we do not need assistence from the operating
+ system. This change makes it slightly simpler to write programs in a way
+ such that they run in both single- and multithreaded environments.
+ <br>
+ (WB 2002/09/05)
+ </p>
+
+ <li> <p>
+ New: The old class <code class="class">vector2d</code>, implementing a
+ two-dimensional array of objects is now gone. Instead, there is the new
+ <code class="class">Table</code> class that implements tables of
+ arbitrary dimension. Transition is painless: where there was
+ <code>vector2d<type></code> before, use
+ <code>Table<2,type></code> now (and don't forget to update the
+ name of the header file, of course). If you have a three-dimensional
+ array, you can use <code class="class">Table<3,type></code> now.
+ <br>
+ (WB 2002/09/03)
+ </p>
+
+ <li> <p>
+ New: There are now functions returning the transpose of <code
+ class="class">Tensor</code> objects of rank 2.
+ <br>
+ (WB 2002/08/31)
+ </p>
+
+ <li> <p>
+ New: Row accessors for the <code class="class">vector2d</code>
+ class now have a member function <code
+ class="member">size</code> that returns the size of the row,
+ i.e. the number of columns of the table.
+ <br>
+ (WB 2002/07/24)
+ </p>
+
+ <li> <p>
+ Fixed: In EPS output, colors were set to invalid values if the
+ values of the field that is used for coloring are all
+ equal. This happens, for example, in the very first time step
+ of time dependent problems, if initial values are zero. The
+ color value now used is arbitrary, but valid.
+ <br>
+ (WB 2002/07/24)
+ </p>
+
+ <li> <p>
+ Changed: To save disk space, color values in EPS output are
+ written as grey scale with only one value instead of three RGB
+ values if the color so represented is actually a grey scale.
+ <br>
+ (WB 2002/07/24)
+ </p>
+
+ <li> <p>
+ New: There are now operators to allow multiplication and
+ division of <code class="class">Tensor</code> objects by scalar
+ factors.
+ <br>
+ (WB 2002/06/07)
+ </p>
+</ol>
+
+
+
+<a name="lac"></a>
+<h3>lac</h3>
+
+<ol>
+ <li> <p> New: Function
+ <code class="member">BlockSparseMatrix::print_formatted</code>
+ added, similar to the
+ <code class="member">BlockVector::print_formatted</code> function.
+ <br>
+ (Brian Carnes 2003/06/02)
+ </p>
+
+ <li> <p> New: Functions <code class="member">SparseMatrix::operator *=</code>
+ and <code class="member">SparseMatrix::operator /=</code> as well as
+ <code class="member">BlockSparseMatrix::operator *=</code>
+ and <code class="member">BlockSparseMatrix::operator /=</code>
+ are added.
+ <br>
+ (Brian Carnes 2003/06/02)
+ </p>
+
+ <li> <p> Deprecated: The functions <code class="member">Vector::scale</code>
+ and <code class="member">BlockVector::scale</code> are now deprecated
+ and will be removed in a future version. Use <code>operator*=</code> and
+ <code>operator/=</code> instead.
+ <br>
+ (WB 2003/05/31)
+ </p>
+
+ <li> <p> New: <code class="class">Vector</code>, <code
+ class="class">BlockVector</code> and
+ <code class="class">FullMatrix</code> now have <code>operator/=</code>
+ for scaling by a scalar.
+ <br>
+ (WB 2003/05/31)
+ </p>
+
+ <li> <p> New: <code class="class">PointerMatrix</code> now
+ has <code>empty()</code> function, which returns true if the pointer is
+ null; otherwise we call the pointer's <code>empty()</code> function.
+ This requires the class MATRIX to have an <code>empty()</code>
+ function.
+ <br>
+ (Brian Carnes 2003/05/22)
+ </p>
+
+ <li> <p> New: <code class="class">SparseLUDecomposition</code> now
+ has <code>empty()</code> function, which calls the inherited <code
+ class="class">SparseMatrix</code> <code>empty()</code> function.
+ <br>
+ (Brian Carnes 2003/05/22)
+ </p>
+
+ <li> <p> New: <code class="class">PreconditionPSOR</code> implements
+ interface to permuted SOR preconditioner function in <code
+ class="class">SparseMatrix</code>.
+ <br>
+ (GK 2003/05/12)
+ </p>
+
+ <li> <p> Improved: <code class="class">FullMatrix</code>::<code
+ class="member">fill</code> now copies the largest possible block,
+ whether the destination or source matrix is bigger. Additionally, an
+ offset inside the source matrix may be specified.
+ <br>
+ (GK 2003/03/31)
+ </p>
+
+ <li> <p>
+ New/Changed: The <code class="class">SparseILU</code>, <code
+ class="class">SparseMIC</code> and <code
+ class="class">SparseLUDecomposition</code> now use the same
+ interface (<code class="class">initialize</code>, <code
+ class="class">vmult</code>, <code class="class">clear</code>)
+ as all <code class="class">PreconditionBlock</code> classes. In
+ virtue of an unified preconditioner interface it is now
+ recommended to use the new methods. The old methods (<code
+ class="class">reinit</code>, <code
+ class="class">decompose</code>, <code
+ class="class">apply_decomposition</code>) are now deprecated,
+ and will be removed in a later version.
+ <br>
+ (RH 2003/02/19)
+ </p>
+
+ <li> <p>
+ Changed: The <code class="class">BlockVector</code> accessor classes
+ have been moved to a namespace <code
+ class="class">internal</code>. Since these classes are not (or should
+ not be) used directly in applications, this should not change
+ compatibility. However, they will now no longer show up in the class
+ overview of the documentation, which they were cluttering up.
+ <br>
+ (WB 2003/02/13)
+ </p>
+
+ <li> <p>
+ New: The <code class="class">SolverGMRES</code> now accepts an
+ <code class="class">AdditionalData</code> parameter
+ <code>use_default_residual</code> whose default is
+ <code>true</code>. By setting this flag to <code>false</code>,
+ the stopping criterion of the left-preconditioned GMRes solver
+ is not the default preconditioned residual but the normal
+ (unpreconditioned) residual and visa versa for the
+ right-preconditioned GMRes solver. Due to a performance loss of
+ the solver this flag should be set to <code>false</code> only
+ for debugging/testing purposes.
+ <br>
+ (RH 2003/01/31)
+ </p>
+
+ <li> <p>
+ New: <code class="class">FullMatrix</code> has a function <code
+ class="member">copy_from</code>, copying from sparse matrices.
+ It uses iterators of the sparse matrix classes.
+ <br>
+ (GK 2003/01/08)
+ </p>
+
+
+ <li><p>
+ Changed: In an attempt to unify the use of preconditioners a
+ little, the function <code class="member">initialize</code> of
+ classes <code class="class">PreconditionRelaxation</code> and
+ <code class="class">PreconditionBlock</code> take an argument
+ of type <code class="class">AdditionalData</code>, defined in
+ the same class. Standard behavior of <code
+ class="class">PreconditionBlock</code> has been changed on this
+ occasion to invert diagonal blocks during initialization.
+ <br>
+ (GK 2003/01/06)
+ </p>
+
+ <li> <p>
+ New: The interface for sparse decompositions has been abstracted, and
+ there is now an Modified Incomplete Cholesky (MIC) decomposition in
+ addition to the Imcomplete LU (ILU) decomposition.
+ <br>
+ (Stephen Kolaroff 2002/11/27)
+ </p>
+
+ <li> <p>
+ Changed: In multithread mode, the <code
+ class="class">SparseMatrix</code> would spawn
+ <code>multithread_info.n_default_threads</code> threads to
+ perform matrix-vector multiplications and similar
+ operations. It would even do so if
+ <code>multithread_info.n_default_threads</code> was equal to
+ one. In that case, we now do the operation on the thread we are
+ presently on, eliminating the overhead of spawning a single
+ thread, and later waiting and terminating it.
+ <br>
+ (WB 2002/11/13)
+ </p>
+
+ <li> <p>
+ Fixed: In the <code class="class">SparseDirectMA27</code> class, wrapping
+ the MA27 solver written in Fortran77 into some structure amenable to C++,
+ we wrote beyond the end of an array on rare inputs. This is now fixed. The
+ same probably holds for the respective code for MA47.
+ <br>
+ (WB 2002/09/30)
+ </p>
+
+ <li> <p>
+ New: Since the MA27 sparse direct solver uses Fortran common blocks, it
+ was previously impossible to run several instances of this solver in
+ parallel, in a multihreaded environment. To solve this problem, the
+ <code class="class">SparseDirectMA27</code> class now has a detached
+ mode, in which it forks off a separate program that will do the
+ computations using this solver. The actual operations are therefore
+ distributed to distint programs that have separate address spaces. This
+ allows to have as many concurrent instances of this solver in parallel
+ as you want. For more information, read the documentation of the
+ <code class="class">SparseDirectMA27</code> class.
+ <br>
+ (WB 2002/09/25)
+ </p>
+
+ <li> <p> Changed: The classes <code
+ class="class">PreconditionBlock</code>, <code
+ class="class">PreconditionBlockJacobi</code>, <code
+ class="class">PreconditionBlockSOR</code>, and <code
+ class="class">PreconditionBlockSSOR</code> have changed their
+ template signature. The first template argument is now the matrix
+ type, not just a number type.
+ <br>
+ (GK 2002/09/18)
+ </p>
+
+ <li> <p> New: Class <code class="class">BlockVector</code> has a
+ function <code class="member">collect_sizes()</code>, very much as
+ <code class="class">BlockSparsityPattern</code>. This allows
+ updating internal structures after blocks have been resized.
+ <br>
+ (GK 2002/09/17)
+ </p>
+
+ <li> <p> New: Class <code class="class">SparseMatrix</code> has an
+ STL-conforming <code class="class">const_iterator</code> and
+ functions <code class="member">begin()</code> and <code
+ class="member">end()</code> for looping through all existing
+ entries. Furthermore, <code class="member">begin(row)</code> and
+ <code class="member">end(row)</code> allow looping through all
+ entries of a single line.
+ <br>
+ (GK 2002/09/11)
+ </p>
+
+ <li> <p>
+ New: Classes <code class="class">SparsityPattern</code> and <code
+ class="class">SparseMatrix</code> now have functions <code
+ class="member">block_write/block_read</code>, allowing to dump the data
+ of these objects into a file in binary format, and later to re-read it
+ without much need for parsing.
+ <br>
+ (WB 2002/09/09)
+ </p>
+
+ <li> <p>
+ New: <code class="class">Vector</code> has a function <code
+ class="member">lp_norm</code>, computing the <i>l<sub>p</sub></i>-norm
+ of a vector for arbitrary <i>p</i>.
+ <br>
+ (GK 2002/08/13)
+ </p>
+
+ <li> <p>
+ New: a way of using abstract base classes for matrices has
+ been implemented with <code class="class">PointerMatrixBase</code>
+ and <code class="class">PointerMatrix</code>. Storing a matrix in
+ <code class="class">PointerMatrix</code> allows to use the base
+ class in functions only templated for the vector class.
+ <br>
+ (GK 2002/07/18)
+ </p>
+</ol>
+
+
+
+<a name="deal.II"></a>
+<h3>deal.II</h3>
+
+<ol>
+ <li> <p>
+ Fixed: The restriction matrices for the Q1 element in 1d had a
+ trivial bug in that one element was not set. Due to the fact
+ that contributions from all child cells are taken into account,
+ this did no harm, though, since all computations were done
+ correctly anyway.
+ <br>
+ (WB 2003/05/06)
+ </p>
+
+ <li> <p>
+ New: The <code class="class">GeometryInfo</code> classes now
+ have new static member functions <code
+ class="member">child_cell_from_point</code> that, given a point
+ in the unit cell, returns which child cell it is on; <code
+ class="member">cell_to_child_coordinates</code> that transforms
+ coordinates between the unit coordinate systems from the mother
+ to the child cell; <code
+ class="member">child_to_cell_coordinates</code> that does
+ exactly the opposite; and <code
+ class="member">is_inside_unit_cell</code> that tells whether a
+ given point is inside the unit cell.
+ <br>
+ (WB 2003/05/01)
+ </p>
+
+ <li> <p>
+ New: There are now functions <code
+ class="member">recursively_set/clear_user_pointer</code> that
+ do much the same as <code
+ class="member">recursively_set/clear_user_flag</code> on a
+ line/quad/hex and all of its descendants, but on user pointers
+ rather than flags.
+ <br>
+ (WB 2003/04/11)
+ </p>
+
+ <li> <p>
+ New: The functions in the <code
+ class="class">DerivativeApproximation</code> class can now also
+ work on <code class="class">BlockVector</code>.
+ <br>
+ (WB 2003/04/11)
+ </p>
+
+ <li> <p>
+ Changed: The cell argument to <code
+ class="member">Mapping::transform_unit_to_real_cell</code> (and its
+ reverse function) is now passed by reference, rather than by value, for
+ efficiency reasons.
+ <br>
+ (WB 2003/04/06)
+ </p>
+
+ <li> <p>
+ New: The <code
+ class="member">GridGenerator::subdivided_hyper_cube</code> generated a
+ hypercube as coarse grid that is subdivided a given number of times.
+ <br>
+ (WB 2003/04/05)
+ </p>
+
+ <li> <p>
+ New: The <code class="member">DataOut_DoFData::merge_patches</code>
+ function allows to merge the patches of two objects, so as to create one
+ output file from several DoF handlers. This is useful if one uses a
+ domain decomposition algorithm where each block of the domain is
+ represented by one DoF handler.
+ <br>
+ (WB 2003/04/05)
+ </p>
+
+ <li> <p>
+ Fixed: The <code class="class">DataOutStack</code> class had a problem
+ when there were as many degrees of freedom as there were cells (i.e. if
+ we were using DG0 elements). This should now be fixed.
+ <br>
+ (WB 2003/03/02)
+ </p>
+
+ <li> <p>
+ Fixed: The <code class="class">DataOutFaces</code> class was
+ broken for cell data. It should now be correct, although the
+ algorithm used is not optimal, being approximately quadratic in
+ runtime.
+ <br>
+ (WB 2003/02/25)
+ </p>
+
+ <li> <p>
+ New: The <code class="member">ConstraintMatrix::shift</code>
+ function shifts and translates the elements of the constraint
+ matrix by a certain number of indices.
+ <br>
+ (Roy Stogner 2003/02/24)
+ </p>
+
+ <li> <p>
+ New: The <code class="class">GridReordering</code> class now uses a
+ vastly better algorithm in 2d than previously. The new algorithm is
+ linear in time, where it could be exponential before.
+ <br>
+ (Michael Anderson 2003/02/21)
+ </p>
+
+ <li> <p>
+ New: There is now a function <code
+ class="member">GridIn::read_xda</code> that allows reading
+ grids from a file in XDA format.
+ <br>
+ (WB 2003/02/21)
+ </p>
+
+ <li> <p>
+ Changed: Some implementation details of the <code
+ class="class">GridReordering</code> class have been moved to a
+ namespace <code class="class">internal</code>.
+ <br>
+ (WB 2003/02/19)
+ </p>
+
+ <li> <p>
+ New: There are now functions <code
+ class="member">FiniteElement::prolongation_is_implemented</code> and
+ <code class="member">FiniteElement::constraints_are_implemented</code>
+ that inform the caller about whether the finite element in question in
+ fact implements its prolongation matrices and hanging node constraints.
+ <br>
+ (WB 2003/02/15)
+ </p>
+
+ <li> <p>
+ Fixed: The <code
+ class="member">ConstraintMatrix::is_identity_constrained</code> function
+ would previously generate a segmentation fault if called on a constraint
+ matrix object that did not contain any constraints at all. This is now
+ fixed.
+ <br>
+ (WB 2003/02/15)
+ </p>
+
+ <li> <p>
+ Fixed: Objects of type <code class="class">FESystem</code>
+ could not be constructed if one of the elements it is to be composed of
+ did not implement interface constraints for hanging nodes. This is now
+ fixed: you can construct such a composed element, but it does not
+ implement hanging node constraints either.
+ <br>
+ (WB 2003/02/15)
+ </p>
+
+ <li> <p>
+ New: For each of the renumbering functions in the <code
+ class="class">DoFRenumbering</code> class there is now an
+ additional <code class="member">compute_*</code>
+ function. These new functions compute and return the
+ corresponding renumbering vectors but do not perform the actual
+ renumbering on the <code class="class">DoFHandler</code>
+ object. The behaviour of the old functions is not changed.
+ <br>
+ (RH 2003/02/03)
+ </p>
+
+ <li> <p>
+ Fixed: The <code class="class">GridReordering</code> tried to be
+ thread-safe in the initialization of some data, but was not due to a
+ typo. This is now fixed.
+ <br>
+ (WB 2003/01/28)
+ </p>
+
+ <li> <p>
+ Changed: The <code class="member">FEValues::get_cell</code> and
+ <code class="member">FEValues::get_face</code> functions have
+ been removed, since they limited our ability to use this
+ class for other types of DoFHandlers, for example future
+ extensions for hp elements.
+ <br>
+ (WB 2003/01/17)
+ </p>
+
+ <li> <p>
+ New: The DoF accessor classes now have a function <code
+ class="member">get_fe()</code> that returns a reference to the finite
+ element being used on this cell. The result is of course identical to
+ what a call to <code
+ class="member">iterator->get_dof_handler().get_fe()</code> would have
+ yielded.
+ <br>
+ (WB 2003/01/10)
+ </p>
+
+ <li> <p>
+ New: Checked in new <code class="class">GridGenerator</code>
+ member function <code class="member">half_hyper_ball</code>,
+ derived from member <code class="member">hyper_ball</code>.
+ The intial mesh contains four elements. This mesh will work with
+ the boundary class <code class="class">HalfHyperBallBoundary</code>.
+ <br>
+ (Brian Carnes 2002/12/16)
+ </p>
+
+ <li> <p>
+ New: Checked in new class <code class="class">FE_Q_Hierarchical</code>
+ derived from class <code class="class">FiniteElement</code>.
+ This element is analogous to <code class="class">FE_Q</code>, but
+ makes use of hierachical shape functions, based on the
+ <code class="class">Polynomials::Hierarchical</code> class.
+ For <code>degree>1</code>, the non-nodal basis functions are "bubble"
+ functions, which are not Lagrange polynomials. Therefore, the usual
+ interpolation based on using unit support points will not work for
+ <code>degree>1</code>. It is planned to implement a different
+ interpolation-projection operator, based on an hp-type interpolant.
+ <br>
+ The files for this element are
+ <code>deal.II/include/fe/fe_q_hierarchical.h</code> and
+ <code>deal.II/source/fe/fe_q_hierarchical.cc</code>.
+ <br>
+ (Brian Carnes 2002/12/13)
+ </p>
+
+ <li> <p>
+ New: For finite element classes, the functions
+ <code class="member">unit_support_point</code> and
+ <code class="member">unit_face_support_point</code> return the position
+ of an individual support point. This is necessary when you want to get
+ information about the support points of certain components in a composed
+ finite element, where not all components provide support points, and the
+ composed element thus does not fill the array the
+ <code class="member">get_unit_support_points</code> function returns.
+ <br>
+ (WB 2002/11/23)
+ </p>
+
+ <li> <p>
+ Fixed: Vectors could not be given as input and output vectors to the
+ <code class="class">SolutionTransfer</code> class at the same time, but
+ this was not checked. An assertion has now been added to ensure this
+ requirement.
+ <br>
+ (WB 2002/10/28)
+ </p>
+
+ <li> <p>
+ Fixed: The <code
+ class="member">DoFRenumbering::component_wise</code> function accepts a
+ parameter indicating the order in which the degrees of freedom
+ corresponding to one vector component are to be sorted. However, it did
+ not honor this order, but always sorted them in the order in which the
+ components appear. This is now fixed.
+ <br>
+ (WB 2002/10/17)
+ </p>
+
+ <li> <p>
+ New: The <code
+ class="member">FiniteElement::system_to_base_index</code> function now
+ exports the values of the <code
+ class="member">FiniteElement::system_to_base_table</code> member
+ variable. Likewise for the indices on faces.
+ <br>
+ (WB 2002/10/17)
+ </p>
+
+ <li> <p>
+ New: The <code
+ class="member">FiniteElement::element_multiplicity</code> function was
+ previously only available in the <code class="class">FESystem</code>
+ class, where it actually returned a non-trivial value. However, in some
+ cases one would need to access this field also for general finite
+ elements, even if the returned value will be equal to one in all cases
+ other than a composed element.
+ <br>
+ (WB 2002/10/17)
+ </p>
+
+ <li> <p>
+ Fixed: The algorithm to generate neighbor information for patches from
+ cells in <code class="member">DataOut::build_patches</code> was rather
+ inefficient, tripling the time for patch generation when support for
+ neighbor information was added. Furthermore, the algorithm was at least
+ O(N log N), where the rest was all O(N), making this particularly
+ problematic when the data set was already large. This should now be back
+ to the previous level, by using a more efficient algorithm.
+ <br>
+ (WB 2002/10/10)
+ </p>
+
+ <li> <p>
+ Changed (internals): Previously, the finite element base class
+ initialized the restriction, prolongation, and face constraints matrices
+ to their correct size. Derived classes had to fill these classes, and
+ should have set their size back to zero in case they chose not to
+ implement them. However, we found a class that forgot to resize it to
+ zero, so it is now the other way round: they remain at size zero, and a
+ class that chooses to implement these matrices has to set them to the
+ correct size, to avoid programs that run on data that as just been
+ forgotten to add. (This information only concerns programs that
+ implement some finite element class on their own.)
+ <br>
+ (WB 2002/09/28)
+ </p>
+
+ <li> <p>Improved: The different transfer functions in <code
+ class="class">FETools</code> operate on template vector arguments.
+ <br>
+ (GK 2002/09/24)
+ </p>
+
+ <li> <p> New: the class <code
+ class="class">FE_DGPNonparametric</code> implements finite elements
+ where shape functions are polynomials of order <i>k</i> on the
+ actual grid cell. This is achieved by evaluating the polynomials at
+ the mapped quadrature points. No grid transfer matrices are
+ available for this class.
+ <br>
+ (GK 2002/09/19)
+ </p>
+
+ <li> <p>
+ Fixed: Some of the various instances of the <code
+ class="member">VectorTools::interpolate_boundary_values</code> functions
+ were not explicitly instantiated, leading to linker errors. This is now
+ fixed.
+ <br>
+ (WB 2002/09/19)
+ </p>
+
+ <li> <p>
+ Removed: The <code
+ class="member">FiniteElement::component_to_system_index</code> function
+ and its counterpart for faces is gone. This data did not make much sense
+ in the case of elements that are non-zero in more than one vector
+ component, such as the Nedelec element. The respective information can
+ also be obtained from other sources provided by the finite element
+ classes, if so necessary.
+ <br>
+ (WB 2002/09/16)
+ </p>
+
+ <li> <p>
+ Changed: The <code
+ class="member">FiniteElement::restriction_is_additive</code> function
+ used to take an argument that denoted the vector component of a finite
+ element. This has become difficult with elements that are non-zero in
+ more than one vector component, such as the Nedelec element. Thus, the
+ semantics of the function have been changed so that the argument now
+ denotes the index of a shape function, rather than a vector
+ component. Since the function is probably not used in application code,
+ this will most probably not lead to more serious problems.
+ <br>
+ (WB 2002/09/16)
+ </p>
+
+ <li> <p>
+ New: The mapping classes now also know how to transform tensors of rank
+ 2, not only vectors (tensors of rank 1) in a co- and contravariant way.
+ <br>
+ (WB 2002/09/03)
+ </p>
+
+ <li> <p>
+ Fixed: the <code class="class">GridIn</code> class had problems
+ when reading in UCD grids with comment lines that contained
+ only the comment sign, but nothing else. This is now fixed.
+ <br>
+ (WB 2002/08/30)
+ </p>
+
+ <li> <p>
+ Improved: <code class="class">VectorTools</code>::<code
+ class="member">integrate_difference</code> can compute <i>L<sup>p</sup></i>
+ and <i>W<sup>1,p</sup></i> norms for arbitrary <i>p</i>. The function
+ receives an additional optional argument <i>p</i> for this. All previous
+ fuctionality remains unchanged, although the code has been cleaned up a bit.
+ <br>
+ (GK 2002/08/01)
+ </p>
+
+ <li> <p> New: The <code class="class">GridTools</code> class now
+ offers functions to apply general transformations to all
+ vertices of a triangulation, and also more specialized
+ functions that shift, scale, and rotate triangulations.
+ <br>
+ (RH 2002/07/25)
+ </p>
+
+ <li> <p> New: The existing <code
+ class="member">FETools::extrapolate</code> functions does not
+ take into account hanging node constraints. Therefore, it works
+ for continuous elements on globally refined grids and on
+ discontinuous elements, only. Now, there is a new <code
+ class="member">FETools::extrapolate</code> function with an
+ additional <code class="class">ConstraintMatrix</code> argument
+ for the hanging node constraints. This new function works for
+ continuous as well as for discontinuous elements. But, the old
+ function is still supported.
+ <br>
+ (RH 2002/06/17)
+ </p>
+
+ <li> <p> New: There are now <code
+ class="member">Triangulation::save/load_user_pointers(vector<void
+ *> &)</code> functions similar to the respective <code
+ class="member">Triangulation::save/load_user_flags(vector<bool>
+ &)</code> functions.
+ <br>
+ (RH 2002/06/14)
+ </p>
+
+ <li> <p> Fixed: Bug in <code
+ class="member">Triangulation<3>::load_user_flags(vector<bool>
+ &)</code> is now fixed.
+ <br>
+ (RH 2002/06/14)
+ </p>
+
+ <li> <p> Fixed: <code
+ class="member">Triangulation::load_user_flags(vector<bool>
+ &)</code> erroneously threw an assertion for
+ <code>dim==1</code>. This is now fixed.
+ <br>
+ (RH 2002/06/14)
+ </p>
+
+ <li> <p> Changed: <code
+ class="member">Triangulation<1>::n_quads</code> now returns 0,
+ instead of throwing an assertion, as before. The same holds for
+ similar functions like <code
+ class="member">Triangulation<dim>::n_hexs</code> that now
+ returns 0 for <code>dim<3</code>.
+ <br>
+ (RH 2002/06/14)
+ </p>
+
+ <li> <p> Improved: Several functions like the <code
+ class="member">DoFHandler::distribute_dofs</code> and <code
+ class="member">DoFTools::make_flux_sparsity_pattern</code>
+ functions altered the <code
+ class="member">user_flags</code>. This was stated in the
+ documentation of these functions. Nevertheless, it might have
+ led to unexpected behaviour of the <code
+ class="member">user_flags</code> for users who weren't aware of
+ this <em>side-effect</em>. Now, these functions do not alter
+ the <code class="member">user_flags</code>, any
+ more. Consequently, the users do not need to worry any more
+ about the reliability of the <code
+ class="member">user_flags</code> when calling any function of
+ the library.
+ <br>
+ (RH 2002/06/14)
+ </p>
+
+ <li> <p> Fixed: <code
+ class="member">FE_Q::has_support_on_face</code> always returned
+ true in 1d, partly because faces are not really an issue in
+ 1d. It now does so only when the support point of the
+ respective shape function is actually the requested vertex. The
+ same applied to <code
+ class="member">FE_DGQ::has_support_on_face</code>
+ <br>
+ (WB 2002/06/13)
+ </p>
+
+ <li> <p> New: The existing <code
+ class="member">FETools::interpolate</code>, <code
+ class="member">FETools::back_interpolate</code> and <code
+ class="member">FETools::interpolate_difference</code> functions
+ do not take into account hanging node constraints. Therefore,
+ they work for continuous elements on globally refined grids and
+ on discontinuous elements, only. Now, there are new functions
+ with the same names but additional <code
+ class="class">ConstraintMatrix</code> arguments for the hanging
+ node constraints. These new functions work for continuous as
+ well as for discontinuous elements. But, the old functions are
+ still supported.
+ <br>
+ (RH 2002/06/13)
+ </p>
+
+ <li> <p> Changed: The constructor of <code
+ class="class">DoFHandler</code> now takes a reference to a
+ <code>const</code> <code class="class">Triangulation</code>.
+ <br>
+ (RH 2002/06/12)
+ </p>
+
+ <li> <p> Changed: The constructors of all <code
+ class="class">DoFAccessor</code>, <code
+ class="class">TriaAccessor</code> and <code
+ class="class">TriaIterator</code> classes now take pointers to
+ <tt>const</tt> <code class="class">Triangulation</code>s.
+ <br>
+ (RH 2002/06/12)
+ </p>
+
+ <li> <p> Fixed: In debug mode the <code
+ class="member">MappingQ1::transform_real_to_unit_cell</code>
+ function erroneously threw an assertion when used in 1 or 3
+ dimensions. This is now fixed.
+ <br>
+ (RH 2002/06/10)
+ </p>
+
+ <li> <p>
+ Fixed: The <code class="member">get_dof_indices</code>
+ functions of DoF accessor classes used to work also for
+ non-active cells. However, the results were bogus except for
+ the special case that we had a finite element that has all its
+ degrees of freedom located in vertices. This is now fixed: the
+ function throws an exception in all other cases, since there is
+ no useful meaning for it then. It continues to work in the
+ special case.
+ <br>
+ (WB 2002/06/08)
+ </p>
+
+ <li> <p>
+ New: For encapsulated postscript output of 2d grids, it is now
+ possible to tell the <code class="class">GridOut</code> class to
+ write the cell numbers into each cell, as well as the numbers
+ of the vertices.
+ <br>
+ (WB 2002/06/04)
+ </p>
+</ol>
+
+<hr>
+Last update $Date$
+
+</body>
+</html>
projects / dealii-svn.git / commitdiff