Thank you, I will keep working on it and see if I find good solutions. Best, Yves
On Wednesday, June 29, 2022 at 1:14:06 AM UTC+3 Dan Negrut wrote: > 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 <(608)%20772-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] 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 > > <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/79c77829-c6f4-41e1-8dfd-fd5ff862bbd5n%40googlegroups.com.
