From Yade

This page describes the current (23.11.2009) state of trunk.

Separation of BodyState from Material

PhysicalParameters were separated in Body::Material and Body::State. See Material_and_State_classes for details.

Shared Materials


  1. vector<shared_ptr<Material> > MetaBody::materials holds materials that are shared. They are shared by virtual of shared_ptr.
  2. Body::material which is not shared has always Body::material->id==-1
  3. Material which is shared has Material::id>=0. This id _must_ correspond to the index within MetaBody::materials!!! Use MetaBody::addMaterial to push_back to MetaBody::materials and set the id in the right way at the same time.
  4. NEVER remove materials, unless you are sure no body uses them and that you will not change index of other shared materials!
  5. Materials can be looked up by their index: Material::byId(int,MetaBody* mb=NULL)
  6. materials can be looked up by their label: Material::byLabel(string, MetaBody*mb=NULL). This iterates over all materials (currently), doesn't scale.


  1. O.materials is the container; access: by index O.materials[1], by label O.materials['someName']
  2. O.materials.append to add materials (removing not supported)
  3. NEVER change id of the material by hand (O.materials[2]['id']=1 and such)
  4. straightforward assignment to bodies:
# or if not shared

utils.sphere & friends

see epydoc documentation on utils.sphere, notable the material= parameter ( -- will be updated automatically in a few days; meanwhile, see docstring or type utils.sphere? in the ipython console)


Shared interaction parameters

In the same way as for bodies, Interaction::interactionPhysics could be separated into IntrState and IntrParams (constant, shareable); the ConstitutiveLaw would dispatch based on IntrParams and IntrParams could declare what type of IntrState they require. (hierarchy of IneractionPhysics )

  1. pair<int,int> Interaction::paramsIds (default something like -1,-1; meaning interaction parameters are non-shared, inside Interaction::InteractionParams); if >=0, we would look for parameters in MetaBody::sharedInterationParams (better name?), a 2-dimensional symmetric storage (of dimensions nMaterials × nMaterials) for IntrParams; again, this logic would be wrapped in Interaction::getParams(MetaBody*) or such.
  2. sharedIntercationParams could be filled in advance with some meaningful data by the user
  3. For a new interaction, if at least one body uses non-shared material, the interaction would not share its params -- the would have to be computed as usual by the functor (averages of the Youngs moduli etc)
  4. For a new interaction, if both bodies use a shared material (of indices i and j), then
    1. use sharedInteractionParams[i,j] if it exists (either set by the user, or computed previously)
    2. compute values for sharedInteractionParams[i,j] by the functor, store it in sharedInteractionParams and use it for the new interaction

This way, we can have

  1. predefined interaction parameters for any given 2 material types, if the user wishes (Vincent, do you see GroupRelationData here ;-) )
  2. once-computed and shared interaction parameters for any 2 shared material types (which would give the same results in all cases, anyways)
  3. arbitrary interaction parameters if at least one body doesn't share the material (Bruno, think statistically distributed rigidities, frictionAngles etc)


Original proposal: thread1, thread2


Comments & discussion