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/7aa257f0-8865-4f77-afd4-956eed84de47n%40googlegroups.com.
