> One other thought I had is that the slowdown could be related to saving 
> around 20 functions for post-processing and plotting with GNU plot at the 
> end. Do you think that this could be a contributing factor?
There is an easy way to check: do not write anything out and see how long it 
takes to simulate.
Writing to disk or other I/O operations, if this is what you do, would slow 
things down a lot.
Dan
---------------------------------------------
Bernard A. and Frances M. Weideman Professor
NVIDIA CUDA Fellow
Department of Mechanical Engineering
Department of Computer Science
University of Wisconsin - Madison
4150ME, 1513 University Avenue
Madison, WI 53706-1572
608 772 0914
http://sbel.wisc.edu/
http://projectchrono.org/
---------------------------------------------

From: [email protected] <[email protected]> On Behalf 
Of Gianni Curti
Sent: Tuesday, September 24, 2024 12:34 PM
To: ProjectChrono <[email protected]>
Subject: Re: [chrono] Percentage of CPU decrease over time


Hi Dan,

Thank you for your response.

By "start of the simulation," I’m referring to the point where the timestep is 
already running. As for the profiler, I can use the built-in tools in Microsoft 
Visual Studio 2022 on my laptop. However, the issue mainly arises towards the 
end of the simulation, and the last time I ran it on the workstation, it took 
about 4 days to complete. I could try running it for a few hours to see if the 
problem starts to manifest earlier.

One other thought I had is that the slowdown could be related to saving around 
20 functions for post-processing and plotting with GNU plot at the end. Do you 
think that this could be a contributing factor?

The reason I’m using MCORE instead of DEM-E is because there’s already someone 
else in the project working on creating a particle bed using DEM-E. Instead, my 
thesis focus is on the vehicle itself, and since we also need to build a 
prototype, I’m using the previous terrain model (built with MCORE) to generate 
initial results while waiting for the DEM-E model to be ready.

Thank you again.

Gianni

Il giorno martedì 24 settembre 2024 alle 18:47:05 UTC+2 Dan Negrut ha scritto:
Gianni – it might be that the initial process is associated with setting up the 
simulation.
When you say “start of the simulation”, do you mean the simulation time is 
advancing, or are you referring to the “set up” stage, when there is no time 
integration yet. It might be that memory operations are so overwhelming that 
the CPU is stalled most of the time waiting for data to move back and forth 
between CPU and RAM. This is a guess, and if you have 30 mins and get to the 
bottom of it, it’d be interesting to run a profiler on the code, to see where 
the time is spent during the dynamics simulation.

One more question: is there a good reason you want to use MCORE? In case you 
need friction and contact on a large scale, you might take a look at Chrono DEM 
Engine.

Dan
---------------------------------------------
Bernard A. and Frances M. Weideman Professor
NVIDIA CUDA Fellow
Department of Mechanical Engineering
Department of Computer Science
University of Wisconsin - Madison
4150ME, 1513 University Avenue
Madison, WI 53706-1572
608 772 0914<tel:(608)%20772-0914>
http://sbel.wisc.edu/
http://projectchrono.org/<https://urldefense.com/v3/__http:/projectchrono.org/__;!!Mak6IKo!JcpdaBHVHm6vOOqQxwWvR8lzy3o1pR4lgdSo4ye60XOgQ7GrJvD3hrbFEW324un2lHR8D6kpLpqjixhQmaJ3$>
---------------------------------------------

From: [email protected] <[email protected]> On Behalf Of 
Gianni Curti
Sent: Tuesday, September 24, 2024 5:33 AM
To: ProjectChrono <[email protected]>
Subject: [chrono] Percentage of CPU decrease over time


Hi everyone,

I’m encountering some issues with Chrono::Multicore in my simulation, which is 
based on the demo_MCORE_Cratering example. The goal is to simulate the 
interaction of an object with a particle bed at rest. The code compiles and 
runs without errors, but I’ve noticed an unexpected drop in CPU utilization.

At the start of the simulation, all the threads I allocate are working at 
80-90% capacity. However, as the simulation progresses, their utilization 
gradually drops to around 10% or even lower. I had expected the computational 
load to increase as the number of contacts grows from about 7,000 to 50,000, 
but this CPU behavior is quite strange.

I’ve observed this issue on both my Windows laptop (with 20 threads) and a 
university workstation running Linux (with 40 threads). Has anyone else 
experienced this? Could it be that the nature of the problem makes 
parallelization progressively more difficult as the simulation advances?

Thanks in advance for your help!

Best regards,
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 on the web visit 
https://groups.google.com/d/msgid/projectchrono/207ae42c-461f-4ce6-b019-cd8a9d8448cfn%40googlegroups.com<https://urldefense.com/v3/__https:/groups.google.com/d/msgid/projectchrono/207ae42c-461f-4ce6-b019-cd8a9d8448cfn*40googlegroups.com?utm_medium=email&utm_source=footer__;JQ!!Mak6IKo!Mn-N_BVwsaeaLOaZsF4s97HOvYjh5IqcOxw7-HDp_xbX7s1PAZ9DDHCyZNSdKhWwJR80RB6Jqjch6ml6kSFF$>.
--
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]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/projectchrono/adaf3ecc-3073-4e18-8696-a3e175d529ffn%40googlegroups.com<https://urldefense.com/v3/__https:/groups.google.com/d/msgid/projectchrono/adaf3ecc-3073-4e18-8696-a3e175d529ffn*40googlegroups.com?utm_medium=email&utm_source=footer__;JQ!!Mak6IKo!JcpdaBHVHm6vOOqQxwWvR8lzy3o1pR4lgdSo4ye60XOgQ7GrJvD3hrbFEW324un2lHR8D6kpLpqjiyrEymQR$>.

-- 
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/DM8PR06MB7703262F9FB79C80DFBCACF4B1682%40DM8PR06MB7703.namprd06.prod.outlook.com.

Reply via email to