Hi Ruo chun,
I have a question that how to output the mass, the force and torque of
particles into the output file?
Thank you!
Weigang
On Wednesday, July 3, 2024 at 11:35:21 AM UTC+8 Ruochun Zhang wrote:
> 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 visit
https://groups.google.com/d/msgid/projectchrono/04d47a97-2b72-4157-b9a0-cbe09548107an%40googlegroups.com.
