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 On Thursday, September 26, 2024 at 11:38:02 PM UTC+8 [email protected] wrote: > 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 > > Il giorno mercoledì 25 settembre 2024 alle 05:27:08 UTC+2 Ruochun Zhang ha > scritto: > >> 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 >> >> On Wednesday, September 25, 2024 at 12:15:00 AM UTC+8 [email protected] >> wrote: >> >>> 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 >> >> -- You received this message because you are subscribed to the Google Groups "ProjectChrono" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/d9a58b35-5eda-46e0-98e7-7c483f08fbd8n%40googlegroups.com.
