> in the case of engines using getStress function, there can be used a > hack with useDem3dof parameter, but in general getStress function > depends on if you use SCGeom or Dem3DofGeom (for the same particles > displacement it differs in sign). Yes, unfortunately.
> So ideal way would be the runtime determination of interaction type in > getStress, so from performance point of view I recommend to have one > more parameter (const static int), which would be (for example) 0 for > GenericSphereContact, 1 for SCGeom and 2 for Dem3DofGeom, and in > getStress it would look like: > > int type = I->phys.get().type; > if (isPeriodic) branch += (type==1? 1 : > -1)*scene->cell->hSize*I->cellDist.cast<Real>(); > > would such solution be ok? > Jan > I thought about that once before, It could work but it is complicated and a bit weird. It's a short term workaround to a long standing problem, and it will still be painful in the long run. Everyone coding a function using contact forces would have to remember that i->phys->force needs to be inverted depending on I->phys.get().type. A nightmare for developers. Coding a new law would give 50% chance to pick the wrong type. I wanted to remove those "forceSign" flags when possible, adding new flags in interactions would not help. There is only one law using the inverted convention currently: ConcretePM (not counting orphan laws that will be removed soon). The only real fix I can imagine is to revert the force convention in this ConcretePM (maybe 4 lines to change), then all laws would have same convention and we can get rid of the remaining flags, else I'd prefer to keep current situation. Bruno
_______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp