Todo List

Class AVI

The update routine does not take further arguments that may not need to be updated but may be needed to compute the force field, such as when dealing with plasticity or a coupled heat conduction problem. We will need to deal with this eventually.

Member AVI::getImposedValues (const GlobalElementIndex &ElementIndex, const LocalToGlobalMap &L2G, size_t field, size_t dof, double &qvalue, double &vvalue) const =0

There has to be a cleaner way to deal with the value of the boundary condition other than providing a general interface to code them in the derived classes.

Class BasisFunctions

So far the number of spatial dimensions, needed to transverse the getDShapes and getQuadraturePointArrays is not provided, but should be obtained from the ElementGeometry where these basis functions are in. One way in which this may be computed is using the fact that getQuadraturePointCoordinates().size()/getIntegrationWeights().size() = getDShapes().size()/getShapes().size() = spatial dimensions

Member DResidue::assemble (std::vector< DResidue * > &DResArray, const LocalToGlobalMap &L2G, const VecDouble &Dofs, VecDouble &ResVec, MatDouble &DResMat)

This structure has to be revised. In the implementation of both assemble functions I had to use a dynamic_cast to prevent writing two versions of essentially the same code, one for residue and another for

Class Element

It would be nice to have vectors and tensors as fields, where for each component one assigns a single set of shape functions and quadrature points. The current abstraction is flexible in the sense that it does not enforce vector or tensor fields to have the same quadrature and shapes.

Need to explain what the expected order of the vectors getShapes() and getDShapes() is.

Need to explain that either getShapes or getDShapes may return an empty vector, signaling that those values are not available.

Class P13DTrace< NF >

As was commented in P12DTrace, TetGeom may have to be a pointer and not a reference, since this is a reference to a copy of the original geometry.

Class Residue

This class does not accept the input of additional parameters that may be needed for the evaluation of T that may not be solved for.

The assembly procedure should probably be changed

Member Residue::assemble (std::vector< Residue * > &ResArray, const LocalToGlobalMap &L2G, const VecDouble &Dofs, VecDouble &ResVec)

A defect of this implementation is that all fields in the element enter as arguments for Residue and its derivative. It would be good to have the flexibility to extract a subset of the degrees of freedom of the element as the argument to Residue and its derivative. In this way it is possible to act with different elemental operation on different degrees of freedom naturally, i.e., without having to artificially return a Residue that has presumed contributions from all degrees of freedom.

Member Shape::getVal (size_t a, const double *x) const =0

It'd be nice to have some form of Coordinate object, which may derive Barycentric and Cartesian coordinates, and that would guarantee that the argument to each function is always the correct one.

Class ShapesEvaluated

It would be nice to provide an interface of iterators to navigate the vectors, so that it is not necessary to remember in which order the data is stored in the vector. In the interest of simiplicity, this is for the moment skipped.

It would useful to have the option of not computing the derivatives of the shape functions if not needed. Right now, it is not possible.

Make coordinate types so that it is not necessary to check whether one is using the right convention between the three related classes.

The computation of derivatives of shape functions with respect to the coordinates of the embedding space can only be performed if the ElementGeometry::map has domain and ranges of the same dimension. Otherwise, the derivatives should be computed with respect to some system of coordinates on the manifold. This will likely need to be revisited in the case of shells.

Need to fix the Lapack interface... it is too particular to Mac here, and even not the best way to do it in Mac...

Class ShapesEvaluated__< ShapeObj, QuadObj >

Should I perhaps have the constructors of the class to be protected, making the classes using ShapesEvaluated__ friends? Since the ElementGeometry is not stored or referenced from within the class, it would prevent unwanted mistakes.

In the future, as remarked in ShapesEvaluated as well, we need to separate the need to provide the Shape function values from the one of providing the derivatives as well, perhaps through multiple inheritance.

Member StandardAVI::setBCs (const MatBool &IFlag, const MatDouble &IVal)

--Modify this to reflect changes to constructor

Class Tet_1

Need to include a test for this quadrature

Member Tet_11Point::BulkCoordinates []

Include face quadrature rules if needed.

Member Tet_15Point::BulkCoordinates []

Include face quadrature rules if needed.