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/53b99de8-1b62-4166-a405-039a10a27b48n%40googlegroups.com.
