David and Yves – if you work together and find a way to contribute back to Chrono::GPU that would be *fantastic*. You’ll likely help other users who have the same needs as you do. Pull Requests in GitHub would then be the way to go… I hope I convinced you :-) Dan
------------------------------------------------- Bernard A. and Frances M. Weideman Professor NVIDIA CUDA Fellow Director, Wisconsin Applied Computing Center Department of Mechanical Engineering Department of Computer Science University of Wisconsin - Madison 4150ME, 1513 University Avenue Madison, WI 53706-1572 608 772 0914 http://sbel.wisc.edu/ http://projectchrono.org/ ------------------------------------------------- From: [email protected] <[email protected]> On Behalf Of David Reger Sent: Tuesday, June 28, 2022 4:36 PM To: ProjectChrono <[email protected]> Subject: [chrono] Re: Time in simulations Hi Yves, Let me know if you find a solution to this, it seems we are performing very similar work. Perhaps we can work together to find a way to do this in Chrono. Thanks! David On Monday, June 27, 2022 at 11:46:46 AM UTC-6 [email protected]<mailto:[email protected]> wrote: Hello, Indeed, I was thinking about changing the time step during the calculation. It is true that the reinsertion is continuous, falling then in the "too often" box. My idea was to simulate the slowly evolving pebble bed with a large time step, but then between each of these large time steps, kind of ignore most of the pebbles' interactions and apply fine steps. In these fine steps, I would have fixed the already existing pebbles (acting then as a wall), and based on the recirculation rate, take few of the bottom pebbles to reinsert them at the top (these would not be fixed anymore). I would simulate that until the new pebbles settle (it should be fairly fast, both in terms of simulated and real time), and then advance to the next large time step. But now that you tell me that it is not possible as it is with Chrono, I think I will try to approach it in another way. I guess what I could do would be to "depose" these new pebbles on top of the pebble bed, by extracting the position of the top layer of the bed and picking a location not far above this position, instead of just dropping them from the top of the geometry. Yves On Monday, June 27, 2022 at 6:21:00 PM UTC+3 Ruochun Zhang wrote: 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]<mailto:[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]<mailto:[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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/8672f59c-66c6-4b7e-a0d3-719173ac96fen%40googlegroups.com<https://groups.google.com/d/msgid/projectchrono/8672f59c-66c6-4b7e-a0d3-719173ac96fen%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/DM8PR06MB7703A8EE5546ECF5A2E7CA3EB1B89%40DM8PR06MB7703.namprd06.prod.outlook.com.
