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/be21ffc1-8694-46cb-bd9f-fcc2311b47d3n%40googlegroups.com.
