Hello Ruochun,
Thank you for your response. I have a few follow-up questions.
1.
The results from the *GRCdemo_Part1* executable generated on a desktop
(3080 series GPU) were run on a 2080 series GPU in a linux environment. We
encountered the following error message:
My contact pairs csv file from GRCdemo_part1 shows the following
columns(Attached Pic 1 image).
For debugging, I temporarily renamed *columns A and B to geoA and geoB,*
which seemed to fix the error and allowed *GRCdemo_Part2 to run
successfully*.
*My question is:*
· *Are geoA and geoB equivalent to A and B?*
· *What do they refer to in this context?*
· *If they are equivalent, how should I properly fix the script to
avoid this issue in the future?*
* 2.*The files produced by *GRCdemo_Part2* were then used for
*GRCdemo_Part3*. The program failed to run and did not display an error
message like before.
When I ran Part 3 in debug mode, it crashed at the following line
in a different file(Attached GRC_PART3_HEADER_ERROR_MESSAGE) .
>From my understanding, the exception indicates that we ran out of VRAM. Is
this indeed the expected location for an exception when VRAM is exhausted?
I was also using GPU monitoring tools and observed VRAM usage reaching its
maximum right before the program aborted.
Thank you in advance for your help.
Bests,
Sumaiya
On Saturday, August 2, 2025 at 7:27:59 AM UTC-4 Ruochun Zhang wrote:
> Hi Sumaiya,
>
> I'd also like to answer the couple of questions you asked in a previous
> private message.
>
> The first is a comment. If you are indeed targeting hundreds of millions
> of particles, one full simulation can easily take days or months. So be
> cautious.
>
> About reducing the number of particles generated in GRC_Part1 and 2: You
> could try modifying the *scales *vector. Just enlarge every number
> therein by a factor. This should generate proportionally larger particles,
> thus reducing the total number. An even better way is to simply generate
> particles (and optionally save them to a file to reuse later, like you see
> in *SlopeSlip* and *DP* tests) like how *WheelDPsimplified *did. This
> way, you don't generate the extremely small particles compared to the
> "full" GRC representations, which I believe sacrifices some expressiveness
> but dramatically reduces the computational cost.
>
> Thank you,
> Ruochun
>
> On Friday, August 1, 2025 at 10:26:01 AM UTC+8 Ruochun Zhang wrote:
>
>> Hi Sumaiya,
>>
>> About verifying memory usage, it is possible with the current DEME. You
>> can use the method *ShowMemStats *in your script.
>>
>> But I don't think this is the problem you are facing, as the script seems
>> to exit quite early. And while I think outputting 80 frames in Part1 is
>> correct, I don't think it could be the problem either, because even if you
>> have some different Part1 generation due to randomization, Part2 should
>> still run.
>>
>> Could you please first identify up to what point in the script the
>> program can reach before exiting? You can do this by compiling your *sln
>> *file in Debug mode, then either stepping through the code until it
>> exits, or simply put a bunch of std::cout lines (especially around the
>> checkpoint file loading part) and run and see.
>>
>> Let me know and thanks,
>> Ruochun
>>
>> On Friday, August 1, 2025 at 1:59:54 AM UTC+8 sumaiya abedin wrote:
>>
>>> Here are the screen shots
>>>
>>> On Thursday, July 31, 2025 at 1:57:25 PM UTC-4 sumaiya abedin wrote:
>>>
>>>> Hello Ruochun,
>>>>
>>>>
>>>>
>>>> I have also verified the location of the files as mentioned in the
>>>> script of GRCDemo_part2.
>>>>
>>>> However, the problem has still not been resolved.
>>>>
>>>>
>>>>
>>>> Here is the directory of the files:
>>>>
>>>>
>>>>
>>>> 1. Directory for DEMDemo_GRCPrep_Part2 :
>>>> C:\Users\umroot\chrono_DEM-Engine\build\bin\Release
>>>>
>>>> 2. Directory for DemoOutput_GRCPrep_Part1 folder :
>>>> C:\Users\umroot\chrono_DEM-Engine\build\bin\Release
>>>> Note : The folder has the following files
>>>>
>>>>
>>>>
>>>> Can you please confirm the number of frames GRCpart1 was supposed to be
>>>> produce? In my case its 80. And there were no vtk files in GRCpart1.
>>>>
>>>> From your experience, do you think memory could be a factor here? More
>>>> specifically, is there anything in the script that checks GPU memory
>>>> status
>>>> between loading the file and performing the calculations—and possibly
>>>> crashes silently if the memory limit is exceeded?
>>>>
>>>>
>>>>
>>>> For reference, here are my computer's hardware specifications:
>>>>
>>>> *GPU: NVIDIA GeForce RTX 3080*
>>>>
>>>> * RAM: 26 GB*
>>>>
>>>> * Dedicated GPU Memory: 10 GB*
>>>>
>>>>
>>>>
>>>> Thank you in advance.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wednesday, July 16, 2025 at 9:40:29 AM UTC-4 Ruochun Zhang wrote:
>>>>
>>>>> Hi Sumaiya,
>>>>>
>>>>> First I'd like to address the window-closes-immediately problem. You
>>>>> probably double-clicked the executable to run it, so when it crashes for
>>>>> some reason, the window closes, giving you no chance to see the error
>>>>> messages. You should try opening a command line prompt (PowerShell)
>>>>> first,
>>>>> then launch the executable there for the window to hold. It gives us a
>>>>> better chance of understanding what happened.
>>>>>
>>>>> DEME is more tested on Linux, but I wouldn't say I strongly recommend
>>>>> Linux - I just recommend Linux. On Windows, it should still run
>>>>> correctly,
>>>>> I just don't know much about its efficiency. But if you do consider using
>>>>> Linux, maybe start with WSL2, it's quick to pick up for Windows users.
>>>>>
>>>>> Back to the problem you had, based on the runtime you got for part1,
>>>>> perhaps you have a gaming card released some years back? Maybe a 2070? It
>>>>> could seriously have VRAM shortage for running part3, but perhaps fine
>>>>> for
>>>>> part2. Or the problem could just be that somehow it failed to load the
>>>>> GRC_XXX input file. We shall see when we have the error message. But
>>>>> since
>>>>> this is the hardware you have, if you are interested in DEM
>>>>> terramechanics,
>>>>> you could try *WheelDPSimplified*. The terrain representation there
>>>>> is much cheaper to run, and offers relatively comparable results to the
>>>>> more expensive terrain you just tried.
>>>>>
>>>>> Part2 and 3 should generate separate output files.
>>>>>
>>>>> Thank you,
>>>>> Ruochun
>>>>>
>>>>> On Wednesday, July 16, 2025 at 6:15:31 AM UTC+8 sumaiya abedin wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I am new to Project Chrono and was looking for some advice.
>>>>>>
>>>>>> My research project involves using DEM simulations. I wanted to ask
>>>>>> whether the DEM engine is well-tested on Windows. From reading the
>>>>>> documentation, I got the impression that Linux might be better
>>>>>> supported.
>>>>>> However, I am more comfortable with Windows, so I would prefer to use
>>>>>> it—unless switching to Linux is strongly recommended. Please advise.
>>>>>>
>>>>>> I tried running the GRCdemo_part1 executable. After about a day and a
>>>>>> half, the expected CSV file named GRC_3e5 was produced. However, when I
>>>>>> try
>>>>>> to run the GRC_part2 and PGRC_part3 executables, the command prompt
>>>>>> window
>>>>>> closes immediately. I'm not sure why this is happening.
>>>>>>
>>>>>> Additionally, are GRC_part2 and GRC_part3 supposed to generate
>>>>>> separate GRC_3e5 files, or is there just one shared output file?
>>>>>>
>>>>>> I also tried running the Wheel_IDP executable by putting the GRC_3e5
>>>>>> in the
>>>>>> same directory, but the prompt closes right away as well. Any ideas
>>>>>> on what might be causing this? I am using Windows.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
--
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/e6686415-15b2-434e-ae90-7ee82785f0c3n%40googlegroups.com.
