Hi Ruochun,

Thank you for your reply! Could you tell us about the data format of the 
input xyz generated by the HCPSampler?

Thank you,
Weigang

On Monday, July 1, 2024 at 4:37:11 PM UTC+8 Ruochun Zhang wrote:

> 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/5116b468-72af-40e8-a252-fe4dd1d0859en%40googlegroups.com.

Reply via email to