Here is my take on your questions: 1. You can. Although I doubt how viable 50nm particles are. You can always scale the length unit if needed, for sure, but with or without doing it, the velocity values will be large compared to particle sizes, necessitating extremely small time step sizes (or you have, for example, particle phasing through one another in one time step). The step size requirement may be quite ridiculous for your needs, like 1e-8 or 1e-9. But another thing is, you need to ensure the system is initialized correctly, that no particle is spawned in the walls (analytical walls may be invisible when you visualize), that is a more typical cause for simulations that dies right at the start.
2. Although this may look like a VRAM issue, from my experience, for DEME, this is more like the kT's automatic bin size adaptation policy is failing. It has a tendency to fail for some "outlier" simulation scenarios, and I hope to resolve that in the next major version. You can probably test if this is the case by adding the following two lines before Initialization(), to see if they help: *DEMSim.SetInitBinNumTarget(int(1e7)); // or some other number like 1e6 or 1e5DEMSim.DisableAdaptiveBinSize();* If this makes no difference, then we'll have to see the code to figure out what is really happening. 3. Again, using such a high *E *will necessitate extremely small time step sizes. I don't know what you are using (maybe you derived it using Rayleigh time step?), but it's always good to try if even smaller step sizes stabilize it. It should be noted that even if it does, the size may be too small to be viable. Using reduced *E *in DEM simulations is common and in many use cases it hardly affects the result. There's also a chance that the number is too big and the floating-point accuracy starts to kick in. So another good thing to try is to scale the length unit so 200G becomes a smaller number. But this is less likely the cause. Ruochun On Sunday, March 1, 2026 at 7:04:10 AM UTC+8 [email protected] wrote: > Got ur point. I will try to do that. I have few questions regarding DEME. > 1. Can I use extremely small particle sizes for compression using > Hertz-Mindlin model. My specimen size is 50nm currently and its > consistently showing me error of very high velocity (exceeding max velocity > around 2k) at step 0? > 2. When I run a simulation, sometimes its using 1 GPU (getting stuck at > some point) or sometimes 2 GPUs (runs smoothly then). Then I had to rerun > the simulation . Is there any way to solve it? Particle size count is > around 30k. > 3. In another compaction problem, I am using particles with *E = 200 GPa*. I > have set the time step accordingly, and the particle size is 1 mm. However, > the particles are not settling properly. They keep vibrating(underdamped) > even after a long settling period (increasing the settling time or reducing > CoR to 0 doesn't help). > > In all the demo examples, I have seen that at most *1 GPa* is used for > Young’s modulus. How can I stabilize the particle bed when using such a > high stiffness material? > > > Thanks for the support. > > On Friday, February 27, 2026 at 9:50:17 PM UTC-8 Ruochun Zhang wrote: > > Then again, I still think it's a servo-controlled boundary problem, or say > you need a control policy implemented (i.e. you keep the lateral pressure > constant by keeping the lateral walls under servo control during the axial > loading phase). During shear you prescribe the top wall’s z-velocity > (strain rate control) while continuously (like updating it every N steps or > so) adjusting the x/y wall positions/velocities based on the > tracker-measured lateral pressure values. This should be exactly like > what's happening under the hood for a physical test, and this control > policy shouldn't be too hard to implement with C++ or Python. It's not > already in DEME, which is a shame... But if you can contribute such a demo > to the project, that'd be great. I hope I understand your question > correctly. > > On Friday, February 27, 2026 at 11:59:05 AM UTC+8 [email protected] > wrote: > > Thanks a lot, but the problem is how can I keep that pressure constant > after getting my desired pressure (If I put an axial strain rate in the > z-direction after that, the lateral pressure will increase again according > to you)? I wanted to apply an isotropic confining pressure of some value to > the specimen in all directions to consolidate it to equilibrium and then an > axial strain rate on the top wall (z-axis) while maintaining constant > lateral pressure (x and y axis) which is also called Standard Triaxial Test. > > On Thursday, February 26, 2026 at 1:54:53 AM UTC-8 Ruochun Zhang wrote: > > The short answer is yes, but it's not a one-liner. If you already have > your setup to compress the material, then rather than directly setting the > wall pressure, think of creating a servo-controlled boundary problem. You > can use the tracker class to track the walls that you use for compression, > then you can get the normal force using that tracker, and divide that by > the area of the wall, you get the pressure. Adjust the wall velocity (or > position) based on the difference between the current pressure and your > target pressure. This creates a feedback loop that drives the system toward > the desired pressure. > > Let me know if there are further questions. > Ruochun > On Wednesday, February 25, 2026 at 7:31:13 PM UTC+8 [email protected] > wrote: > > Can I do a triaxial compression test in Chrono DEM Engine?? I can easily > do uniaxial compression but I cant put any confined pressure in y and z > directions when trying triaxial tests in chrono DEM Engine. How can I keep > the pressure constant in a direction at the time of compression?? > > -- 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/4c80be7d-8ec8-4453-8e73-700f86a4955cn%40googlegroups.com.
