meeting-2013
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| meeting-2013 [2013/04/13 03:08] – created mikael.ohman | meeting-2013 [2014/08/04 19:06] (current) – mikael.ohman | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| === Maintenance === | === 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) | - 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. | + | - <del>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: '' | + | - < |
| - Reduce numbering of engineering models | - Reduce numbering of engineering models | ||
| - SM-module: Replace '' | - SM-module: Replace '' | ||
| Line 8: | Line 8: | ||
| - Automatic tools: | - Automatic tools: | ||
| - More tests (at least 1 for each element type, at least 1 for each material, and 1 for each engineering model). | - 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). | + | - <del>Coverage testing (static analyzers could help, gcov + ctest is an option but it will miss tons of unstestable, |
| - Aiming at zero-warning policy, even with MSVC (some thing that MSVC warns about could be fixed, some could be turned off). Usage of '' | - Aiming at zero-warning policy, even with MSVC (some thing that MSVC warns about could be fixed, some could be turned off). Usage of '' | ||
| Line 15: | Line 15: | ||
| === Consistent naming schemes === | === 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: '' | ||
| + | - Should we try to be consistent with '' | ||
| - Add ClassFactory for interpolation classes, allowing to create more flexible | - Add ClassFactory for interpolation classes, allowing to create more flexible | ||
| + | - '' | ||
| + | - '' | ||
| === Sets === | === Sets === | ||
| - | - Mikael will be adding sets (boundary/ | + | - <del>Mikael will be adding sets (boundary/ |
| - | - Active boundary conditions will use sets instead of storing their own list of elements. | + | - <del>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) | + | - <del>See where to go from there (perhaps it's possible to keep backwards compability)</ |
| + | |||
| + | === License === | ||
| + | - < | ||
| + | - < | ||
| + | - < | ||
meeting-2013.1365815334.txt.gz · Last modified: 2013/04/13 03:08 by mikael.ohman