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/6f64ad87-50d9-4f25-8494-9beec8f973acn%40googlegroups.com.
