Stopping a Simulation Via Force/Distance

Hi Zachary,

thanks for your feedback. I added a few things to the tutorial at the end of http://woodem.eu/doc/tutorial/basic.html#running which shows how to access things like number of contacts with len(S.dem.par[i].con) and force with S.dem.par[i].f .

After some thoughts, I changed the logic behind Particle.{contacts,con,tacts} to return only real contacts, as potential contacts are implementation detail (still accessible through Particle.allContacts), so you need r3619 for the above to work as it should.

If you access a particle often, you can shove it into the S.lab dictionary, e.g. the middle particle S.lab.mid=S.dem.par[1] so that you can access it by name rather than by remembering particle index all the time.

Coordination number is computed using http://woodem.eu/doc/woo.utils.html#_utils2.coordNumber (woo.utils.coordNumber). It could be easily (by adding to py/_monkey/aliases.py) aliased so that one could call S.dem.coordNumber(...), would it be easier to find then perhaps -- what do you think?

HTH, cheers!

Václav

Václav,

First I'd like to thank you very much for the quick help, this should let me continue with my simulation immediately. The additions to the end of the tutorial were excellent, I can see them being referenced often. The change of the logic is also sensible, Yade often had issues with determining when no more contacts were occurring, resulting in many of my simulations having to be stopped manually.

As for the S.lab dictionary, while the functionality is the same as label="name" in Yade, and it is not an issue for me to type out S.lab. each time I reference the particle(Though I am aware I could use "from woo.lab Import *"). It may be more intuitive to use a similar method to label, it would also permit using virtuals and overrides to define and implement specific functions for each body, cut down on code length, and shift to using the particle class only for labelling.

I like the idea of moving the Coordination number to an alias, accessing it through that function would be extremely simple.

A general point I could make having used both Yade and Woo now is that they need to be more accessible. Simple behind the scenes tools to automatically assign the physics and contacts unless they are specified, and condensing classes to reduce complexity, would make the code much more appealing. Possibly increase it's use and popularity. In general though, Woo is much more intuitive so far than Yade.

Forgive me if I've said anything incorrect, this is only based on my current and limited knowledge. Thank you again, both for the wonderful program and the help.

Cheers,

Zachary

Hi Zachary,

always good to hear some feedback; you did not say anything incorrect, and if you did, then it would not be with a bad intention. I am glad the tutorial helped you better this time.

For the S.lab, it is smarter than you think :) It is not a module (so you cannot import * from it), it is a proxy for storing scene-specific things. So it will also properly load and save them 9including shared pointers0, even if you have multiple scenes at the same time and such. I did not really get what you mean by virtuals for labels? Any example of what you mean?

For the accessibility, that's also a matter of style. People tend to spaghetti code even if they don't have to; spaghetti is just so good that one can't resist ;) I tried to hide quite a few things from the sight (engines, contact models etc), and the rest can go to modules, like this one http://woodem.eu/doc/woo.triangulated.html . Often people write long code because they don't know there is a better way to do it. I guess that's an invitation for me to push the docs a bit :)

Cheers, Václav

Václav

When I mentioned virtuals for labels, I was referring to the idea of haveing a virtual method in the object class named label such as:

virtual label(string Name){
//...//}

This would by default store a reference inside a vector of type array (or vector), which would allow all bodies in the simulation to be stored inside of it labelled. When a label is created it would be assigned a portion of the vector:

LabelVector.push_back(this Object&) //Adding the body to the label vector
labelName=LabelVector[-1]

Then overriding the method differently when referring to either a single particle or set of particles or other body (such as facet or otherwise), which would allow specific functionality depending on which you're using:

//Inside a particle
label(string Name){//Some code//}

//Inside a facet body
label(string Name){//Some different code//}

The idea would be that you would have one universal format for labels, which could in turn let you have conditional statements to control how a label is treated, or use the convenience of referential transparancy and have functions within the classes of the bodies. For example:

//Assuming the label refers to a cloud
labelName.pos(x,y,z){//Some code//}

Could be set up to move every particle in the cloud using the center as a reference, while

//Assuming the label refers to a sphere
labelName.pos(x,y,z){//Some different code//}

Could be set up to move the sphere to a precise location, while keeping the syntax the same.

Again I may be incorrect, but I believe that using a system like this would lead to a more intuitive design.

As for the spaghetti coding, call me OCD but unless everything is in a nice precise order, I find it quite unpleasant. Or at least my code seems nice to me :P. I'm fairly new to python and DEM software though, so I'm still fighting the learning curve. If you don't mind me asking, what version of C++ are you using?

def Cheers():
   print "Zachary"

Hi,

having all objects a label (stored inside the object, and making it accessible by that label) is not really possible. First it would be quite some overhead, as many objects (like contacts) are created and destroyed very quickly, and they would all carry empty lables around uselessly. Second, an object does not know which simulation it belongs to (and labels are per-simulation, I tried to avoid global objects as much as possible), so there is no place to register the label (an exception is with engines, which may define the label attribute label internally and are put in S.lab automatically).

For the methods which are common to many types, well, that is what virtual methods do, or even methods with same signature accross unrelated types in Python. Python will call whatever can be called, and try to give it the arguments you want. Or did I misunderstand something?

In most DEM simulation, you don't have to move particles one by one... You have the physics to do that for you, or motion constraints or other funny objects to help you. I did not mean you write spaghetti code ;) Just to say there are sometimes very concise way to do things, and people don't know about them and write more code than necessary. You know, the basic falling sphere simulation is a one-liner:

from woo.dem import *; from woo.core import *; import woo; S=Scene(fields=[DemField(gravity=(0,0,-9.81),par=[Wall.make(0,axis=2),Sphere.make((0,0,.2),.2)])],engines=DemField.minimalEngines(damping=.2));

C++ version? I try to stick with the c++11 standard for portability reasons. I compile with clang (faster compilation, but no OpenMP) and g++ (slower to compile, but OpenMP).

v.