Hi Sumaiya, I think I found the issue. In an unknown update, I seem to have changed the default contact file output from indexing with geometry ID (column name geoA and geoB) to indexing with owners (column name A and B). That seems to have caused Part1's output to be missing geoA and geoB, but has A and B. I made a recent update that explicitly asks Part1's output to include geoA and geoB, and that should fix the problem you previously saw. Sorry about that. But you probably have already "fixed" it by not loading the contact file in Part2, which is totally valid and you don't have to do anything in that case.
Thank you, Ruochun On Tuesday, August 12, 2025 at 11:32:23 PM UTC+8 Ruochun Zhang wrote: > Hi Sumaiya, > > First, about the error you got for Part3, yes it's about running out of > VRAM, thus a bad_alloc error. Again, I really suggest trying a > smaller-sized simulation for a more reasonable runtime. > > About reading CSV files into the solver, first let me say that it is not a > part of the core functionalities of DEME, and what we are discussing here > is really about a small auxiliary tool that somehow went wrong. The > contact_pairs file here records the contacts existing at the end of the > previous simulation. It's a piece of info many users need in their > research, understandably; but here in Part2, we are just reading a > checkpoint file to "restart" the simulation, and the contact pairs file is > in fact not strictly necessarily, because even if you don't notify the > solver the "old" existing contacts, the solver will figure them out once > the simulation starts (still, it's not 100% the same, as in this case the > solver thinks they are new contacts and loses all history info, such as > contact persistent time, but this effect is minor). You could even comment > out the *Contact_pairs_3e5*-related four lines, and it should still run. > > Now, about geoA or A, geoB or B, they mean the contact entity ID in each > contact (each line in that file records a contact). DEME uses generic data > storage formats such as CSV, so as CSV header names, geoA or A does not > matter and you can change them (to anything, in fact). It's just that the > small utility, *ReadContactPairsFromCsv*, assumes the column names are > geoA and geoB, in order to extract the contact pairs into a C++ vector. You > can call *ReadContactPairsFromCsv* differently (please check out the > call pattern of this function to see what I'm referring to). DEME itself > does not really care about file formats and all it cares about is a correct > vector as the input of the later *SetExistingContacts *call and, as we > discussed, even this *SetExistingContacts *call is optional and can be > removed without a big issue. My design philosophy small talk: DEME is about > being generic and open, thus both its input and output data have high > information granularity, there's never a big-fat-custom-format-file thing > with it, so you could make your own modifications or wrap more code around > what it does, such as writing your own CSV reader to supply the core solver > information needed, and that's probably the right way to use it as an > advanced user. > > I still don't understand how you generated a contact pair file that, in > the header row, had A and B, rather than geoA and geoB (as the default). > You could take a look at line 1766 in dT.cpp, I did ask the name "geoA" and > "geoB" to be written to the out file, right? I think it's either the > software version being mixed up, or somehow the contact file was > ninja-modified by someone. But again, this is very much out of the core > functions that DEME aims to provide so we could pick a remedy as we like, > such as commenting out the unnecessary part, and be assured that it won't > affect the physics that we are after. > > Ruochun > > On Tuesday, August 12, 2025 at 3:18:44 AM UTC+8 sumaiya abedin wrote: > >> 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/7fd1928c-9b9e-43fb-bacd-6093791bb91dn%40googlegroups.com.
