> Written? Yes, any of the colliders we have would do the job. Just set > an interval for e.g. insertionSortCollider, and run it periodically > with detectionFactor = 1.5. > During N timesteps, use the same list of interactions (some will go > from virtual to real, or real to virtual, no problem with that as long > as they can change many times). > I experimented that before with the triangulation collider, it worked > well, but it was not faster than SAPcollider for a stupid reason (*), > and I realised the same thing could be achieved with SAPcollider with > intDetectionFactor=1.5. > It needs a few adjustments in other classes now, perhaps, perhaps not. > For instance, i'm not sure requestDeletion(i) will let "i" become real > again, but this would be minimal changes. > The problem with CGAL::triangulation is its not parallel. We would need to define some measure of maximum velocity and adjust collider's interval so that we wouldn't miss interactions. I am not sure how much it would help, as number of AABB overlaps is proportional to detectionFactor^3, whereas time savings are linear to the stride of collider wakeups. As we have ABB overlaps in the same container as real interactions, it will also slow down loop over interactions (shouldn't we split that in 2 containers?). I will try to experiment with that; I created https://blueprints.launchpad.net/yade/+spec/collider-stride to track the idea.
"Written?"=triangulation collider. I am still not sure about legal status of CGAL, if we may use it or not. They have something about using it in GPL programs on their license page, but it is not very clear. They're killing their product by those restrictions, at least for me (too bad they have python wrappers for their lib, also). > > We will experiment, thank you for the tip. I'm not so sure a lot of > algebra libraries with parallel features are available. There is PLENTY! At least those oofem uses are http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview and http://www.mcs.anl.gov/petsc/petsc-2/, which are damn good as far as I know (see also http://www.mcs.anl.gov/petsc/petsc-2/miscellaneous/external.html). > >> Oh, BTW, is there agreement on having useShear by default and >> progressively remove prevNormal from various InteractionPhysics classes? > I'd prefer to keep the traditional (Cundall) incremental form for now. > The equations are simpler, especially in 3D, so it is easier to > understand what happens and implement different laws. I will change my > mind one day perhaps, but for now I feel like the incremental form is > good enough for dry friction. :) Ah, nay, there is still misunderstanding here. Read SpheresContactGeometry::updateShear and compare it to updateShearForce. It is the _same_ incremental formulation, but it increments shear _displacement_ (rather than _force_), which is, I think, what most constitutive laws need (even if they are non-linear) and therefore can use. I would like to have that incremental formulas at one place only. (The non-incremental algo is in Dem3Dof* classes and I am quite happy with it.) V. _______________________________________________ Mailing list: https://launchpad.net/~yade-users Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp _______________________________________________ yade-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/yade-users
