Hi Weigang, Yes. And that's exactly what we did in the fracture demo to begin with, is it not?
Thank you, Ruochun On Thursday, June 20, 2024 at 3:07:07 PM UTC+8 weigan...@gmail.com wrote: > Hi Ruochun, > > Do you mean that we can add a if statements in the > ForceModelWithFracture.cu to differentiate types of contacts? > > Thank you, > Weigang > > > > On Thursday, June 13, 2024 at 8:30:45 PM UTC+8 Ruochun Zhang wrote: > >> Currently, DEM-Engine custom model functionality permits only one script, >> meaning that in principal, you are writing a unified force model that goes >> for sphere-sphere, sphere-boundary, *and *sphere-mesh. Just think of the >> sphere-compressor contact as a special case, which is the contact between a >> normal sphere and an infinitely-large sphere. >> >> About enforcing different models for different objects, you can associate >> different objects with respective family numbers, then use if statements to >> differentiate types of contacts. I talked about this in one of the earlier >> replies in this thread, please go back and have a look. >> >> Thank you, >> Ruochun >> >> >> On Thursday, June 13, 2024 at 1:31:37 PM UTC+8 weigan...@gmail.com wrote: >> >>> Hi Ruochun, >>> >>> Thank you for your reply. In fact, I am puzzled that there is not any >>> sentence in the Fracture-Box demo to declare the contact model between >>> spheres and the compressing plate. So, how to declare the contact model, >>> especially for the case in which there has been another contact model, such >>> as the ForceModelWithFracture.cu? >>> >>> Thank you, >>> Weigang >>> >>> On Thursday, June 13, 2024 at 12:03:52 AM UTC+8 Ruochun Zhang wrote: >>> >>>> Hi Weigang, >>>> >>>> Note that in general, if you use a custom force model, then that model >>>> alone is used, there is no fallback so I wouldn't call that anything has >>>> "defaulted" to Hertz–Mindlin. Specific to the Fracture-Box demo, it's just >>>> that the force model (ForceModelWithFracture.cu) is written in a way that >>>> when the bond between two particles breaks, the "else" branch of that big >>>> if statement is executed, and something similar to Hertz–Mindlin is >>>> enforced. >>>> >>>> I said it's similar since it's not a pure spring–damper model now, it's >>>> a spring–damper model with the resting location (zero-force location) >>>> being >>>> the penetration depth the moment when the bond broke. This implementation >>>> avoids a potential problem with a pure spring–damper model: Without the >>>> adjusted resting location, a newly broken-away pair of particles would see >>>> the bond suddenly gone but there were still left-over penetration, >>>> therefore immediately pushing each other away with high velocity, >>>> resulting >>>> in non-physical results. Shout-out to Bona for implementing this. >>>> >>>> Thank you! >>>> Ruochun >>>> >>>> >>>> On Wednesday, June 12, 2024 at 8:33:55 PM UTC+8 weigan...@gmail.com >>>> wrote: >>>> >>>>> Hi Ruochun, >>>>> >>>>> Thank you for your great work. The demo now is runs well. I have a >>>>> question about the Fracture-Box demo. After the bond between two >>>>> particles >>>>> breaks, is it right that the contact model between them change defaultly >>>>> from ForceModelWithFracture to Hertz–Mindlin model? >>>>> >>>>> Thank you, >>>>> Weigang >>>>> >>>>> On Friday, May 31, 2024 at 8:05:24 PM UTC+8 Ruochun Zhang wrote: >>>>> >>>>>> Hi Weigang, >>>>>> >>>>>> The problem appears to be fixed now. Please pull the newest main >>>>>> branch and try the fracture demo again. I suggest you do a clean rebuild >>>>>> from an empty directory, because only a force model file is changed and >>>>>> if >>>>>> you just "make", cmake probably thinks nothing needs to be done. Or you >>>>>> can >>>>>> simply manually copy the modified cu file over to the appropriate >>>>>> location >>>>>> in the build folder. >>>>>> >>>>>> The problem was that we left an uninitialized variable in the force >>>>>> model file. On data center cards, the compiler zeros it out >>>>>> automatically, >>>>>> but on consumer cards it does not. We therefore missed it initially. >>>>>> Should >>>>>> be all good now. >>>>>> >>>>>> Thank you, >>>>>> Ruochun >>>>>> >>>>>> >>>>>> On Tue, May 28, 2024, 11:00 PM Ruochun Zhang <ruoc...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Weigang, >>>>>>> >>>>>>> It's not like recommending a card; rather, if you happen to have a >>>>>>> data center card available (A100, A5000 etc.), you can circumvent this >>>>>>> problem for now by using them. Otherwise, let's hope we find a solution >>>>>>> very soon, or at least find a workaround. We'll keep you posted. >>>>>>> >>>>>>> Thank you, >>>>>>> Ruochun >>>>>>> >>>>>>> On Monday, May 27, 2024 at 7:27:10 PM UTC+8 weigan...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Ruochun, >>>>>>>> >>>>>>>> My card is indeed a gaming card NVIDIA GeForce RTX 2070 Super. >>>>>>>> Could you recommend a card? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Weigang >>>>>>>> >>>>>>>> On Saturday, May 25, 2024 at 10:44:17 PM UTC+8 Ruochun Zhang wrote: >>>>>>>> >>>>>>>>> Hi Weigang, >>>>>>>>> >>>>>>>>> I would like to answer Question 2 first. You can use variables >>>>>>>>> *AOwnerFamily >>>>>>>>> *and *BOwnerFamily *to refer to clump (or owner) A's and clump >>>>>>>>> B's family numbers directly in the force model. So you can write *if >>>>>>>>> *statements that treat each case accordingly. This is mentioned >>>>>>>>> in the DEME paper: You can check out Table 2. >>>>>>>>> >>>>>>>>> For Question 1, the situation is more complicated. We are actually >>>>>>>>> able to reproduce the problem you encountered (simulation freezing), >>>>>>>>> but on >>>>>>>>> consumer/gaming cards only. It runs perfectly on data center cards >>>>>>>>> and >>>>>>>>> that's what we used for generating this experiment, therefore it did >>>>>>>>> not >>>>>>>>> appear a problem for us. It's likely due to different GPU >>>>>>>>> architectures >>>>>>>>> running the same code differently, we'll try to find a solution and >>>>>>>>> let you >>>>>>>>> know in the following days, so stay tuned. By the way, you are using >>>>>>>>> a >>>>>>>>> gaming card to run the simulations, correct? >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Ruochun >>>>>>>>> >>>>>>>>> On Friday, May 24, 2024 at 8:47:00 AM UTC+8 weigan...@gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thank you for your reply! I have two questions about the demo >>>>>>>>>> "DEMdemo-Fracture-Box". >>>>>>>>>> >>>>>>>>>> (1) After i have run this demo for one day, there is still >>>>>>>>>> nothing outputed. Is it fact that the DEME will run a long time once >>>>>>>>>> a >>>>>>>>>> fracture model is used? >>>>>>>>>> >>>>>>>>>> (2) How to tell DEME the contact force models between different >>>>>>>>>> familys? I did not see any snippet which undertakes this work, >>>>>>>>>> although the >>>>>>>>>> demo has at least two kinds of contact force model. The question i >>>>>>>>>> really >>>>>>>>>> want to ask is that, if we have more than three familys in our model >>>>>>>>>> and >>>>>>>>>> there are more than two familys consist of spherical particles, how >>>>>>>>>> to tell >>>>>>>>>> DEME the contact force model between different familys, and tell >>>>>>>>>> DEME the >>>>>>>>>> contact force model between the particles of a family in the same >>>>>>>>>> time. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Weigang >>>>>>>>>> >>>>>>>>>> On Thursday, May 23, 2024 at 10:10:14 PM UTC+8 Ruochun Zhang >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> No. That's because the *sphere components* in a clump are just >>>>>>>>>>> shape representations, and they have no physics, only material >>>>>>>>>>> properties. >>>>>>>>>>> If they did have interaction with each other then every clump >>>>>>>>>>> would've >>>>>>>>>>> immediately exploded upon simulation starting. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Ruochun >>>>>>>>>>> >>>>>>>>>>> On Thursday, May 23, 2024 at 12:16:32 PM UTC+8 >>>>>>>>>>> weigan...@gmail.com wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Ruochun, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your reply! I have a question about the clump. Do >>>>>>>>>>>> the particles in a clump interact with each other via any force >>>>>>>>>>>> model? >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> Weigang >>>>>>>>>>>> >>>>>>>>>>>> On Monday, May 20, 2024 at 10:26:03 PM UTC+8 Ruochun Zhang >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Weigang, >>>>>>>>>>>>> >>>>>>>>>>>>> Yes. Again, DEME only cares about the position and radius of >>>>>>>>>>>>> the initial spheres, so you can supply it however you want. If >>>>>>>>>>>>> you have a >>>>>>>>>>>>> file that records this information using your own format, then >>>>>>>>>>>>> the easiest >>>>>>>>>>>>> thing is to have your own C++ or Python script that reads it into >>>>>>>>>>>>> arrays >>>>>>>>>>>>> and then feeds them to the solver. If your file shares the >>>>>>>>>>>>> format with DEME's standard clump output file, or your file is >>>>>>>>>>>>> simply the >>>>>>>>>>>>> output of *WriteClumpFile*, then you can conveniently load >>>>>>>>>>>>> clump positions and orientations by *ReadClumpXyzFromCsv *and >>>>>>>>>>>>> *ReadClumpQuatFromCsv *(examples are in GRCPrep_Part1 and 2). >>>>>>>>>>>>> Note that currently, sphere radius cannot be read from standard >>>>>>>>>>>>> clump >>>>>>>>>>>>> output files since it's part of the clump template information >>>>>>>>>>>>> thus not in >>>>>>>>>>>>> the clump output. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> Ruochun >>>>>>>>>>>>> >>>>>>>>>>>>> On Monday, May 20, 2024 at 12:56:56 PM UTC+8 >>>>>>>>>>>>> weigan...@gmail.com wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would like to generate a block which consists of a assembly >>>>>>>>>>>>>> spheres. Is it possible to generate the block by other code, and >>>>>>>>>>>>>> then load >>>>>>>>>>>>>> it into DEM-Engine via a file containg the informations (such as >>>>>>>>>>>>>> position >>>>>>>>>>>>>> and radius) of the spheres? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> Weigang >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>> 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 projectchron...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/projectchrono/1910af21-d1e3-43dd-a779-0c229e6150a6n%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/projectchrono/1910af21-d1e3-43dd-a779-0c229e6150a6n%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 projectchrono+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/69a858c3-89d6-4c77-bad3-801999feaee2n%40googlegroups.com.
