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] 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] 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/8672f59c-66c6-4b7e-a0d3-719173ac96fen%40googlegroups.com.
