Differences

This shows you the differences between two versions of the page.

--- meeting-2013 [2013/04/14 16:40] – mikael.ohman
+++ meeting-2013 [2013/04/23 20:21] – mikael.ohman
@@ Line 1: / Line 1: @@
 === 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)
+  - 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.
+  - ''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''
@@ Line 8: / Line 8: @@
   - 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).
+    - Coverage testing (static analyzers could help, gcov + ctest is an option but it will miss tons of unstestable, optional but 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.
@@ Line 15: / Line 15: @@
 === Consistent naming schemes ===
-  - Geometric type, interpolation order, and equation type should be part of the name. Will definitely break backwards compatibility
+  - Geometric type, interpolation order, and equation type should be part of the name.
+    - Number of spatial dimensions rarely need to be part of the name.
+    - Will definitely break backwards compatibility.
+    - Tricky cases: Bi-quadratic v.s. Serendipity interpolation. Beams and shells. Springs.
+    - Suggested naming for standard elements: Type-Geometry-Order. E.g: ''PlaneStressTr2'', ''HeatTransferHexa1''
+    - 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
+    - ''FEInterpolation *ClassFactory :: createInterpolation(const char* name)'' <-- Needs empty (or consistent constructors).
+    - ''PlaneStressTr2
 === Sets ===