Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.

Currently locked by: 216.73.216.144,10.1.9.57
Lock expires at: 2025/07/03 09:19 (10 min)

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

=== Maintenance ===
  - 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)
  - 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
    - SM-module: Replace ''DEIDynamic'', ''DIIDynamic'', ''NLDEIDynamic'', ''NonLinearDynamic'' with ''Dynamic''
    - TM-module: Replace ''NonStationary'', ''NLTransient'' with ''Transient''
  - Automatic tools:
    - More tests (at least 1 for each element type, at least 1 for each material, and 1 for each engineering model).
    - Coverage testing (static analyzers could help, gcov + ctest is an option but it will miss tons of used code).
    - 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 ===
  - 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 ===
  - Geometric type, interpolation order, and equation type should be part of the name. Will definitely break backwards compatibility
  - Add ClassFactory for interpolation classes, allowing to create more flexible 

=== Sets ===
  - 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)

=== License ===
  - 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.