Hi Yves, If the problem is multiscale in nature, then it has to be resolved in a multiscale way. I think it is one of the challenges in these kinds of simulations and probably why you are researching it. Sounds like you are already looking for such a solution.
If the reinsertion only happens periodically then it may be possible to make the step size large when it happens, and change it back afterwards. It is unfortunate that the time participates the automatic scaling under the hood of the current version of Chrono::GPU, so you cannot just change the step size and go on with the simulation; some kind of re-initialization is needed each time. But still, it can be done. If the reinsertion happens too often or is too unpredictable then it may be just not worth it. Then it seems difficult to me. Maybe you can reinsert in such a way that it does not induce high velocities. It may link back to how you made these particles move at such a low velocity too. If it is caused by some delicate physics, then wouldn't capturing that physics require a fine time step size to begin with, and thinking about using large steps sizes does not make sense anyway? I do not know enough to comment on how to resolve this multiscale nature exactly. Thank you, Ruochun On Monday, June 27, 2022 at 8:23:25 AM UTC-5 [email protected] wrote: > Hello, > > Thank you for your answer. > > My case is I guess a bit unusual then, since I try to model a pebble bed > reactor. > In this reactor, the spherical elements' axial velocities are on the order > of cm/day when they evolve in the pack. > > However, the circulation of these elements is such that when they reach > the bottom of the vessel, they are reinserted at the top and fall back on > the pack. > When they fall, their velocities are much higher than 1 cm/day, and so I > think I cannot have these time steps too high. > From my preliminary runs, it seems that they crash as they either fall too > fast, or the pebble bed completely explodes, and in both cases the spheres > get out of the box. > > I will try several options and come back with my findings if it works. > > Yves > On Sunday, June 26, 2022 at 2:30:27 PM UTC+3 Ruochun Zhang wrote: > >> Hi Yves, >> >> The answer depends. >> >> About what you should scale, that is a general computational mechanics >> question and is not specific to DEM, and you should be able to find related >> readings from textbooks or webpages. If you scale time, then all quantities >> that involve time must be scaled accordingly. These include velocity, >> acceleration, Young's modulus etc. However I doubt if it is needed at all. >> From what I understand, scaling in computational mechanics is usually used >> to tackle numerical instability (extremely small numbers etc.), and it does >> not reduce runtime just like there is no free lunch. >> >> If the physics in your DEM problem is driven by some extremely small >> velocity/acceleration (hence the long simulation time), then you should be >> able to just use large time step sizes. The quality of DEM simulations >> depends heavily on whether contact events are resolved sufficiently with at >> least something like 4 time steps. A typical DEM contact event has a short >> duration (~1e-5 s), so the step size is usually that small. But a contact >> event with an impact velocity of 1 m/s resolved with a step size of 1 s, >> has about the same quality as a contact event with an impact velocity of >> 100 m/s resolved with a step size of 0.01 s. So if the physics you are >> trying to resolve is "mild", you can use large step sizes, and this is not >> scaling; if the physics is not "mild" then even scaling will not make it >> more numerically feasible. But one may be able to say otherwise if the >> physics driving the simulation is something I did not expect. Then it >> depends, whether scaling can help. >> >> As for what scaling factor/actual time step size you should choose, again >> it depends. No one can say without knowing the specific problem, and this >> is something you need to figure out, and sometimes trial-and-error is >> needed. >> >> Thank you, >> Ruochun >> >> On Sunday, June 26, 2022 at 4:33:25 AM UTC-5 [email protected] wrote: >> >>> Hello, >>> >>> My plan is to simulate a slowly evolving granular system, with time >>> scales of days for the frame rendering, and the whole simulation would >>> probably cover several hundreds of days. >>> >>> Since the DEM time step is usually very low (~1e-5s), I was thinking of >>> scaling down the time. In other words, I would accelerate the process. >>> >>> But I have now several questions: >>> >>> - First, is it the solution you recommend? >>> - Since I really do not want to impact the physics of the phenomena in >>> the system, what should I scale as well? I use material-based properties >>> for the simulation. I guess the gravity would have to be scaled, what about >>> the material properties? >>> - How do I choose the acceleration factor? 1 day could be represented by >>> 1e-5s, 1s, 10s, etc. What kind of criterion is usually used? >>> >>> Thank you, >>> Yves >>> >> -- 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/2a83e6e1-677a-4509-88ab-79f4268b1b40n%40googlegroups.com.
