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/b7232eee-2167-45f5-a963-f0ed2f33a084n%40googlegroups.com.
