Tasks for today: Update and regenerate documentation. Talk about next week's schedule. Take a look at the collaboration diagram again. Take a look at the grid classes.
Documentation and programs are constantly updated by others. Every once in a while, it is therefore a good idea to update one's sources to get the latest changes from the repository. Using subversion, this is how this is done:
svn update
Since now your documentation is out of synch from the program sources, you should judge whether this is a problem and if necessary re-run documentation generation. It may also be a good idea to re-make the entire project. Let's start this and go on to other stuff while this is running:
make online-doc make all -j2
Everyone should give a brief overview of their research, and where possible topics for projects based on deal.II are.
Take a look at this collaboration diagram: http://www.dealii.org/developer/doxygen/deal.II/index.html. It is essentially the same diagram already shown in the first class of the semester. Consider it as your homework to read over this text once. We will use this diagram as the guide for the next few week's class topics.
GeometryInfo was already mentioned: http://www.dealii.org/developer/doxygen/deal.II/structGeometryInfo.html.
Triangulation (http://www.dealii.org/developer/doxygen/deal.II/group__grid.html): Creation typically using the GridGenerator class
Triangulation<dim> triangulation; GridGenerator::hyper_cube (triangulation); GridGenerator::hyper_ball (triangulation);
Triangulation is essentially a container class to store the data about vertices and their connection to lines, faces, and cells. Just like with STL containers, not very many functions that actually do something with the data:
Triangulation<dim> triangulation; ... triangulation.n_cells (); triangulation.n_active_cells (); triangulation.refine_global (); triangulation.execute_coarsening_and_refinement ();
Data is stored in a level-wise hierarchy. Triangulations allow to get access to this data using iterators:
Triangulation<dim>::cell_iterator cell = triangulation.begin(); Triangulation<dim>::active_cell_iterator cell = triangulation.begin_active();
Iterators are like pointers: they point to an object that one can manipulate or ask for information. However, these objects are not consecutive in memory, so we can't just use a simple pointer but instead use a class that acts like a pointer (an iterator type). In addition, active iterators can simply skip over non-active cells, i.e. they provide a view on a subset of all cells.
Usually, iterators point to objects with data. In our case, we don't even do that: iterators point to accessors -- objects that do not store the data itself, but have functions that can be used to access the data that is stored elsewhere. For example:
cell->vertex (3); cell->neighbor (1); cell->set_refine_flag ();// only active cell->child (2); // only non-active cell->at_boundary (0); cell->diameter (); cell->measure (); cell->get_tria ();
A complete listing of functions can be found here: http://www.dealii.org/developer/doxygen/deal.II/classTriaObjectAccessor.html and http://www.dealii.org/developer/doxygen/deal.II/classCellAccessor.html. Documentation is from stone age of deal.II -- feel free to improve:
emacs deal.II/include/grid/tria_accessor.h svn commit -m "Improve documentation" deal.II/include/grid/tria_accessor.h
Unless you want to implement an element that isn't in the library yet (unlikely, since there are only few left), you won't ever get into contact with anything except creating and deleting finite element objects. Let's take a look anyway:
Collaboration diagram: http://www.dealii.org/developer/doxygen/deal.II/index.html. Note the dual purpose of FE classes.
FE Data abstractions: http://www.dealii.org/developer/doxygen/deal.II/classFiniteElementData.html. Note static information and conformity.
Actual shape function: http://www.dealii.org/developer/doxygen/deal.II/classFiniteElement.html.