Currently, DEM-Engine custom model functionality permits only one script, meaning that in principal, you are writing a unified force model that goes for sphere-sphere, sphere-boundary, *and *sphere-mesh. Just think of the sphere-compressor contact as a special case, which is the contact between a normal sphere and an infinitely-large sphere.
About enforcing different models for different objects, you can associate different objects with respective family numbers, then use if statements to differentiate types of contacts. I talked about this in one of the earlier replies in this thread, please go back and have a look. Thank you, Ruochun On Thursday, June 13, 2024 at 1:31:37 PM UTC+8 weigan...@gmail.com wrote: > Hi Ruochun, > > Thank you for your reply. In fact, I am puzzled that there is not any > sentence in the Fracture-Box demo to declare the contact model between > spheres and the compressing plate. So, how to declare the contact model, > especially for the case in which there has been another contact model, such > as the ForceModelWithFracture.cu? > > Thank you, > Weigang > > On Thursday, June 13, 2024 at 12:03:52 AM UTC+8 Ruochun Zhang wrote: > >> Hi Weigang, >> >> Note that in general, if you use a custom force model, then that model >> alone is used, there is no fallback so I wouldn't call that anything has >> "defaulted" to Hertz–Mindlin. Specific to the Fracture-Box demo, it's just >> that the force model (ForceModelWithFracture.cu) is written in a way that >> when the bond between two particles breaks, the "else" branch of that big >> if statement is executed, and something similar to Hertz–Mindlin is >> enforced. >> >> I said it's similar since it's not a pure spring–damper model now, it's a >> spring–damper model with the resting location (zero-force location) being >> the penetration depth the moment when the bond broke. This implementation >> avoids a potential problem with a pure spring–damper model: Without the >> adjusted resting location, a newly broken-away pair of particles would see >> the bond suddenly gone but there were still left-over penetration, >> therefore immediately pushing each other away with high velocity, resulting >> in non-physical results. Shout-out to Bona for implementing this. >> >> Thank you! >> Ruochun >> >> >> On Wednesday, June 12, 2024 at 8:33:55 PM UTC+8 weigan...@gmail.com >> wrote: >> >>> Hi Ruochun, >>> >>> Thank you for your great work. The demo now is runs well. I have a >>> question about the Fracture-Box demo. After the bond between two particles >>> breaks, is it right that the contact model between them change defaultly >>> from ForceModelWithFracture to Hertz–Mindlin model? >>> >>> Thank you, >>> Weigang >>> >>> On Friday, May 31, 2024 at 8:05:24 PM UTC+8 Ruochun Zhang wrote: >>> >>>> Hi Weigang, >>>> >>>> The problem appears to be fixed now. Please pull the newest main branch >>>> and try the fracture demo again. I suggest you do a clean rebuild from an >>>> empty directory, because only a force model file is changed and if you >>>> just >>>> "make", cmake probably thinks nothing needs to be done. Or you can simply >>>> manually copy the modified cu file over to the appropriate location in the >>>> build folder. >>>> >>>> The problem was that we left an uninitialized variable in the force >>>> model file. On data center cards, the compiler zeros it out automatically, >>>> but on consumer cards it does not. We therefore missed it initially. >>>> Should >>>> be all good now. >>>> >>>> Thank you, >>>> Ruochun >>>> >>>> >>>> On Tue, May 28, 2024, 11:00 PM Ruochun Zhang <ruoc...@gmail.com> wrote: >>>> >>>>> Hi Weigang, >>>>> >>>>> It's not like recommending a card; rather, if you happen to have a >>>>> data center card available (A100, A5000 etc.), you can circumvent this >>>>> problem for now by using them. Otherwise, let's hope we find a solution >>>>> very soon, or at least find a workaround. We'll keep you posted. >>>>> >>>>> Thank you, >>>>> Ruochun >>>>> >>>>> On Monday, May 27, 2024 at 7:27:10 PM UTC+8 weigan...@gmail.com wrote: >>>>> >>>>>> Hi Ruochun, >>>>>> >>>>>> My card is indeed a gaming card NVIDIA GeForce RTX 2070 Super. Could >>>>>> you recommend a card? >>>>>> >>>>>> Thanks, >>>>>> Weigang >>>>>> >>>>>> On Saturday, May 25, 2024 at 10:44:17 PM UTC+8 Ruochun Zhang wrote: >>>>>> >>>>>>> Hi Weigang, >>>>>>> >>>>>>> I would like to answer Question 2 first. You can use variables >>>>>>> *AOwnerFamily >>>>>>> *and *BOwnerFamily *to refer to clump (or owner) A's and clump B's >>>>>>> family numbers directly in the force model. So you can write *if >>>>>>> *statements >>>>>>> that treat each case accordingly. This is mentioned in the DEME paper: >>>>>>> You >>>>>>> can check out Table 2. >>>>>>> >>>>>>> For Question 1, the situation is more complicated. We are actually >>>>>>> able to reproduce the problem you encountered (simulation freezing), >>>>>>> but on >>>>>>> consumer/gaming cards only. It runs perfectly on data center cards and >>>>>>> that's what we used for generating this experiment, therefore it did >>>>>>> not >>>>>>> appear a problem for us. It's likely due to different GPU architectures >>>>>>> running the same code differently, we'll try to find a solution and let >>>>>>> you >>>>>>> know in the following days, so stay tuned. By the way, you are using a >>>>>>> gaming card to run the simulations, correct? >>>>>>> >>>>>>> Thank you, >>>>>>> Ruochun >>>>>>> >>>>>>> On Friday, May 24, 2024 at 8:47:00 AM UTC+8 weigan...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> Thank you for your reply! I have two questions about the demo >>>>>>>> "DEMdemo-Fracture-Box". >>>>>>>> >>>>>>>> (1) After i have run this demo for one day, there is still nothing >>>>>>>> outputed. Is it fact that the DEME will run a long time once a >>>>>>>> fracture >>>>>>>> model is used? >>>>>>>> >>>>>>>> (2) How to tell DEME the contact force models between different >>>>>>>> familys? I did not see any snippet which undertakes this work, >>>>>>>> although the >>>>>>>> demo has at least two kinds of contact force model. The question i >>>>>>>> really >>>>>>>> want to ask is that, if we have more than three familys in our model >>>>>>>> and >>>>>>>> there are more than two familys consist of spherical particles, how to >>>>>>>> tell >>>>>>>> DEME the contact force model between different familys, and tell DEME >>>>>>>> the >>>>>>>> contact force model between the particles of a family in the same time. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Weigang >>>>>>>> >>>>>>>> On Thursday, May 23, 2024 at 10:10:14 PM UTC+8 Ruochun Zhang wrote: >>>>>>>> >>>>>>>>> No. That's because the *sphere components* in a clump are just >>>>>>>>> shape representations, and they have no physics, only material >>>>>>>>> properties. >>>>>>>>> If they did have interaction with each other then every clump >>>>>>>>> would've >>>>>>>>> immediately exploded upon simulation starting. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Ruochun >>>>>>>>> >>>>>>>>> On Thursday, May 23, 2024 at 12:16:32 PM UTC+8 weigan...@gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Ruochun, >>>>>>>>>> >>>>>>>>>> Thank you for your reply! I have a question about the clump. Do >>>>>>>>>> the particles in a clump interact with each other via any force >>>>>>>>>> model? >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Weigang >>>>>>>>>> >>>>>>>>>> On Monday, May 20, 2024 at 10:26:03 PM UTC+8 Ruochun Zhang wrote: >>>>>>>>>> >>>>>>>>>>> Hi Weigang, >>>>>>>>>>> >>>>>>>>>>> Yes. Again, DEME only cares about the position and radius of >>>>>>>>>>> the initial spheres, so you can supply it however you want. If you >>>>>>>>>>> have a >>>>>>>>>>> file that records this information using your own format, then the >>>>>>>>>>> easiest >>>>>>>>>>> thing is to have your own C++ or Python script that reads it into >>>>>>>>>>> arrays >>>>>>>>>>> and then feeds them to the solver. If your file shares the >>>>>>>>>>> format with DEME's standard clump output file, or your file is >>>>>>>>>>> simply the >>>>>>>>>>> output of *WriteClumpFile*, then you can conveniently load >>>>>>>>>>> clump positions and orientations by *ReadClumpXyzFromCsv *and >>>>>>>>>>> *ReadClumpQuatFromCsv *(examples are in GRCPrep_Part1 and 2). >>>>>>>>>>> Note that currently, sphere radius cannot be read from standard >>>>>>>>>>> clump >>>>>>>>>>> output files since it's part of the clump template information thus >>>>>>>>>>> not in >>>>>>>>>>> the clump output. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Ruochun >>>>>>>>>>> >>>>>>>>>>> On Monday, May 20, 2024 at 12:56:56 PM UTC+8 weigan...@gmail.com >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>> >>>>>>>>>>>> I would like to generate a block which consists of a assembly >>>>>>>>>>>> spheres. Is it possible to generate the block by other code, and >>>>>>>>>>>> then load >>>>>>>>>>>> it into DEM-Engine via a file containg the informations (such as >>>>>>>>>>>> position >>>>>>>>>>>> and radius) of the spheres? >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> Weigang >>>>>>>>>>>> >>>>>>>>>>> -- >>>>> 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 projectchron...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/projectchrono/1910af21-d1e3-43dd-a779-0c229e6150a6n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/projectchrono/1910af21-d1e3-43dd-a779-0c229e6150a6n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- 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 projectchrono+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/f4f88237-422b-498f-bdf7-82ee762dd322n%40googlegroups.com.
