Hi Ruochun, yes indeed I was referring to Chrono Multicore. Since I have only a few objects for now I will avoid to use parallel computing as you said.
Thank you again for everything. Gianni Il giorno mercoledì 22 gennaio 2025 alle 14:10:34 UTC+1 Ruochun Zhang ha scritto: > Hi Gianni, > > You are probably asking about using Chrono Multicore. It's the best that > you start a Multicore-specific thread to let people with experience of that > answer this question. > > As a rule of thumb, if the Chrono part is about a small number of objects > then no; If it's about a moderate number of clearly divisible groups of > objects, like several ground vehicles, then yes. I wouldn't dismiss the > possibility that the Chrono part of the simulation can have an impact on > the simulation, even if the DEM part involves a million times more entities > since they are also computationally lightweight and run on GPUs. However, I > think it's more reasonable to ensure the Chrono part is implemented > correctly and efficiently using appropriate MBD models, before thinking > about running it in parallel. > > Thank you, > Ruochun > > On Wednesday, January 22, 2025 at 6:42:34 PM UTC+8 [email protected] > wrote: > >> Hi Ruochun, >> >> thank you for your answer. >> >> Another question regards the computational speed. In this case the >> terrain is completely managed by the the GPU, but regarding the Chrono part >> is it possible to have any speed boost (maybe by setting the number of >> threads used by the processor)? It is just a curiosity since maybe it does >> not even impact that much. >> >> Thank you again, >> >> Gianni >> >> Il giorno mercoledì 22 gennaio 2025 alle 04:17:55 UTC+1 Ruochun Zhang ha >> scritto: >> >>> Hi Gianni, >>> >>> For question 1 I can't comment too much on it, as I never used this >>> functionality. But since it's an unused variable warning, I don't imagine >>> any harm if the logic of the code is correct. >>> >>> For question 2, you should use the diagonal inertia matrix that is >>> consistent with the one you supplied to DEME. Note that if this object's >>> motion (velocity and acceleration) is completely managed by Chrono instead >>> of DEME, and the only thing you care about is the force and torque, then >>> the inertia matrix does not even have to be "correct" (you can choose to >>> not set it at all, and let it be the default 1.0), it needs only to be >>> consistent. >>> >>> Thank you, >>> Ruochun >>> >>> On Wednesday, January 22, 2025 at 7:00:17 AM UTC+8 [email protected] >>> wrote: >>> >>>> Hi Ruochun, >>>> >>>> my questions are: >>>> >>>> 1) When I build the program there is this warning appearing due to the >>>> fact that I am using GNUplot to produce graphs that shows the temporal >>>> trends of the object's position and velocity in Chrono. Is this harmful in >>>> some way? How can I suppress it?[image: Screenshot From 2025-01-21 >>>> 23-47-49.png] >>>> >>>> 2) At the point where the Chrono and DEME bodies interact, you find the >>>> torque by multiplying the diagonal inertia matrix of the ball for the >>>> angular acceleration. In my case, I have an unsymmetrical body, and as you >>>> told me I used the functions *InformCentroidPrincipal* and *SetMOI* to >>>> fully define principal inertia axis direction, principal inertia moments >>>> and CoG position. Thus my question is, in this case do I have to calculate >>>> *tor* as shown in line 1652 (where *inertia* is the vector containing >>>> the three principal inertia moments) or follow the process in line 1653 >>>> (and so use an inertia matrix which is not diagonal therefore I >>>> explicitely >>>> performed the product between the matrix and the vector)?[image: >>>> Screenshot From 2025-01-21 23-51-04.png] >>>> >>>> Thank you again for your time. >>>> >>>> Gianni >>>> >>> -- 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 visit https://groups.google.com/d/msgid/projectchrono/812421b5-9b0b-4031-a58c-5e0bfb2fdf62n%40googlegroups.com.
