You can *SetVel *to simulation entities, such as particles, before the 
simulation starts. You can for example see how it is used at line 150 of 
*DEMdemo_GRCPrep_Part1*.

Thank you,
Ruochun

On Thursday, June 27, 2024 at 3:03:00 PM UTC+8 [email protected] wrote:

> 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/1d70fcb3-a90e-49d6-87c2-c9999ddf384dn%40googlegroups.com.

Reply via email to