oofem-wiki

This is an old revision of the document!

Avoiding duplicated information (impossible to keep things up-to-date in the manuals). Good would be to store everything in-code (perhaps with some script scavengers all information from the headers automatically)
Modularity: Having each REGISTER_CLASS() in the respective source file. Code for registering components exists for string-only versions (I'm hoping that classtype versions should rather be removed). Currently works for dynamic linking, but static linking is a problem (static symbols are optimized away). Solution could be to push for dynamic linking.
classType has to go. Replace with strings (Note: int DataStream::write(const std::string &data); + read already exists!). This effects context files and load balancing.
Reduce numbering of engineering models
1. SM-module: Replace DEIDynamic, DIIDynamic, NLDEIDynamic, NonLinearDynamic with Dynamic
2. TM-module: Replace NonStationary, NLTransient with Transient
Automatic tools:
1. More tests (at least 1 for each element type, at least 1 for each material, and 1 for each engineering model).
2. Coverage testing (static analyzers could help, gcov + ctest is an option but it will miss tons of unstestable, optional but used, code).
3. Aiming at zero-warning policy, even with MSVC (some thing that MSVC warns about could be fixed, some could be turned off). Usage of -DCMAKE_CXX_COMPILER_FLAG=-Werror is recommended. We still produce quite a lot of warnings in Clang and Intels compilers.

Add BasicElement (linear triangle with plane stress) and BasicMaterial (isotropic plasticity + hardening) for the structural analysis problems which could help new developers get started without having to understand complex inheritance and tons of optional features. These are kept in-code with tests so that we make sure to keep them up-to-date.

Geometric type, interpolation order, and equation type should be part of the name.
1. Number of spatial dimensions rarely need to be part of the name.
2. Will definitely break backwards compatibility.
3. Tricky cases: Bi-quadratic v.s. Serendipity interpolation. Beams and shells. Springs.
4. Suggested naming for standard elements: Type-Geometry-Order. E.g: PlaneStressTr2, HeatTransferHexa1
5. Should we try to be consistent with SpringLine1 and Beam2dLine1 ? I think these structural elements could have their own naming / Mikael
Add ClassFactory for interpolation classes, allowing to create more flexible
1. FEInterpolation *ClassFactory :: createInterpolation(const char* name) ←- Needs empty (or consistent constructors).
2. ''PlaneStressTr2

Mikael will be adding sets (boundary/edge/surface sets and bulk sets to start with)
Active boundary conditions will use sets instead of storing their own list of elements.
See where to go from there (perhaps it's possible to keep backwards compability)

Keep GPL - Might cut of commercial interest that could be benefitial
Switch to LGPL - Commercial might pay developers to extend OOFEM to include new elements, materials, contact models, etc.
Offer separate commercial license - We would probably require a copyright assignment agreement for contributions to work with this. Seems unlikely to happen.