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 Il giorno venerdì 27 settembre 2024 alle 18:06:04 UTC+2 Ruochun Zhang ha scritto: > 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/eebd76cb-8ab7-4b54-a8c1-5adb497cae82n%40googlegroups.com.
