Difference between revisions of "Yade2"
From Yade
(Blanked the page) |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | = Object overview = |
||
| − | |||
| − | Scene |
||
| − | [field, field, ...] |
||
| − | engines (1) |
||
| − | Field: |
||
| − | [Node, Node, ...] (2) |
||
| − | [NodeData, NodeData, ...] (3) |
||
| − | Node: |
||
| − | position, orientation |
||
| − | Constraint |
||
| − | DynState (4) |
||
| − | |||
| − | (1) Each engine chooses to which field it applies, and is run only for them (serially or in parallel, if desired); it is also possible to restrict engine to only some fields by hand. |
||
| − | |||
| − | (2) All objects in sequences or objects encapsulated in other objects are shared_ptr's are are shared as much as meaningful. Nodes in fields are shared, aobjects store pointers rather than ids, which necessitate stable storage. (Care must be taken to avoid ownership loops, which would lead to stale objects). |
||
| − | |||
| − | (3) Each field should be able to attach its own data to nodes, independently of other fields. The association is not straightforward, as nodes cannot contain to node data, as they are shared over fields. Perhaps nodeData could contain Node*, and there would be no [node, ...] in the Field itself. |
||
| − | |||
| − | (4) I thought other fields than DEM could be interested about velocity etc of the node. |
||
| − | |||
| − | DemField: Field |
||
| − | [Particle, Particle, ...] |
||
| − | [Contact, Contact, ...] (5) |
||
| − | Particle: |
||
| − | Material |
||
| − | Shape: |
||
| − | Bound |
||
| − | [Node,Node,...] (6) |
||
| − | contacts: {otherId1: Contact*, otherId2: Contact*, ...} |
||
| − | Contact: |
||
| − | particleA, particleB |
||
| − | CGeom, CPhys, CData (7) |
||
| − | CGeom: |
||
| − | node (8) |
||
| − | CPhys: |
||
| − | force, torque (9) |
||
| − | CData: /* arbitrary */ |
||
| − | |||
| − | (5) Linear array gathering all contacts stored in Particles:contacts for all particles |
||
| − | |||
| − | (6) Each Shape can have multiple nodes - think of facets defined by 3 corners, or brick elements and such. |
||
| − | |||
| − | (7) CData is used by the Law2 functor to store any additional data it needs; this avoids abusing IPhys (CPhys) as it is done now. |
||
| − | |||
| − | (8) Each contact defines local coordinate system; it could be coincident with the global system as well |
||
| − | |||
| − | (9) force and torque on contact node is in contact-local coordinates. |
||
| − | |||
| − | = Dem logic = |
||
| − | |||
| − | DEM engines work on the ``DemField`` field only. Collision detection works on particles, but forces act subsequently on nodes, which carry mass and are moved by integrator. Typical loop: |
||
| − | |||
| − | 1. Collision detection between particles |
||
| − | 2. Usual Contact loop; Cg2 (Ig2) creates contact node (for real interactions), Law2 stores force&torque in the contact node |
||
| − | 3. Compute "Inner forces" (In2_Sphere_ElastMat) |
||
| − | a. transfers forces from contact nodes to particle nodes -- different based on particles shape (spatial node distribution, their number). For 1-node shapes (sphere), simply compute equivalent force&torque on snape.nodes[0] from equilibrium, otherwise distribute based particle in question. (For clumps, force should cascade down to the node which will be eventually integrated; not clear how to implement it) |
||
| − | b. compute forces on nodes coming from particle deformation due to motion of nodes; depends on material. Probably no-op for 1-node particles, but think of facet being stretched from edges, which must be pulled together. |
||
| − | 4. Integrate motion of nodes (clumps: push motion up the clump cascade, in the other way) |
||