Thank you for your help! I will study it and make experiments for a few more days.
在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/23e76e5a-88a5-4b97-a942-93c367fecb9dn%40googlegroups.com.
