User Tools

Site Tools


meeting-2013

This is an old revision of the document!


Maintenance

  1. 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)
  2. 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)
  3. 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.
  4. Reduce numbering of engineering models
    1. SM-module: Replace DEIDynamic, DIIDynamic, NLDEIDynamic, NonLinearDynamic with Dynamic
    2. TM-module: Replace NonStationary, NLTransient with Transient
  5. 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 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.

For new developers

  1. 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.

Consistent naming schemes

  1. Geometric type, interpolation order, and equation type should be part of the name. Will definitely break backwards compatibility
  2. Add ClassFactory for interpolation classes, allowing to create more flexible

Sets

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

License

  1. Keep GPL - Might cut of commercial interest that could be benefitial
  2. Switch to LGPL - Commercial might pay developers to extend OOFEM to include new elements, materials, contact models, etc.
  3. Offer separate commercial license - We would probably require a copyright assignment agreement for contributions to work with this. Seems unlikely to happen.
meeting-2013.1365950428.txt.gz · Last modified: 2013/04/14 16:40 by mikael.ohman