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 <https://www.sciencedirect.com/science/article/pii/S001046552400119X?via%3Dihub> . 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 On Tuesday, October 1, 2024 at 1:03:59 AM UTC+8 [email protected] wrote: > 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/98d551dd-5961-4860-9092-0b8f82383c16n%40googlegroups.com.
