Initialize hangs in pyDEME after solver setup on WSL (CUDA Blackwell/compute_120)

[박선호]

## Environment
- OS: Windows + WSL Ubuntu
- GPU: NVIDIA Blackwell class GPU (compute_120)
- CUDA: tested with 12.8 (also checked arch override)
- DEME: pyDEME 2.3.3 (`pip install DEME`)
- Python: conda env, Python 3.11
- Note: similar behavior observed in both pyDEME path and C++ demo path during initialization-stage runs in our setup history.

## Problem
The simulation hangs right after solver setup and never reaches Initialize completion.
In our marker logs, execution reaches setup marker (e.g., `P3_SETUP`) but does not reach initialize marker (e.g., `P4_INIT`).

## Reproduction
1. Create clean conda env (Python 3.11)
2. Install DEME via pip
3. Run a minimal script that:
   - imports DEME
   - creates `DEMSolver`
   - sets basic material/scene
   - calls `Initialize`
4. Observe process stalls indefinitely after setup stage

## Expected
`Initialize` should complete and proceed to timestep loop or first output frame.

## Actual
Process stalls/hangs after setup stage with no forward progress.

## What we already tried
- Clean reinstall of DEME and environment
- Re-run with persistent JIT cache related env vars
- Set `DEME_DEFAULT_CUDA_ARCH=compute_120`
- Cross-check with C++ path and minimal demos
- Investigated known jitify/startup related PRs/issues history

## Questions
- Is Blackwell/compute_120 fully validated for current pyDEME path?
- Are there recommended flags/env vars for avoiding Initialize-stage stalls?
- Any known incompatibility matrix for CUDA/GCC/driver combinations specific to pyDEME?

[Ruochun Zhang]

Thanks for reporting this. To answer your question, newer CUDA and newer GPUs are indeed less tested. But I just tested the C++ version of DEME on a 5090 machine with CUDA=12.8, and it works fine for me (did not test pyDEME yet). So there are incompatible setups, but CUDA 12.8 and the newest NV driver are not among them.

So please help me understand: Are you saying that for both your pyDEME installation and the compiled-from-source C++ version, you got the stalling problem at demo initialization? And your CUDA version is 12.8 (not 13.0+)? And if you are willing to spend a bit more time on it, could you try debugging it and let me know if it stalls at the just-in-time compilation (i.e., spending 20 minutes or so just to compile one kernel)?

There are plans to modernize the pyDEME installation process, and DEME itself, which may be online quite soon, which I hope will resolve potential problems, at least to better show where the stalling happens.

Thank you,

Ruochun

[박선호]

Thank you for your comment, 

Initialize isn't hanging, just slow (up to ~10–17 min for our setup). But we hit a new serious issue tied to small particle radius (1mm):

After Initialize() succeeds, the run either:

crashes: GPU Assertion: an illegal memory access was encountered (DEMStaticDeviceUtilities.cuh:27), or
halts: On average a sphere has NNN contacts, more than the max allowance (100)
Tested (DEME 2.3.3, pip, single GPU, WSL Ubuntu 22.04, CUDA 12.8, 2306 particles, radius=1mm):

. Sweeping SetInitBinSize(MULT*radius): small/medium bin counts (2541, 432 bins) → crash

                                                                         large bin (225–250 bins) → no crash, but avg-contacts error instead (809–2118, exceeds even a raised allowance of 2000).
. DEME's own default bin choice (no explicit SetInitBinSize, ~986k bins) → crash.
. Finer wall mesh (1580+2600 tris vs. 42+129) → same crash, so mesh coarseness isn't it.
. SetForceCalcThreadsPerBlock(128) (per your troubleshooting doc, for register-starved force kernels) 

    → tried at both 986k bins and 432 bins → still crashes either way.

Also a related question on step size: we're using SetInitTimeStep around 1e-6 – 2e-7s for 1mm particles (scaled down from a larger-particle baseline). 

Is there a recommended way to derive a safe/stable time step as a function of particle radius (e.g., some fraction of the Rayleigh time step), 

rather than trial-and-error shrinking it every time we go smaller?
we're considering testing even smaller particles (sub-1mm) next. If there's a known best-practice combination of bin sizing + time step scaling for very small particles that avoids this crash, that would be extremely helpful before we go further.

Best regards

Sunho Park

2026년 7월 8일 수요일 오전 5시 53분 14초 UTC+9에 Ruochun Zhang님이 작성:

[Ruochun Zhang]

Hi Sunho,

About the extremely slow JIT process: Taking 10~17 mins is not normal for the process. I've seen similar problems with CUDA 13.0+. Though not with 12.8, I think using older versions of CUDA might resolve this. I haven't figured out why this happens with newer CUDA (and/or potentially newer GPUs). But in the upcoming DEME versions, it will cache the jitified kernels so repeated runs should not have to re-jitify every kernel each time. That might be a point of interest for your use case.

About the crash, if I read correctly, you did not specify which script so I assume it is not a demo that comes with DEME, but your own test script? In that case, the best thing you can do is to let us have a look at the script. Without it, I only have some educated guesses:

1) The error "on average a sphere has NNN contacts" most likely just indicates a diverged simulation. Though you don't have that many particles, radius=1mm can be quite challenging, and relaxing the physics usually fixes it. I have a feeling that you are also using a "realistic" Young's modulus, i.e., 10e9 or so. The quickest way to test is to use a Young's modulus value that is much smaller, like 1e6, to see if it helps.

2) I would suggest against paying too much attention to the bin size controls. You can just leave everything default. Or maybe just add a line "DisableAdaptiveBinSize()" to rule out the effect of the bin auto-adaptation. Other than that, I don't think it plays a big role.

3) Pay attention to InstructBoxDomainDimension. If it is set to something like millions of times larger than the bounding box of the actual particles, the solver may get a bit confused. But in your case it's not very likely.

About step size choice, I just suggest using the Rayleigh time step, nothing wrong with it. You are probably asking because the time step size you are using is not yielding great simulation results yet, or you fear that for the tests with even smaller particles, the step size might need to be too small. I'd worry about it when you actually get there, after resolving the current issue. And it's generally needed to use some "artificial" or say relaxed material properties (rather than stubbornly attacking this issue via step size only) for particles this small. If done right, it generally does not hurt the physics and makes the simulation much more doable.

Thank you,

Ruochun