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/a013f0b2-467b-45c6-8f46-7fb7277aab28n%40googlegroups.com.
