Hi Mohammad, *SetCDUpdateFreq *sets the maximum number of time steps by which the DEM physics can run ahead of the contact detection. So naturally, if this number is large, the contact detection subroutine needs to add a bigger envelope/safety margin to ensure it does not miss a contact that can potentially appear in the "future". That's why it is possible that when you increase it, more geometries appear in one bin and potentially cause problems, since the geometries here mean the geometries with the safety margin included.
But this should really be less of a problem for meshes, and I am a bit surprised here. You know I wrote this error message, but I myself never ever saw that in my simulation outputs. Meshes used in DEME are expected to have triangles somewhat larger than the particles (if you do need the mesh to represent geometric features that are smaller than your particles, then the contact force won't be calculated accurately anyway, because your particle shapes are approximations too), but it seems to be not the cause in your simulation, as you see problems with the mesh before you see that with the particles. If you just happen to be using huge particles (and therefore comparably small mesh facets) for this simulation and you just want it to run, then you can always use smaller bin sizes to resolve the problem. As for what number you should use, this is hardware- and problem-dependent. The target is always to use *the smallest number that is able to minimize the times that dT is held back*. This means right now, you have to try it out to find the best choice. I found with A100s many typical use cases benefit from that being set to something like 20. With consumer-grade GPUs, it tends to be larger, like 30 or 40. Just so you know, if the sweet spot is 20, and you set it to be 5 for example, then you are pretty much running at 25% speed; if you set it to 30 on the other hand, you will be running at a slightly reduced speed but not too bad. But a number too large has the associated risk of leading to too many geometries in a bin. Now there is good news. After deliberating, I think I know a way to make the bin size *and *CDUpdateFreq adapt automatically, and remove the limit of the number of geometries in a bin, meaning when it materializes you will no longer see this error again. If it does pan out, I'll let people know. Thank you, Ruochun On Thursday, December 29, 2022 at 8:13:02 PM UTC-6 [email protected] wrote: > Hello, > > This is DEME related question. > > How does the function SetCDUpdateFreq affect the maximum bin allowance? I > have been running a code with SetCDUpdateFreq(6) and everything was working > fine. However, when I changed the input from 6 to 15, I started getting an > error saying that Bin 32 contains 264 triangular mesh facets, exceeding > maximum allowance (256). Also, I am running a cone penetration test, does a > value of 6 considered a low value for such a test? > > > Thank you so much in advance, > > -- 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 on the web visit https://groups.google.com/d/msgid/projectchrono/7fa59513-733a-41ee-912a-99d772d9de56n%40googlegroups.com.
