DEM_E wildcards getter

[Sabrina Lanfranco]

Hi,
Is there a way to log the wildcards' values at each simulation instant?
For example, log charges value "Q" in the Electrostatic example.

Thanks in advance for your help!
Sabrina

[Ruochun Zhang]

Hi Sabrina,

If you want to get a vector so you can directly use in your script, then you can use DEMTracker's method GetGeometryWildcardValues to get "Q". Note that since "Q" is a geometric wildcard (associated with individual spheres, triangle facets etc., but not a owner) and a tracker is tracking a owner, this method only gets you the geometric wildcard values (can be a vector of length more than 1, depending on the components this owner has) associated with this owner.

On the other hand, owner wildcard is probably more convenient to use, if it fits your purpose. DEMSolver's method GetFamilyOwnerWildcardValue and DEMTracker's method GetOwnerWildcardValue can easily help you get the owner wildcard value.

If you are fine with writing the wildcard values to a file, then in a SetOutputContent call, you can enable "GEO_WILDCARD", so in a subsequent WriteSphereFile call, "Q" will be written to the output file. You can see an example of this (albeit it's about outputting an owner wildcard) in DEMdemo_Indentation.cpp.

Thank you!

Ruochun

[Sabrina Lanfranco]

Hi Ruochun,
Thank you for the help!

In addition to the charges I need to calculate the potential and electric field in the force_model (to take advantage of CUDA): I was thinking of using geometric wildcards or is it better to use owner wildcards?
I ask this because I didn't fully understand the owner wildcards' properties/functionalities.

Sabrina

[Ruochun Zhang]

Hi Sabrina,

The two types of "wildcard"s are both for assigning extra properties to simulation entities. The "owner" type is associated with owners (clumps, meshes etc.) and the "geo" type is associated with geometries which are owners' components (spheres, triangle facets etc.).

Say you'd like to associate extra properties to all the particles and all the particles you have in the simulation are spheres (that is you have one-sphere templates only), then you can just use the owner wildcard, since using the other won't give any more benefits. 

If you have multi-sphere clumps in the simulation, then it's a bit trickier. Let's first assume you choose to use the geometry wildcard, then you are associating electric charges with the component spheres in each clump. Because of that, three things will happen. One is that you have finer control over how electric charges should be distributed in a clump (some component spheres can be assigned more charges if they represent the sharper part of the particle, for example). 

The second is that you don't have to worry about double-counting the eletrostatic force pairs, compared to using owner wildcards. This is because in DEME, the contacts are resolved using geometry entity pairs (recall that it means sphere--sphere pairs, sphere--triangle pairs etc., not clump--clump pairs). Say your custom force model is simply applying an electrostatic force for each pair of spheres that are close enough, and all particles in your simulation are two-sphere clumps, then up to four contact pairs could be acting between two clumps. Using geometry wildcards, this is probably fine (each component sphere should only have 1/2 of the particle's total charge anyway); but if you used owner wildcards, then a force up to four times larger than normal could be applied, if you don't cleverly pre-process the wildcard numbers (one "clever" way might be artificially let the owner only take half of the charge that it really has, as a numerical trick, if you would).

The third one is that it might be easier to incorporate the transfer of electric charges in the force model. Again, when you write your custom force model detailing how the charges should be transferred, you are writing your policy for each sphere--sphere contact, and this might go a bit better if your wildcard is associated with the geometries. I'll provide another example scenario: Suppose you are using an owner wildcard to record the charges, and the policy you write in the force model is that the charges flow between the two particles at a certain rate at each contact, then if somehow the two particles have two physical contact points (which can easily happen if they have non-convex shapes), then the rate of charge exchange will be two times higher than when they have only one contact point. This may or may not be physical; it depends on the model and the actual particle shape you use.

You probably noticed that the owner wildcards could be used in the clump case as well, if some simplification can be allowed. For example, if your particles are in general convex and small (so the shape's effect on charge distribution is not important), then the first and third "problems" might go away. And the second one might not be an issue if you account for it in designing your forced model. So in the end, which one to use is up to you.

Let me know if you have further questions,

Ruochun

[Sabrina Lanfranco]

Thank you Rouchun for your time.

As I said I wanted to calculate the potential (using Poisson's equation), but to implement it via Gauss-Seidel or any other method, I wanted to better understand how the force_model is executed inside the kernel. From what I understand, the kernel is launched with a 1D block with N threads, correct? Additionally, I need to assign the charges Q differently based on the "layer" they are in, but with the current structure of the force_model, is there a way to distinguish the layers of the terrain?

Sabrina

[Ruochun Zhang]

It is correct that the kernel is launched with 1D blocks with N threads (the user can control this N via SetForceCalcThreadsPerBlock, and the default is 256). However, in general the user does not have to change or worry about this configuration.

If you would like to assign Q in the force model (meaning that you don't just want to assign an initial Q; you need them to dynamically update during simulation), then you can use the user-referable variables, namely AOwnerPos, BOwnerPos, bodyAPos, and bodyBPos, to extract the contact entities' location in defining your force model. For a complete list of the user-referable variables, you can refer to Table 2 of the DEME paper.

This can also be done on the host. For example, at every 10th time step, you can use a tracker to get the locations of all the owners (particles), then calculate their corresponding Q on the host, then use the tracker's SetOwnerWildcardValues method to set the computed values back, then resume the computation.

Thank you,

Ruochun