Looks like the copy paste image does work not properly. Here is the third image based on the previous conversation.
On Monday, August 11, 2025 at 3:15:00 PM UTC-4 sumaiya abedin wrote: > 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/e8a4d374-6887-45f5-b244-db526cc1d51bn%40googlegroups.com.
