Hi, ruochun, thank you for your help sincerely! After some attempts, I
succeeded in using material-based properties. I realized that I should use
functions in ChSystemGpuMesh:: instead of ChSystemGpu::. I will continue to
learn it for a few days, and I will try to use DEM-Engine if I get the
chance later. Thank you very much for your help!
在2023年9月9日星期六 UTC+8 18:37:20<Ruochun Zhang> 写道：
> Hi,
>
> To answer the questions:
>
> 1. They can be different. In that test, I didn't choose to set them
> differently though. Is there anything that makes you concerned about this
> choice?
>
> 2. Mesh material properties are specified by those S2M parameters.
> Compared to real-world materials, the properties we use tend to be much
> less stiff. This is to make the simulation easier to run, and it is a
> common practice.
>
> 3. and 4. are very related, I'd like to talk about them together. The
> short answer is that in your case you should use material-based properties,
> instead of specifying stiffness and damping numbers. An example of using
> material-based properties is demo_GPU_ballDrop. There, you specify Young's
> modulus and Poisson's ratio and friction coefficient and such, and the
> solver calculates the rest without you worrying about it. For aluminum or
> titanium, you should know those material properties. But I should notify
> you that using true Young's modulus could necessitate an extremely small
> time step size for your simulation to run, and it is questionable whether
> using true properties means much for increasing the fidelity of your
> simulations.
>
> I admit that Eq.18 and Eq.19 make the text a bit less intuitive to
> understand. Eq.18 and Eq.19 basically say that when you set normalStiffS2S,
> normalDampS2S and such in the code, you are setting \hat{k} and
> \hat{\gamma}, rather than k and \gamma. We need to convert \hat{k} and
> \hat{\gamma} to k and \gamma to understand the physics, because Eq.3 and 4
> use k and \gamma. But Chrono::GPU uses a nonlinear force model where the
> force is proportional to \delta^{1.5}, rather than \delta. That is to say
> the k and \gamma in Eq.3 and 4 are not independent of \delta. And indeed, k
> and \gamma contain a \delta^{0.5} in them, as indicated in Eq.18 and Eq.19.
> Also, k and \gamma are dependent on R and m, meaning that smaller particles
> are effectively stiffer given the same material, and this is a part of the
> force model. As for how to convert Young's modulus and such to k and
> \gamma, as indicated in the paper you are referred to *Fleischmann, J.;
> Serban, R.; Negrut, D.; Jayakumar, P. On the importance of displacement
> history in soft-body contact models. J. Comput. Nonlinear Dyn. 2016, 11,
> 044502*. Using this paper you can probably figure out a stiffness param
> k' which is in front of \delta^{1.5}, then you know k' is independent of
> \delta (since we use a force model proportional to \delta^{1.5}), and then
> based on the particle size and mass, you can figure out \hat{k} which is
> completely independent, and the solver asks for \hat{k}.
>
> After reading all these, you probably already decided to use the
> material-based model. I would like to comment that the way \hat{k} and
> \hat{\gamma} were implemented is more force model-oriented, without
> considering much about the implications on materials (mindset: as long as
> we can explain how they make into the force model, it is fine). This is
> related to the fact that the stiffness and damping choices in many
> situations are numerical viability-driven, rather than trying to capture a
> specific material. You probably don't believe this now, but faithfully
> setting the true stiffness and damping, in some DEM simulations, makes them
> much more difficult to run while offering little accuracy boost for the
> application you try to simulate.
>
> One last thing: If you use DEM-Engine, the only default model is
> material-based, so know that if you switch to that tool you don't have to
> worry about all these. Also note that the friction coefficient between two
> materials, if you use the material-based model in Chrono::GPU, will always
> be the larger one between the two. Whereas in DEM-Engine, you can specify
> explicitly the friction coefficient between any pair of two materials
> involved in a contact.
>
> Ruochun
>
> On Monday, September 4, 2023 at 5:14:27 AM UTC-5 [email protected] wrote:
>
>> Hi, ruochun
>>
>> Thank you for your help sincerely!
>>
>> I still have some problems in the material, regarding the simulation
>> parameters. Based on your last suggestion, I tried to use the material-based
>> force model but still failed for some reasons. So I continued to set the
>> parameters from .json like the demos in the Chrono::GPU. I also read some
>> papers about Chrono, including the one you mentioned before: Chrono::GPU: An
>> Open-Source Simulation Package for Ganular Dynamics Using the Discrete
>> Element Method.
>>
>>
>> 1. I notice that the parameter of S2S、S2W、S2M are same, such as
>> normalStiffS2S、normalStiffS2W、normalStiffS2M. I am confused because I think
>> the granular material should be different to the mesh material, so why S2S
>> and S2M are same?
>> 2. I don't know what the material of the mesh model in the demos are,
>> such as the mixer in the demo_GPU_mixer.cpp and the ball in the
>> demo_GPU_ballCosim.cpp
>>
>> 3. I want to modify the parameters to simulate the simulation between
>> different metals and particles, such as aluminum and titanium. Do you know
>> how I should modify these parameters including
>> normalStiff、normalDamp、tangentStiff、tangentDamp and static_friction_coeff?
>> 4. When reading the paper, I have some questions about this paper
>> Chrono::GPU: An Open-Source Simulation Package for Ganular Dynamics Using
>> the Discrete Element Method.
>> You taught me once before that the unit of normal stiffness is *g/s²* (the
>> same as *k* in Eq. 3), and the unit of normal damping is *1/s* (similar
>> to /gamma in Eq. 3, but Chrono ::GPU's damping will be multiplied by
>> particle mass to form /gamma). I feel difficult to understand Eq.18 and
>> Eq.19 and the text described it above and below. δn means small penetration
>> which I understand it as a variable that tends to 0. I'm wondering how it
>> convert to the parameter we need, namely the stiffness and damping
>> coefficients kn, kt, γn, and γt.
>>
>> Sorry to bother you, but my core question is the third one. The other
>> questions came up when I was exploring its solutions. I'd appreciate very
>> much it if you knew it. And thank you so much for all the help you've been
>> giving me!
>>
>> part of .json:
>> "sphere_radius": 1,
>> "sphere_density": 1,
>>
>>
>> "normalStiffS2S": 1e8,
>> "normalStiffS2W": 1e8,
>> "normalStiffS2M": 1e8,
>>
>> "normalDampS2S": 10000,
>> "normalDampS2W": 10000,
>> "normalDampS2M": 10000,
>>
>> "tangentStiffS2S": 1e8,
>> "tangentStiffS2W": 1e8,
>> "tangentStiffS2M": 1e8,
>>
>> "tangentDampS2S": 2000,
>> "tangentDampS2W": 2000,
>> "tangentDampS2M": 2000,
>>
>> "static_friction_coeffS2S": 0.5,
>> "static_friction_coeffS2W": 0.5,
>> "static_friction_coeffS2M": 0.5,
>> 在2023年3月12日星期日 UTC+8 15:42:59<Ruochun Zhang> 写道：
>>
>>> Hi,
>>>
>>> You are right about re-setting the material properties after loading a
>>> checkpoint. In fact, I suggest you just pretend that the checkpoint file
>>> stores particle size and location information only, and set everything one
>>> more time should you need to restart a simulation. When you say there is no
>>> force, do you mean *CollectMeshContactForces *returns 0 force always?
>>> If that is the case then you probably should ensure that you re-set the
>>> SPH2MESH material properties as well, since I didn't see related lines in
>>> your snippet. And then ensure that the mesh indeed touches the granular
>>> material when you measure. If you mean you try to output a contact pair
>>> info file and it's empty then you probably need to manually call
>>> *SetRecordingContactInfo(true)*.
>>>
>>> As you noted before, DEME <https://github.com/projectchrono/DEM-Engine>
>>> is currently the DEM package being developed and maintained. Just letting
>>> you know that it now has some proper introduction added to the readme
>>> document that you may want to check out.
>>>
>>> Thank you,
>>> Ruochun
>>>
>>> On Saturday, March 11, 2023 at 2:22:26 AM UTC-6 [email protected] wrote:
>>>
>>>> Hi, Ruochun
>>>> Thank you for your help sincerely!
>>>> Now, I am trying material-based force model in my simulation which is
>>>> similar to the demo_GPU_ballcosim.cpp. There are two simulations. When
>>>> run_mode == 0, this run is particle settling phase. After it is done, I
>>>> will have a settled bed of granular material and a checkpoint file to
>>>> store
>>>> this state through gpu_sys.WriteCheckpointFile(checkpoint_file). Then, we
>>>> change run_mode from 0 to 1, load the checkpoint file and start the second
>>>> simulation.
>>>> Now, I am trying to use material-based force model instead of using
>>>> SetKn_SPH2SPH、SetGn_SPH2SPH、SetGt_SPH2SPH...
>>>> I use the setMatreialProperty from demo_GPU_ballDrop. In the setting
>>>> phase, I still use gpu_sys.WriteCheckpointFile(checkpoint_file) to get the
>>>> cheeckpoint file. I notice that in the checkpoint file, the parameter such
>>>> as K_n_s2s、G_t_s2w、G_t_s2m..are 0. So, in the second simulation, the
>>>> measured force is always 0. It looks as if there is no collision and the
>>>> simulation goes very fast. To solve the problem, I use setMatreialProperty
>>>> again in the second simulation, after load the checkpoint file. However,
>>>> it
>>>> didn't work. But the simulation runs at normal speed. I am confused about
>>>> this and could you help me? Than you very much!
>>>>
>>>> void setMatreialProperty(ChSystemGpuMesh& gran_sys) {
>>>> double cor_p = 0.5; // use cor_p = 0.9 for sand or glass beads
>>>> double cor_w = 0.5;
>>>> double youngs_modulus = 1e8;
>>>> double mu_s2s = 0.16;
>>>> double mu_s2w = 0.45;
>>>> double mu_roll = 0.09;
>>>> double poisson_ratio = 0.24;
>>>>
>>>> gran_sys.UseMaterialBasedModel(true);
>>>> gran_sys.SetYoungModulus_SPH(youngs_modulus);
>>>> gran_sys.SetYoungModulus_WALL(youngs_modulus);
>>>> gran_sys.SetRestitution_SPH(cor_p);
>>>> gran_sys.SetRestitution_WALL(cor_w);
>>>> gran_sys.SetPoissonRatio_SPH(poisson_ratio);
>>>> gran_sys.SetPoissonRatio_WALL(poisson_ratio);
>>>> //gran_sys.SetRollingMode(CHGPU_ROLLING_MODE::SCHWARTZ);
>>>> gran_sys.SetRollingMode(CHGPU_ROLLING_MODE::NO_RESISTANCE);
>>>> gran_sys.SetRollingCoeff_SPH2SPH(mu_roll);
>>>> gran_sys.SetRollingCoeff_SPH2WALL(mu_roll);
>>>> gran_sys.SetFrictionMode(CHGPU_FRICTION_MODE::MULTI_STEP);
>>>> gran_sys.SetStaticFrictionCoeff_SPH2SPH(mu_s2s);
>>>> gran_sys.SetStaticFrictionCoeff_SPH2WALL(mu_s2w);
>>>> }
>>>>
>>>>
>>>> 在2023年1月18日星期三 UTC+8 06:16:18<Ruochun Zhang> 写道：
>>>>
>>>>> Hi,
>>>>>
>>>>> Simulations failing randomly is not a good sign... Perhaps the
>>>>> simulation parameters are just on the verge of being valid. Or, it's also
>>>>> possible that Chrono::GPU has some suspicious memory operations that
>>>>> cause
>>>>> troubles in some scenarios such as yours. But I cannot be sure. To answer
>>>>> your questions...
>>>>>
>>>>> 1. Yes, this package is dimensionless. That means when it reads a
>>>>> file, it reads numerics only, not unit systems. Honestly, I don't
>>>>> think
>>>>> your mesh file has a unit system baked into it either. Once it is
>>>>> exported
>>>>> from your CAD system, there is no way to know the unit system you
>>>>> used, nor
>>>>> does Chrono care about it. So if you created mesh in your CAD using an
>>>>> *mm*-based metric system and then in the simulation set the sphere
>>>>> radius to be 1, thinking it means 1cm, then this is the inconsistency
>>>>> I
>>>>> talked about earlier. The way you are doing it implicitly makes this
>>>>> "1" in
>>>>> sphere radius mean 1mm. There is no such thing as a switch in
>>>>> Chrono::GPU
>>>>> that changes the way it interprets unit systems, the only thing that
>>>>> can be
>>>>> relied on is that you do the scaling and unification of unit systems
>>>>> properly under the hood.
>>>>> 2. Chrono::GPU cannot do that. But the new DEM-Engine can do that.
>>>>> 3. In this case, you should use the material-based force model (by
>>>>> the way, the default force model in DEM-Engine is also
>>>>> material-based).
>>>>> It's best if you check out the *demo_GPU_ballDrop *example. There
>>>>> you can see that you need to *UseMaterialBasedModel(true)* and
>>>>> then set the material properties, such as Young's modulus, etc.
>>>>>
>>>>> Thank you,
>>>>> Ruochun
>>>>>
>>>>> On Tuesday, January 17, 2023 at 7:31:26 AM UTC-6 [email protected]
>>>>> wrote:
>>>>>
>>>>>> Hi, Ruochun
>>>>>> The last issue about failure in simulation is almost solved, I think
>>>>>> the model is still too complex for the simulation. Finally, I remake the
>>>>>> 3d
>>>>>> model, for example by removing the sharp tips and I reduced 80
>>>>>> percentage triangles of the curved surface in the stl. Also, I find
>>>>>> there
>>>>>> is a probability that the simulation will fail because I sometimes
>>>>>> retest
>>>>>> and it gets better.
>>>>>> At the same time, I have some other questions and I really appreciate
>>>>>> your help .
>>>>>> 1.In your previous answer, you told me that Chrono is dimensionless
>>>>>> and in Chrono GPU, the length is usually assumed to be in *cm *(no
>>>>>> demo uses *mm *as its length unit).[image: 60mm.png]However, I load
>>>>>> this blue mesh in the simulation, whose height is 60mm, and I don't
>>>>>> transform：
>>>>>> float trans = 1.f;
>>>>>> spoon_mixer_mesh->Transform(ChVector<>(0), ChMatrix33<>( trans ));
>>>>>> But I set "sphere_radius" 1 which I did't make change in
>>>>>> *demo_GPU_ballcosim.json*, and the simulation as the picture make
>>>>>> me a little confused.
>>>>>> 2.Can chrono's simulation obtain the force at each different contact
>>>>>> point between the mesh and the particle? *CollectMeshContactForces*
>>>>>> should
>>>>>> be a measurement of the combined force.
>>>>>> 3.If I want to simulate a specific particle material, such as moon
>>>>>> soil or cement, can you give me an idea on how to modify the parameters
>>>>>> of
>>>>>> the particle, because I see a lot of parameters such as normalStiffS2S
>>>>>> static_friction_coeffS2S..... and I feel a bit confused. I feel like I
>>>>>> should read some papers describing these material, but how should I
>>>>>> relate
>>>>>> them to the parameters in the simulation?
>>>>>> Thank you very much again!
>>>>>> 在2023年1月2日星期一 UTC+8 13:35:08<Ruochun Zhang> 写道：
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> OK this mesh has an extremely sharp tip. That is a demanding physics
>>>>>>> in terms of numerical simulations, you agree? DEM is based on geometry
>>>>>>> penetration/overlap. Capture that microscopic particle--mesh overlap at
>>>>>>> that mesh tip is not easy, considering the geometry's own thickness.
>>>>>>> But
>>>>>>> other than that, the mesh seems valid.
>>>>>>>
>>>>>>> I don't know what exact simulation you are running but say if you
>>>>>>> are using particles of diameter 0.5cm or something and a Young's
>>>>>>> modulus
>>>>>>> 1e9, then I suppose the time step size has to be 1e-6s or something
>>>>>>> like
>>>>>>> that. It's likely that 1e-5 won't cut it. As for not getting any force
>>>>>>> readings, I suspects it's because the simulation crashes right after
>>>>>>> the
>>>>>>> mesh tip hits the particles and all the readings you got were before
>>>>>>> the
>>>>>>> particles and mesh made contact, so they're all 0.
>>>>>>>
>>>>>>> To quickly do a proof of concept you can make a similar mesh that
>>>>>>> does not have the tip, and repeat the simulation to see if it is
>>>>>>> easier. I
>>>>>>> even attached one, but it's just your mesh with the tip and most of the
>>>>>>> top
>>>>>>> structures removed. I imagine however, that tip is the key of the
>>>>>>> physics
>>>>>>> you are trying to simulate. If that is the case, eventually you have to
>>>>>>> add
>>>>>>> that part back, and go with small time step sizes since you have to.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Ruochun
>>>>>>>
>>>>>>> On Sunday, January 1, 2023 at 8:38:35 PM UTC-6 [email protected]
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi, Ruochun
>>>>>>>> Thank you for your help! The thing that I am sure is about the
>>>>>>>> using of CollectMeshContactForces, including the first argument.
>>>>>>>> Because
>>>>>>>> when I use 5e-5 time step, CollectMeshContactForces works correctly,
>>>>>>>> but
>>>>>>>> when I use 1e-5, force and torque are always 0.
>>>>>>>> So I sent you some meshes, expecting for check. Meanwhile, I'd like
>>>>>>>> to share how I got those reduced objs and stls. I used a 3D modelling
>>>>>>>> software called 'Meshmixer', it can reduce stls in a certain
>>>>>>>> percentage, I
>>>>>>>> set 50%. Before that, I export stls from the software 'soildworks'
>>>>>>>> with
>>>>>>>> minimum precision. Finally, I use solidworks again to import reduced
>>>>>>>> stls
>>>>>>>> and save as objs. In previous attempts, I have used the same approach
>>>>>>>> to
>>>>>>>> get stls and objs for simulation without problems. This time, I did
>>>>>>>> the
>>>>>>>> extra step of reducing the stl.
>>>>>>>> Thank you a lot!
>>>>>>>>
>>>>>>>> 在2023年1月2日星期一 UTC+8 07:37:43<Ruochun Zhang> 写道：
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I think you did the right thing in terms of resolving the
>>>>>>>>> too-many-triangles problem. C::GPU assumes that the triangles in the
>>>>>>>>> mesh
>>>>>>>>> you use are about the same size or bigger than the particle size. It
>>>>>>>>> has
>>>>>>>>> difficulty processing triangles that are much smaller than particles.
>>>>>>>>> The
>>>>>>>>> idea is that the mesh features preserved only by triangles that small
>>>>>>>>> will
>>>>>>>>> not benefit the simulation accuracy, since at that point the
>>>>>>>>> bottleneck for
>>>>>>>>> geometry representation accuracy becomes the particles/spheres.
>>>>>>>>>
>>>>>>>>> But you have to make sure your resultant reduced mesh is valid.
>>>>>>>>> The problem of not seeing forces or too many triangles in an SD could
>>>>>>>>> be
>>>>>>>>> because of that. The mesh needs to have correct outward normals, and
>>>>>>>>> should
>>>>>>>>> not have things like duplicate points/facets and such. If it is a
>>>>>>>>> small
>>>>>>>>> mesh, you can send it here and I could quickly check if it is
>>>>>>>>> alright.
>>>>>>>>> Also, when you use *CollectMeshContactForces *you have to make
>>>>>>>>> sure you are querying the correct mesh, meaning the first argument,
>>>>>>>>> the
>>>>>>>>> integer, needs to match the returned numbering of the mesh when you
>>>>>>>>> load
>>>>>>>>> the mesh into the system.
>>>>>>>>>
>>>>>>>>> The negative local pos or too-many-sphere-in-SD type of error is
>>>>>>>>> more common. Uninspiring as it sounds, it is most likely due to a
>>>>>>>>> diverged/destabilized simulation. What you should do is: Reduce the
>>>>>>>>> time
>>>>>>>>> step size further; add more damping; or reduce the stiffness. Just
>>>>>>>>> those
>>>>>>>>> things that make DEM easier to run. The unusual splash as shown in
>>>>>>>>> your
>>>>>>>>> picture is one common symptom of insufficient temporal resolution.
>>>>>>>>> But I
>>>>>>>>> cannot say for sure, since there could be other causes, such as bad
>>>>>>>>> meshes.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Ruochun
>>>>>>>>> On Sunday, January 1, 2023 at 6:34:24 AM UTC-6 [email protected]
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi, Ruochun. Happy new year!
>>>>>>>>>> Thank you for your help! Recently, I used other objs in the
>>>>>>>>>> simulation. At first, it showed the error 'xxx triangles are found
>>>>>>>>>> in one
>>>>>>>>>> of the SDs. The max allowance is 512' at the beginning of the
>>>>>>>>>> simulation. I
>>>>>>>>>> guess that the reason is my objs is too complex because it contains
>>>>>>>>>> curves
>>>>>>>>>> surface. I used stls to get objs. So to solve the error, I reduce my
>>>>>>>>>> stls
>>>>>>>>>> and objs.
>>>>>>>>>> After that, the simulation seems can be started. However, during
>>>>>>>>>> the simulation, there are many problems, 'Error! sphere xxxx has
>>>>>>>>>> negative
>>>>>>>>>> local pos in SDxxx...' I found your reply in the previous forum,
>>>>>>>>>> the "step_size" is 5e-5, when I change it to 1e-5, the force and
>>>>>>>>>> torque
>>>>>>>>>> got by gpu_sys.CollectMeshContactForces are always 0. And during the
>>>>>>>>>> simution, particles will become abnormal as the following picture,
>>>>>>>>>> but when
>>>>>>>>>> I used my previous objs, everything is correct.
>>>>>>>>>> As I said before, there are many problems, sometimes the error
>>>>>>>>>> is about slots, and sometimes error is still about too much
>>>>>>>>>> triangles
>>>>>>>>>> during the simution instaed of at the beginning.
>>>>>>>>>> I was really confused and spent several days, looking forward to
>>>>>>>>>> your help!
>>>>>>>>>>
>>>>>>>>>> [image: 1.jpg]
>>>>>>>>>>
>>>>>>>>>> 在2022年12月11日星期日 UTC+8 12:49:43<Ruochun Zhang> 写道：
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Chrono is dimensionless. So as you noted, there is an underlying
>>>>>>>>>>> consistent set of units. In Chrono GPU, the length is usually
>>>>>>>>>>> assumed to be
>>>>>>>>>>> in *cm *(no demo uses *mm *as its length unit), the mass is
>>>>>>>>>>> usually in *g*, the rest are in SI units. The force is
>>>>>>>>>>> therefore in *g·cm/s²*. Those are just one possible
>>>>>>>>>>> interpretation, and any interpretation that has consistency would
>>>>>>>>>>> go.
>>>>>>>>>>>
>>>>>>>>>>> From this paper <https://www.mdpi.com/2227-9717/9/10/1813>, The
>>>>>>>>>>> unit of normal stiffness is *g/s²* (the same as *k* in Eq. 3),
>>>>>>>>>>> and the unit of normal damping is *1/s* (similar to /gamma in
>>>>>>>>>>> Eq. 3, but Chrono ::GPU's damping will be multiplied by particle
>>>>>>>>>>> mass to
>>>>>>>>>>> form /gamma).
>>>>>>>>>>>
>>>>>>>>>>> Ruochun
>>>>>>>>>>>
>>>>>>>>>>> On Saturday, December 10, 2022 at 6:47:15 AM UTC-6
>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>
>>>>>>>>>>>> hello, Ruochun. Thank you for your advice, now I am trying to
>>>>>>>>>>>> prepare the dataset, and everything seems good now!
>>>>>>>>>>>> Then, I have a question about the unit in the
>>>>>>>>>>>> *demo_GPU_ballcosim.json*. In this json, the unit of
>>>>>>>>>>>> "sphere_radius"、"box_X" seems to be *mm*, but the "grav_Z"
>>>>>>>>>>>> equals -980, so I guess it's *cm/s^2* ?
>>>>>>>>>>>> The reason why I want to know is because the force I measured
>>>>>>>>>>>> is over 1e8, so I guess its unit is not N?
>>>>>>>>>>>> I noticed that the chrono system should not have uniform unit,
>>>>>>>>>>>> but all units need to correspond. I would appreciate it very much
>>>>>>>>>>>> if you
>>>>>>>>>>>> could tell me the units of the "normalStiffS2S"、normalDampS2S" in
>>>>>>>>>>>> this by
>>>>>>>>>>>> the way.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *demo_GPU_ballcosim.json*
>>>>>>>>>>>> {
>>>>>>>>>>>> "sphere_radius": 1,
>>>>>>>>>>>> "sphere_density": 1,
>>>>>>>>>>>> "box_X": 300,
>>>>>>>>>>>> "box_Y": 300,
>>>>>>>>>>>> "box_Z": 200,
>>>>>>>>>>>> "step_size": 5e-5
>>>>>>>>>>>> "time_end": 2,
>>>>>>>>>>>>
>>>>>>>>>>>> "grav_X": 0,
>>>>>>>>>>>> "grav_Y": 0,
>>>>>>>>>>>> "grav_Z": -980,
>>>>>>>>>>>>
>>>>>>>>>>>> "normalStiffS2S": 1e8,
>>>>>>>>>>>> "normalStiffS2W": 1e8,
>>>>>>>>>>>> "normalStiffS2M": 1e8,
>>>>>>>>>>>>
>>>>>>>>>>>> "normalDampS2S": 10000,
>>>>>>>>>>>> "normalDampS2W": 10000,
>>>>>>>>>>>> "normalDampS2M": 10000,
>>>>>>>>>>>>
>>>>>>>>>>>> "tangentStiffS2S": 1e8,
>>>>>>>>>>>> "tangentStiffS2W": 1e8,
>>>>>>>>>>>> "tangentStiffS2M": 1e8,
>>>>>>>>>>>>
>>>>>>>>>>>> "tangentDampS2S": 2000,
>>>>>>>>>>>> "tangentDampS2W": 2000,
>>>>>>>>>>>> "tangentDampS2M": 2000,
>>>>>>>>>>>>
>>>>>>>>>>>> "static_friction_coeffS2S": 0.5,
>>>>>>>>>>>> "static_friction_coeffS2W": 0.5,
>>>>>>>>>>>> "static_friction_coeffS2M": 0.5,
>>>>>>>>>>>>
>>>>>>>>>>>> "cohesion_ratio": 0,
>>>>>>>>>>>> "adhesion_ratio_s2w": 0,
>>>>>>>>>>>> "adhesion_ratio_s2m": 0,
>>>>>>>>>>>>
>>>>>>>>>>>> "verbose": 0,
>>>>>>>>>>>> "run_mode": 1,
>>>>>>>>>>>>
>>>>>>>>>>>> "psi_T": 32,
>>>>>>>>>>>> "psi_L": 16,
>>>>>>>>>>>>
>>>>>>>>>>>> "output_dir": "ballcosim",
>>>>>>>>>>>> "write_mode": "csv"
>>>>>>>>>>>> }
>>>>>>>>>>>> 在2022年11月25日星期五 UTC+8 06:33:36<Ruochun Zhang> 写道：
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> In terms of involving simulation results of Chrono::GPU in
>>>>>>>>>>>>> your reinforcement learning project, I would suggest you generate
>>>>>>>>>>>>> the
>>>>>>>>>>>>> dataset using Chrono::GPU, and then use the dataset in the
>>>>>>>>>>>>> training. You
>>>>>>>>>>>>> probably have to do that anyway, even if Chrono's DEM support is
>>>>>>>>>>>>> wrapped in
>>>>>>>>>>>>> Python.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ruochun
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thursday, November 24, 2022 at 8:23:18 AM UTC-6 Radu Serban
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are correct: Chrono::GPU is currently not wrapped in
>>>>>>>>>>>>>> PyChrono.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But you can certainly use smooth contact (that is construct a
>>>>>>>>>>>>>> ChSystemSMC) in PyChrono. Where/what did you see that made you
>>>>>>>>>>>>>> think that’s
>>>>>>>>>>>>>> not possible?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --Radu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *From:* 'yibing Yan' via ProjectChrono <
>>>>>>>>>>>>>> [email protected]>
>>>>>>>>>>>>>> *Sent:* Thursday, 24 November 2022 13:37
>>>>>>>>>>>>>> *To:* ProjectChrono <[email protected]>
>>>>>>>>>>>>>> *Subject:* [chrono] Re: the GPU module and the multicore
>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you for your advice, after trying for several days, I
>>>>>>>>>>>>>> succeed in using co-simulation, and it took only 10 minutes
>>>>>>>>>>>>>> every one
>>>>>>>>>>>>>> simulation. I have another question now, as I said before, I am
>>>>>>>>>>>>>> going to
>>>>>>>>>>>>>> use reinforcement learning with chrono. I think of using openAI
>>>>>>>>>>>>>> and I also
>>>>>>>>>>>>>> found projectchrono
>>>>>>>>>>>>>> <https://github.com/projectchrono>/*gym-chrono
>>>>>>>>>>>>>> <https://github.com/projectchrono/gym-chrono>*. However, I
>>>>>>>>>>>>>> don't know if I can realize what I have done with *PyChrono*,
>>>>>>>>>>>>>> because the Chrono::Engine Python module does not cover all the
>>>>>>>>>>>>>> features of
>>>>>>>>>>>>>> the C++ API.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Meanwhile, in Project Chrono: Install the PYTHON module
>>>>>>>>>>>>>> <https://api.projectchrono.org/development/module_python_installation.html>,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I found maybe I can't use Chrono::GPU system and Chrono SMC
>>>>>>>>>>>>>> system in
>>>>>>>>>>>>>> PyChrono. Can you give me any advice?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you very much again sincerely!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 在2022年11月11日星期五 UTC+8 11:29:20<Ruochun Zhang> 写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What you wanted is possible. There is no problem creating two
>>>>>>>>>>>>>> systems in one script, the only problem is their interaction.
>>>>>>>>>>>>>> You can do
>>>>>>>>>>>>>> that via co-simulation. Like a said, *demo_GPU_ballcosim *may
>>>>>>>>>>>>>> give you an idea on how to do that. The general idea is that
>>>>>>>>>>>>>> your complex
>>>>>>>>>>>>>> mechanical system involving ChBodies and joints and such, will
>>>>>>>>>>>>>> still be
>>>>>>>>>>>>>> managed by a Chrono SMC system. Those ChBodies can be instructed
>>>>>>>>>>>>>> to receive
>>>>>>>>>>>>>> external forces and torques via accumulators; those external
>>>>>>>>>>>>>> forces and
>>>>>>>>>>>>>> torques in this case should be queried from Chrono::GPU
>>>>>>>>>>>>>> simulations. That
>>>>>>>>>>>>>> is, you load obj meshes into a Chrono::GPU system, and in each
>>>>>>>>>>>>>> time step,
>>>>>>>>>>>>>> you let it compute the contact forces between meshes and
>>>>>>>>>>>>>> particles, then
>>>>>>>>>>>>>> feed that information to ChBodies to update the locations of
>>>>>>>>>>>>>> those bodies,
>>>>>>>>>>>>>> then feed the new locations of these obj meshes back to
>>>>>>>>>>>>>> Chrono::GPU to
>>>>>>>>>>>>>> complete one time step, and then repeat.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If your particle system is large I wouldn't recommend doing
>>>>>>>>>>>>>> runtime visualization anyway, that'd be totally prohibiting in
>>>>>>>>>>>>>> terms of
>>>>>>>>>>>>>> computational cost. Chrono::GPU can write particles and meshes
>>>>>>>>>>>>>> to files,
>>>>>>>>>>>>>> and maybe you should generate movies based on those as a
>>>>>>>>>>>>>> post-processing
>>>>>>>>>>>>>> step.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ruochun
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thursday, November 10, 2022 at 6:41:44 AM UTC-6
>>>>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi, thank you for your response!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First of all, I may have to apologise for my language skills
>>>>>>>>>>>>>> and I really appreciate that you are willing to listen to my
>>>>>>>>>>>>>> ideas. I'd
>>>>>>>>>>>>>> like to describe my question again. I have finished a complete
>>>>>>>>>>>>>> complex
>>>>>>>>>>>>>> experiment, including around 10k granular objects, two objs of
>>>>>>>>>>>>>> my own, one
>>>>>>>>>>>>>> container by using *utils::AddBoxGeometry* and several links
>>>>>>>>>>>>>> and motors, such as *ChLinkMotorRotationSpeed*、
>>>>>>>>>>>>>> *ChLinkMotorLinearSpeed*、*ChLinkMateFix*. I achieved it by
>>>>>>>>>>>>>> using *the MCORE module*, although it can speed up the
>>>>>>>>>>>>>> program by using multiple threads, it still took 2 hours four
>>>>>>>>>>>>>> one time
>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now I am considering using the reinforcement learning
>>>>>>>>>>>>>> afterwards, so it is important to improve the simulation speed.
>>>>>>>>>>>>>> I am
>>>>>>>>>>>>>> wondering if I can use *Chrono::GPU* only for my granular
>>>>>>>>>>>>>> objects, and all other content remains the same by using *the
>>>>>>>>>>>>>> MCORE
>>>>>>>>>>>>>> module.* More specifically, I plan to use both
>>>>>>>>>>>>>> *ChSystemMulticoreSMC* and *ChSystemGpuMesh* in one cpp. The
>>>>>>>>>>>>>> reason I want to do this is because *Chrono::GPU* is more
>>>>>>>>>>>>>> like a separate module, some of the functions I need for
>>>>>>>>>>>>>> simulation can't
>>>>>>>>>>>>>> be found in *Chrono::GPU*, but can be found in *the MCORE
>>>>>>>>>>>>>> module* and are already realized through my previous efforts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also note that *Chrono::GPU *quote ChronoEngine_GPU、
>>>>>>>>>>>>>> ChronoEngine_irrlicht、ChronoEngine_multicore、
>>>>>>>>>>>>>> ChronoEngine_opengl、ChronoEngine_postprocess、ChronoEngine_robot
>>>>>>>>>>>>>> and *ChronoEngine_multicore(* *the MCORE module* *) *is the
>>>>>>>>>>>>>> one which I used now. So I can use MCORE-functions in cpps in
>>>>>>>>>>>>>> *Chrono::GPU*，by including the .h insteading of modify
>>>>>>>>>>>>>> the CMakeLists.txt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried and felt if this idea was unattainable. Because I
>>>>>>>>>>>>>> need to create two systems in one cpp. Meanwhile, for
>>>>>>>>>>>>>> visualization,
>>>>>>>>>>>>>> *opengl::ChVisualSystemOpenGL* is used in *the* *MCORE
>>>>>>>>>>>>>> module *and *ChGpuVisualization* is used in *the Chrono::GPU
>>>>>>>>>>>>>> *and I can't find an interface between the two which means
>>>>>>>>>>>>>> they can't be showed in one window. I don't know how to solve
>>>>>>>>>>>>>> this problem
>>>>>>>>>>>>>> anymore and I wonder if you have any suggestions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really appreciate your help!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 在2022年11月10日星期四 UTC+8 13:29:20<Ruochun Zhang> 写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I hope someone can provide better help on the linkage issue.
>>>>>>>>>>>>>> What I can say is that you can try building it with cuda11.6 and
>>>>>>>>>>>>>> the newest
>>>>>>>>>>>>>> gcc. If you are using cuda11.8, or an ancient version of cuda or
>>>>>>>>>>>>>> gcc, I
>>>>>>>>>>>>>> cannot be sure. I've been building it with the said
>>>>>>>>>>>>>> configuration with no
>>>>>>>>>>>>>> problem, on Linux or Windows.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> About Chrono::GPU's usage, yes it supports obj meshes. I am
>>>>>>>>>>>>>> not sure about what you meant by multi-core acceleration. I
>>>>>>>>>>>>>> might, if you
>>>>>>>>>>>>>> elaborate a bit. And Chrono::GPU should interact with Chrono
>>>>>>>>>>>>>> just fine, for
>>>>>>>>>>>>>> that maybe you can have a look at the *ballcosim *demo.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you care about polydisperse spherical particles or complex
>>>>>>>>>>>>>> shaped particles, then DEM-Engine is the way to go. You can
>>>>>>>>>>>>>> start using it
>>>>>>>>>>>>>> now. Indeed, documentations are being added. I can drop you a
>>>>>>>>>>>>>> message when
>>>>>>>>>>>>>> it becomes more accessible. Right now, I attached a snippet from
>>>>>>>>>>>>>> one of my
>>>>>>>>>>>>>> previous emails, to help you understand how to build this tool
>>>>>>>>>>>>>> on Linux. In
>>>>>>>>>>>>>> terms of using it, I'd start with checking out and running its
>>>>>>>>>>>>>> demos. And
>>>>>>>>>>>>>> then, the methods in *API.h* are mostly commented, which for
>>>>>>>>>>>>>> now, may serve as an ad-hoc documentation for you to understand
>>>>>>>>>>>>>> what some
>>>>>>>>>>>>>> of its basic usages are.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ruochun
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wednesday, November 9, 2022 at 2:19:40 AM UTC-6
>>>>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi, thank you very much for your help!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After last mail, I choosed to use the multicore, the
>>>>>>>>>>>>>> simulation took 2 hours every time now, because I was
>>>>>>>>>>>>>> constantly adding
>>>>>>>>>>>>>> requests and features and the number of bodies comes to 10k.
>>>>>>>>>>>>>> Meanwhile, I
>>>>>>>>>>>>>> bought a 3080 and a new computer. I am considering using the
>>>>>>>>>>>>>> reinforcement
>>>>>>>>>>>>>> learning afterwards, so it is important to improve the
>>>>>>>>>>>>>> simulation speed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have studied your response several times，I am wondering if
>>>>>>>>>>>>>> I can only use Chrono::GPU for my particle-related content, and
>>>>>>>>>>>>>> all other
>>>>>>>>>>>>>> content remains the same, such as multi-core acceleration,
>>>>>>>>>>>>>> loading my own
>>>>>>>>>>>>>> obj. More specifically, I plan to use both ChSystemMulticoreSMC
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> ChSystemGpuMesh. When compile the project, there are errors
>>>>>>>>>>>>>> "LNK2019
>>>>>>>>>>>>>> ：Unresolvable external symbols" in every functions defined
>>>>>>>>>>>>>> in GPU and used in the Muticore and I feel this is a deeper
>>>>>>>>>>>>>> issue involving
>>>>>>>>>>>>>> linkers. So I would like to ask for guidance or is there another
>>>>>>>>>>>>>> way to use
>>>>>>>>>>>>>> the Chrono::GPU as a DEMsolver only for the particles.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And I learned something about projectchrono
>>>>>>>>>>>>>> <https://github.com/projectchrono>/*DEM-Engine*
>>>>>>>>>>>>>> <https://github.com/projectchrono/DEM-Engine>, but I found
>>>>>>>>>>>>>> how to Install DEM-Engine and the DEM-Engine usage are still
>>>>>>>>>>>>>> waiting to be
>>>>>>>>>>>>>> added, I would love to try it if I could.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you again!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 在2022年9月24日星期六 UTC+8 14:45:22<Ruochun Zhang> 写道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The GPU module does benefit a lot from more recent hardware.
>>>>>>>>>>>>>> If your test case does not feature a huge number of bodies, say
>>>>>>>>>>>>>> some 10k,
>>>>>>>>>>>>>> then multicore can be a good choice. It probably requires less
>>>>>>>>>>>>>> learning
>>>>>>>>>>>>>> from you too.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It should be noted that Chrono::GPU is not "Chrono on GPU".
>>>>>>>>>>>>>> Most Chrono core classes and methods cannot be used in
>>>>>>>>>>>>>> Chrono::GPU. For all
>>>>>>>>>>>>>> purposes, Chrono::GPU can be seen as a standalone DEM solver for
>>>>>>>>>>>>>> monodisperse spherical particles, implemented on GPU. It should
>>>>>>>>>>>>>> be used to
>>>>>>>>>>>>>> simulate granular materials, and it can interact with Chrono
>>>>>>>>>>>>>> (core) so that
>>>>>>>>>>>>>> it becomes possible to bring a small number of more complex
>>>>>>>>>>>>>> objects (such
>>>>>>>>>>>>>> as your spoon) into the simulation as well. So if you would like
>>>>>>>>>>>>>> to use
>>>>>>>>>>>>>> Chrono::GPU, you have to start from its demos, to learn how to
>>>>>>>>>>>>>> use its own
>>>>>>>>>>>>>> methods to instantiate and manage granular particles.
>>>>>>>>>>>>>> Chrono::GPU's main
>>>>>>>>>>>>>> advantage is being fast. If your simulation has to involve
>>>>>>>>>>>>>> millions of
>>>>>>>>>>>>>> granular particles, then multicore will not do and GPU is the
>>>>>>>>>>>>>> choice.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> More specifically, *CreateCylindricalContainerFromBoxes* is
>>>>>>>>>>>>>> not a Chrono::GPU thing at all. *cohesion_ratio* is about
>>>>>>>>>>>>>> the cohesion between Chrono::GPU particles, and it has nothing
>>>>>>>>>>>>>> to do with
>>>>>>>>>>>>>> gravity, which is set by *SetGravitationalAcceleration* in
>>>>>>>>>>>>>> Chrono::GPU.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On a different note, Chrono's DEM/granular support on GPU is
>>>>>>>>>>>>>> moving towards a new direction. The support for complex granular
>>>>>>>>>>>>>> particle
>>>>>>>>>>>>>> shapes will be added and it will become a duo-GPU solver. It
>>>>>>>>>>>>>> will be based
>>>>>>>>>>>>>> on SBEL's new DEM Engine
>>>>>>>>>>>>>> <https://github.com/uwsbel/DEM-Engine>. Apart from being
>>>>>>>>>>>>>> more general and having higher efficiency, the usage of it is
>>>>>>>>>>>>>> similar to
>>>>>>>>>>>>>> Chrono::GPU, as a standalone helper to Chrono core which manages
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> granular part of the simulation, or work on its own as a
>>>>>>>>>>>>>> dedicated DEM
>>>>>>>>>>>>>> solver. If from the previous conversation you believe
>>>>>>>>>>>>>> Chrono::GPU is for
>>>>>>>>>>>>>> you, then likely this package will be of interest. More
>>>>>>>>>>>>>> documentations and
>>>>>>>>>>>>>> user guides are being added to it. But again, it does benefit
>>>>>>>>>>>>>> from recent
>>>>>>>>>>>>>> GPUs though.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ruochun
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sunday, September 18, 2022 at 2:13:24 AM UTC-5
>>>>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> hello there,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am tring to perform a simulation which I want to put an
>>>>>>>>>>>>>> object like a spoon and scoop the sand(granular objects) to see
>>>>>>>>>>>>>> the force
>>>>>>>>>>>>>> in the process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I find that demo_GPU_mixer.cpp demo can be referenced, but I
>>>>>>>>>>>>>> am not sure whether I need to add a container holding those sand
>>>>>>>>>>>>>> and give
>>>>>>>>>>>>>> the granular objects gravity. If this is so, should I use
>>>>>>>>>>>>>> *CreateCylindricalContainerFromBoxes* to add container and
>>>>>>>>>>>>>> use *cohesion_ratio* in the .json to add the gravity? Also,
>>>>>>>>>>>>>> I am sad that I have a poor GPU so that it really take a long
>>>>>>>>>>>>>> long time to
>>>>>>>>>>>>>> run the gpu module.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then I find that there are also some granular objects demos
>>>>>>>>>>>>>> in the multicore module, I find some demos about a container
>>>>>>>>>>>>>> with granular
>>>>>>>>>>>>>> material. And I can run those demos faster.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now I am confused about what thing to do next is much better.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any help will be appreciated, thank you so much in advance.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 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/8e6dcb70-2812-4b15-aa00-845f77b9c67dn%40googlegroups.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/projectchrono/8e6dcb70-2812-4b15-aa00-845f77b9c67dn%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/5678a41c-d222-4539-8c13-2826ec53704en%40googlegroups.com.
