If your input (specifically, the input of the "center" argument) is in *float3
*format, then it outputs a vector of* float3*s. If your input is in the
format of a vector of 3 *float*s (like {1.0, 2.0, 3.0}), then it outputs a
vector of vectors that each contain 3 *float*s.
Ruochun
On Wednesday, July 3, 2024 at 8:06:02 AM UTC+8 [email protected] wrote:
> 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/c177c0cc-5820-4231-9dc7-ff0ae4c86c82n%40googlegroups.com.
