Hi Ruochun, After removing the line which prescribe the linear motion, the particles can contact with the plate. However, if we have to prescribe a velocity for the particles, where should we add this line?
Thank you, Weigang On Friday, June 21, 2024 at 3:12:06 PM UTC+8 Ruochun Zhang wrote: > Hi Weigang, > > This is because you prescribed the linear motion of family 1 (which is for > all the particles) to be -1.0. When the velocity is prescribed, the > simulation entities won't accept the influence of physical contacts, and > will keep the prescribed velocity no matter what. This is exactly what we > see in the simulation. Removing that line should fix it. You probably meant > to add an initial velocity. > > Ruochun > > > > On Friday, June 21, 2024 at 9:05:11 AM UTC+8 weigan...@gmail.com wrote: > >> Hi Ruochun: >> >> The script is attached below. >> >> Thank you, >> Weigang >> >> On Thursday, June 20, 2024 at 7:27:35 PM UTC+8 Ruochun Zhang wrote: >> >>> 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 weigan...@gmail.com >>> 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 weigan...@gmail.com >>>>> 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 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/953c6f17-86d3-4e7b-aaf9-3d159047a751n%40googlegroups.com.
