Help with DEM Simulation and Executable Files on Windows

[sumaiya abedin]

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.

[Ruochun Zhang]

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

[sumaiya abedin]

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.

[sumaiya abedin]

Here are the screen shots

[Ruochun Zhang]

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

[Ruochun Zhang]

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

[sumaiya abedin]

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

[sumaiya abedin]

Looks like the copy paste image does work not properly. Here is the third  image based on the previous conversation.

[Ruochun Zhang]

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

[Ruochun Zhang]

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