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/cfbee451-210c-4b5b-93a6-32ea35362174n%40googlegroups.com.

Reply via email to