Obsoleted future plans
Future development is tracked at http://blueprints.launchpad.net/yade
Also see the current development schedule.
New names for core classes
Proposed new names for the most important classes in the project.
|Current name||New name||3 letter name||Meaning|
||information about a body that changes during the simulation process and is different for each instance of a body in the simulation, like position, velocity, acceleration and mass, inertia|
||information about constraints imposed on a body state, like disallowing to change body's position in z direction, or exceeding a velocity or y position a given maximum limit, a constrained value can be either kept at limiting value, or could decide that body must be deleted (like maximum strain, or body ran out of the simulation edges). This information is respected by engines when the BodyExternalVariables are used to calculate a BodyState for the next execution of simulation loop. Usually a big number of bodies will use the same constraints, and even bigger will not use constraints, thus the count of instances of this class will be much smaller than total count of bodies.|
||information about a body that usually does not change during the simulation and is the same for many instances of bodies. For example whole simulation of reinforced concrete will need only two instances of this class: one for concrete, second for reinforcement. It's intended to be an information used by constitutive laws, like stiffness or cohesion|
||The idealized shape of a body that we want to simulate: it is used to create a simplified shape, and for display|
||a shape of the body used for performing the actual simulation, may be different from idealized shape, because it's merely its represntstation used for the prupose of simulation|
||a bounding volume is used to detect potential interaction between bodies, usually is built from information stored inside simplified shape|
||information about an interaction happenning between bodies which changes while the interaction evolves during the simulation, like penetration depth or shearing force|
||information about an interaction happening between bodies which usually does not change during the simulation, even when bodies disconnect and reconnect again. Like contact stiffness|
||if an interaction can have an idealized shape representation, this class is for it, like a water meniscus between two spheres in cohesive interaction caused by water.|
||If you need some information which cannot be directly read from the classes mentioned above, but you need to calculate something and store it somewhere for further reading, use this class. The engines of simulation loop usually will not read from this class, it is rather to store some (final) results needed from the simulation|
||It is a complementary information about a body, which usually sums the effect of all physical actions on a body. This information most often is an intermediate stage that is used to calculate future values (for the next execution of simulation loop) of data stored in BodyState. For example a sum of forces and moments acting on a sphere (they will be used to change body's position and orientation which are stored in BodyState)|
|| Anything that is reading or writing into the simulation data while performing some computational operations, it is a basic building block of the simulation loop. The engine is not supposed to store any information related to calculated model, only information that configures the way in which the engine runs.
Also see note at
|| Both |
||||This class contains everything inside: the data classes for bodies, interactions, and also a simulation loop with engines inside|
||class is removed, to allow reorganization of containers|
The 3 letter name: is used to prefix each class name in yade, to indicate the ROOT of inheritance tree. Yade developers will need to remember those short name versions - thus the intention is to make them easy to remember.
 - an idea is to add a class that is used specifically to record and calculate some information about happening simulation (and have an
GLDraw handler also, just like all the other classes have it and can be drawn on the screen). It's an intermediate stage between reading directly from the simulation to have results - a stage to process this information a bit ans tore it here.
 - you never derive from this class
Model and its containers
Since all the data is to be stored inside
Model we need to say something about its containers. First of all:
- To simplify managment of data a
boost::bimap<X,Y>will be used. This container works in both directions like
Yis a set of
group_ids to which it belongs, like
body_idnumbers are positive,
group_idnumbers are negative. Number zero means empty as in not a body and not a group. Either
short int;) can be used here for the body and group ids.
- To help humans in identifying stuff the ids can be named with
std::stringbut don't need to. For this, we use another container of type
Zcan be either a
group_id, which is in fact a (maybe
boost::bimapallows to identify
ids in both directions - either with a name, or with an id number.
- To simplify managment of data a
- Body data classes
Body*data class listed above has dedicated, separate, container for it. We got a container for
BodyState, another container for
BodyStateConstraints, and so on.
- All bodies have an
idnumber, thus the containrs are actually a bit similar to
std::map<id,Class>in functionality (but see notes about Containers in point 2. below). Information with the same
idnumber in two different containers belongs to the same body.
- Each body can belong to several groups, thus it is fast to iterate over all members of some chosen group.
- Containers take care of multithreading synchronization on their own. Classes written by users, stored inside containers, won't need to worry about this.
- Therefore they provide two means of access: a read-only access, and read-write access to container elements. The function names could be eg:
operatoraccessor can default to read-only function
- Containers allow links between the content, like parent/target/members. So that a single BoundingVolume (for example a cylinder) will consist of many members bounding boxes that cover the cylinders walls (so that the inside of a cylinder is outside bounding volume). Another example - a clump has many members that are spheres.
A note on acronyms in naming
We are using
CamelCase for class names, but it turns out that we cannot avoid using acronyms, which are not compatibile with
CamelCase, for example AABB. So I propose, that when it is necessary to use an acronym, we will make it a word - only first letter is capital. Like this:
Aabb. The same was done with three-letter abbreviations (they have only first letter capital).
Naming of data classes
There comes another problem: the DispatcherFunctor will have a lenghty name of no matter how hard we try: it will contain in it a full name of
SomeClass2, so th epoint is to make a bit shorter names of derived data classes, using mentioned above Short name or Acronym.
* - after refactoring containers, empty classes will no longer be necessary, and will be removed
** - this Quadrilateral is actually a DataProcessor, and so it will become it.
NOTE: we should consider adding basic classes that will be used for multiple inheritance:
- Tetrahedron for BS_Tetrahedron (Tetrahedron) and BOS_Tetrahedron (TetraMold). They have the same data members!
- Sphere for BS_Sphere, BOS_Sphere, BBV_Sphere. They also have exactly the same data members!
- Box for BS_Box and BOS_Box.
Then Unless a specific GLDraw is written for BBV_Sphere - a generic one that understands Sphere can be used ;)
OR: we should allow storing the same class (eg. Sphere) in different containers - in bounding volume container, in body shape container, etc...
EngineUnit (EngineFunctor) naming
To show you the full horror of currently used names, I have prepared a lenghty table at the bottom of this page with currently used names.
No doubt that we must do something to simplify and regularize the convention. Othwerwise, even though everyone of us does his best, we will have names that are difficult to work with. Current proposal is based on following reasoning which compares EngineUnit (DispatcherFunctor) to classical C++ virtual method:
|question||a normal C++ virtual method||EngineUnit (EngineFunctor)|
|what it does?||is a virtual member function of single class||is simulating a virtual member function of two classes.|
|what is (would be) its fully qualified name?||
|so what is the proposal?|| use current name ;-)
|| use EngineFunctor name like this:|
It is impossible to have a name
SomeClass1::SomeClass2::functionName() in C++, because DispatcherFunctor is simulating a missing C++ functionality. For the same reason
functionName() must be part of the classname, because the member function of
SomeClass1_SomeClass2_functionName() that contains the actual code has always a fixed name:
Currently we use '
2' and '
4', I proposed '
_' but we can use three characters as well, like '
_x_' or '
_2_'. This matter is still open. In table at the end of this page I'll use '
_', as an example.
Naming of DispatcherFunctors
Finally we can try to rename EngineUnits (DispatcherFunctors) to something which is not a horror anymore... uh.
|Current name||New name|