I assume you are doing it via a custom force model. In that case, this problem is very similar to the exact demo we provided (which runs). You have to tell us what you changed in order for us to give suggestions.
Thank you, Ruochun On Thursday, June 20, 2024 at 6:55:10 PM UTC+8 [email protected] wrote: > Hi Ruochun, > > I am currently modelling the impact of a rock block against a plate. > However, as shown below, the spheres penetrate through the plate without > any contact with the plate. Could you give some suggestions? > [image: 微信图片_20240620185350.jpg] > > Thank you, > Weigang > > On Thursday, June 20, 2024 at 5:02:38 PM UTC+8 Ruochun Zhang wrote: > >> Hi Weigang, >> >> Yes. And that's exactly what we did in the fracture demo to begin with, >> is it not? >> >> Thank you, >> Ruochun >> >> On Thursday, June 20, 2024 at 3:07:07 PM UTC+8 [email protected] wrote: >> >>> Hi Ruochun, >>> >>> Do you mean that we can add a if statements in the >>> ForceModelWithFracture.cu to differentiate types of contacts? >>> >>> Thank you, >>> Weigang >>> >>> >>> >>> On Thursday, June 13, 2024 at 8:30:45 PM UTC+8 Ruochun Zhang wrote: >>> >>>> 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 [email protected] >>>> 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 [email protected] >>>>>> 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 <[email protected]> >>>>>>>> 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 [email protected] >>>>>>>>> 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 [email protected] >>>>>>>>>>> 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 >>>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>>> [email protected] 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 [email protected]. >>>>>>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/f2813831-775d-470a-ab11-bd317f33e622n%40googlegroups.com.
