Hi Giovanni, It looks to me that the script you gave me would still diverge at some point, but it seems a known issue (large velocity) and I suppose you have to either decrease the step size or make the stiffness lower to relax the physics. The particles in use are indeed very small. But maybe you already resolved it.
Let me know if you need further clarification. Thank you, Ruochun On Tuesday, August 8, 2023 at 11:30:38 AM UTC-5 Giovanni Bianchi wrote: > Thanks again Ruochun, > > I fixed the problem with the mass, and now the simulation runs perfectly > till the end. > > Best wishes, > > Giovanni > > Il giorno martedì 8 agosto 2023 alle 09:03:10 UTC+2 Ruochun Zhang ha > scritto: > >> To add one thing: The reason why the error message is not mentioning it, >> is that the negative mass somehow causes the velocity of particles to reach >> (-inf), even though I am querying the magnitude of the velocity. And then >> the max velocity reduction naturally just picks up a small positive >> velocity, as the outputted largest velocity. In the end, the error message >> did not capture the problem which now we know is still about abnormal >> velocity. >> >> Ruochun >> >> On Tuesday, August 8, 2023 at 1:57:36 AM UTC-5 Ruochun Zhang wrote: >> >>> Hi Giovanni, >>> >>> This is a more or less interesting case. You called the *Scale *method >>> on one of your meshes with (0.01, 0.01, -0.01). With that, the current >>> implementation will scale the mass of the mesh to a negative number. I >>> certainly did not take into account the Scale method being called with a >>> negative argument... >>> >>> In an update which I will push very soon, I'll fix this problem. And in >>> a way, the current implementation warns you about that too (have a look at >>> the first few lines in the output file), but it is actually more for noting >>> there are extremely light particles, rather than a sentry for negative >>> masses. For now, you can fix the problem by calling *SetMass *and *SetMOI >>> *again to the meshes (after you *Scale*), to overwrite the negative >>> mass. It doesn't matter what mass you set the mesh to have, as long as it >>> is magnitudes larger than the particle's. >>> >>> I'll monitor if this is the entirety of the problem, and follow up if >>> needed. But I suspect this is it. >>> >>> Thank you, >>> Ruochun >>> >>> On Monday, August 7, 2023 at 1:29:11 AM UTC-5 Giovanni Bianchi wrote: >>> >>>> Hello Ruochun, >>>> >>>> can you help me again with this issue? I checked the mesh, and now it >>>> seems to be ok, but I get this error as soon as the mesh gets into contact >>>> with the particles. >>>> >>>> Bin 14 contains 52524 sphere components, exceeding maximum allowance >>>> (32768). >>>> If you want the solver to run despite this, set allowance higher via >>>> SetMaxSphereInBin before simulation starts.Bin 20 contains 52524 sphere >>>> components, exceeding maximum allowance (32768). >>>> ... >>>> ... >>>> ... >>>> -------- Simulation crashed "potentially" due to too many geometries in >>>> a bin -------- >>>> Right now, the dT reported (by user-specification or by calculation) >>>> max velocity is 0.0130244 >>>> ------------------------------------ >>>> If the velocity is extremely large, then the simulation probably >>>> diverged due to encountering large particle velocities. >>>> Decreasing the step size could help, and remember to check if your >>>> simulation objects are initially within the domain you specified. >>>> ------------------------------------ >>>> If the velocity is fair, then perhaps for some reason too many contact >>>> geometries appeared in one bin. >>>> Are you using a contact model that promotes large penetrations, so it >>>> leads to this? >>>> And if you are using manual bin size, then decreasing the bin size >>>> could help. >>>> >>>> terminate called after throwing an instance of 'std::runtime_error' >>>> what(): GPU Assertion: unspecified launch failure. This happened in >>>> /home/giovanni/DEM-Engine/src/algorithms/DEMCubContactDetection.cu:384 >>>> >>>> I cannot understand what is happening because the velocity is small. I >>>> have attached the code and the new mesh. >>>> >>>> Best regards, >>>> >>>> Giovanni >>>> Il giorno sabato 22 luglio 2023 alle 08:06:57 UTC+2 Giovanni Bianchi ha >>>> scritto: >>>> >>>>> Thanks a lot, Ruochun, >>>>> >>>>> Your help is really appreciated! >>>>> >>>>> I have generated the mesh with a CAD exactly as you suggested, but >>>>> something wrong may have happened in the conversion from .stl to .obj. I >>>>> will create a new mesh for the objects. >>>>> >>>>> Have a nice weekend, >>>>> >>>>> Giovanni >>>>> >>>>> Il giorno sabato 22 luglio 2023 alle 06:06:38 UTC+2 Ruochun Zhang ha >>>>> scritto: >>>>> >>>>>> Hi Giovanni, >>>>>> >>>>>> I took a closer look. While the simulation parameters can affect, I >>>>>> think the main problem is actually *the mesh*. This is how Rhino >>>>>> thinks of the coperchio mesh: >>>>>> [image: rhino_report.png] >>>>>> >>>>>> As you can see, it purple part which is being complained about seems >>>>>> to be connecting parts of this mesh. Rhino also reports this *mesh >>>>>> is open* rather than closed. This mesh seems to be constructed out >>>>>> of 4 separate pieces, then put together but not properly joined at all. >>>>>> This has left a lot of hanging and degenerate facets, albeit not very >>>>>> visible if you render it. But this is enough and will for sure kill >>>>>> numerical simulations with this mesh. >>>>>> >>>>>> Another proof is that when I tried to reconstruct the mesh using >>>>>> quadratic elements, Rhino gives cracks and holes in those regions, >>>>>> hinting >>>>>> the original mesh is not properly made: >>>>>> [image: rhino_reconstruct.png] >>>>>> And these places happen to be where the particle phase-through >>>>>> happened in this simulation. This says something. >>>>>> >>>>>> I do not know how you obtained the mesh, but if I were to resolve the >>>>>> problem, I'd do this: This object can be made by a revolved solid (main >>>>>> body) and 20 fins generated by a circular pattern. We can make them as >>>>>> CAD >>>>>> objects and properly join them together (using boolean). After a valid >>>>>> solid part is created, we convert it to mesh. This should give a closed >>>>>> and >>>>>> properly conditioned mesh and I am very sure the problem will go away >>>>>> with >>>>>> a correct mesh. I would certainly suggest exploring this path before >>>>>> playing around more with the simulation part of things. >>>>>> >>>>>> Thank you, >>>>>> Ruochun >>>>>> >>>>>> On Friday, July 21, 2023 at 1:34:12 AM UTC-5 Ruochun Zhang wrote: >>>>>> >>>>>>> I was able to get this script running fine by simply changing the >>>>>>> step size to 2e-6 (it's running now. If things go wrong later on I can >>>>>>> let >>>>>>> you know). Of course, when you start using true material properties for >>>>>>> your particles, this step size may need to be further adjusted. Keep in >>>>>>> mind that large E, large CoR and small particle size make the >>>>>>> simulation >>>>>>> more challenging, and require smaller step sizes. I would guess if you >>>>>>> use >>>>>>> true material properties for everything in the simulation, then maybe >>>>>>> 1e-6 >>>>>>> is a good step size to start playing around. >>>>>>> >>>>>>> A few comments: >>>>>>> 1. You generally just need the verbosity level to be at INFO. If it >>>>>>> is at STEP_METRIC, it will try to check if contact pairs are mapped >>>>>>> normally between 2 consecutive contact detections but this is usually >>>>>>> not >>>>>>> needed, and costs time. >>>>>>> 2. I saw a warning in the output: a particle may have 0 mass or MOI. >>>>>>> This is because your MOI is super small in the simulation (~1-13). It >>>>>>> appears to be fine in this case, but you can also consider using a >>>>>>> different underlying unit system so the numerics are not so small for >>>>>>> masses and MOIs. This is perhaps a minor issue. >>>>>>> 3. I suppose you originally got a "too many contacts per sphere" >>>>>>> error, and simply changed the tolerance in your subsequent simulations. >>>>>>> Usually you do not need to change that threshold: Each sphere having on >>>>>>> average more than 100 contacts is indeed strange, don't you think? That >>>>>>> is >>>>>>> common if the physics went bad in the simulation, and the whole system >>>>>>> diverged. Having an error indicating particles moving at a velocity >>>>>>> higher >>>>>>> than the threshold is also likely linked to it (but this can depend on >>>>>>> your >>>>>>> unit system: for example the default threshold is 1000, but if your >>>>>>> particles are moving at 1000mm/s then perhaps it is not abnormal, and >>>>>>> you >>>>>>> may want to manually change the threshold). You usually change the >>>>>>> physics >>>>>>> to make the simulation run, not the thresholds. >>>>>>> >>>>>>> Ruochun >>>>>>> >>>>>>> On Thursday, July 20, 2023 at 11:24:44 AM UTC-5 Giovanni Bianchi >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks Ruochun, >>>>>>>> >>>>>>>> the mesh is composed of two objects, vasca is fixed, and coperchio >>>>>>>> is moving. I share only the moving mesh otherwise I exceed the limit >>>>>>>> of MB. >>>>>>>> >>>>>>>> Thank you very much, >>>>>>>> >>>>>>>> Giovanni >>>>>>>> >>>>>>>> -- 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/f5f3e183-250e-48ed-9a8c-a64c8abd273an%40googlegroups.com.
