You are right. In fact, the scenario i would like to model is that the impact of a rock block onto a palte after a freefall. I would like to set a initial velocity for the rock block according to the freefall height. So, how to set a initial velocity?
Thank you, Weigang On Thursday, June 27, 2024 at 12:54:00 PM UTC+8 Ruochun Zhang wrote: > That depends on whether we are on the same page about the concept of > prescribing velocity. You understand that when the particles come in > contact with the plate, they cannot keep whatever velocity you assigned > them before, if you respect the contact force. So you either respect the > contact force or do not respect it. By assigning a prescribed velocity to a > family, you choose not to respect the contact force's influence on the > entities, and always enforce this velocity. > > What I understand that you wish to achieve is to ensure the particles have > a certain velocity at the moment they come in contact with the plate. That > is not a velocity prescription. That can instead be done in some other > ways. For example, initialize the simulation such that the particles are > touching the plate, and give the particles an initial velocity then start > the simulation. But I don't know if I understand what you wanted to do > correctly, > > Thank you, > Ruochun > > On Thursday, June 27, 2024 at 11:14:42 AM UTC+8 [email protected] wrote: > >> 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 [email protected] 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 [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/eb39317c-989b-442a-a218-1e3fe3e63003n%40googlegroups.com.
