Hi Weigang, If you meant you need the total force and torque each particle experiences, then while DEME does not output that to files, it can output each particle's acceleration and angular acceleration, and the force and torque can be post-processed by you using F=ma and τ=Iα.
As for the mass, if you are using WriteClumpFile, then the name of the clump template (default is "0000", "0001," etc., and you can assign names at clump creation) should be outputted, so you know the mass, as it is defined by you at the time of clump template creation. If you are using WriteSphereFile, then it doesn't naturally come with this information (as you know technically, sphere components, even if you are using one-sphere particles, do not have mass properties). So you can either switch to WriteClumpFile, or perhaps assign a unique family number to each different type of particles, then choose to output the family number into the file, then you have an idea of the mass of each sphere. If you are looking for something more advanced, like the force for each contact (like a "force-web" plot), then that is achieved by using WriteContactFile and you could probably look into some of the demos that use this function. Thank you, Ruochun On Tuesday, April 1, 2025 at 1:18:01 AM UTC+8 [email protected] wrote: > Hi Ruochun, > > I have aquestion that how to output the mass, force and torque of > particles into the outputfile? > > Thank you! > Weigang > > On Wednesday, July 3, 2024 at 11:35:21 AM UTC+8 Ruochun Zhang wrote: > >> If your input (specifically, the input of the "center" argument) is in >> *float3 >> *format, then it outputs a vector of* float3*s. If your input is in the >> format of a vector of 3 *float*s (like {1.0, 2.0, 3.0}), then it outputs >> a vector of vectors that each contain 3 *float*s. >> >> Ruochun >> >> On Wednesday, July 3, 2024 at 8:06:02 AM UTC+8 [email protected] wrote: >> >>> Hi Ruochun, >>> >>> Thank you for your reply! Could you tell us about the data format of the >>> input xyz generated by the HCPSampler? >>> >>> Thank you, >>> Weigang >>> >>> On Monday, July 1, 2024 at 4:37:11 PM UTC+8 Ruochun Zhang wrote: >>> >>>> You can *SetVel *to simulation entities, such as particles, before the >>>> simulation starts. You can for example see how it is used at line 150 of >>>> *DEMdemo_GRCPrep_Part1*. >>>> >>>> Thank you, >>>> Ruochun >>>> >>>> On Thursday, June 27, 2024 at 3:03:00 PM UTC+8 [email protected] >>>> wrote: >>>> >>>>> You are right. In fact, the scenario i would like to model is that >>>>> the impact of a rock block onto a palte after a freefall. I would like to >>>>> set a initial velocity for the rock block according to the freefall >>>>> height. >>>>> So, how to set a initial velocity? >>>>> >>>>> Thank you, >>>>> Weigang >>>>> >>>>> On Thursday, June 27, 2024 at 12:54:00 PM UTC+8 Ruochun Zhang wrote: >>>>> >>>>>> That depends on whether we are on the same page about the concept of >>>>>> prescribing velocity. You understand that when the particles come in >>>>>> contact with the plate, they cannot keep whatever velocity you assigned >>>>>> them before, if you respect the contact force. So you either respect the >>>>>> contact force or do not respect it. By assigning a prescribed velocity >>>>>> to a >>>>>> family, you choose not to respect the contact force's influence on the >>>>>> entities, and always enforce this velocity. >>>>>> >>>>>> What I understand that you wish to achieve is to ensure the particles >>>>>> have a certain velocity at the moment they come in contact with the >>>>>> plate. >>>>>> That is not a velocity prescription. That can instead be done in some >>>>>> other >>>>>> ways. For example, initialize the simulation such that the particles are >>>>>> touching the plate, and give the particles an initial velocity then >>>>>> start >>>>>> the simulation. But I don't know if I understand what you wanted to do >>>>>> correctly, >>>>>> >>>>>> Thank you, >>>>>> Ruochun >>>>>> >>>>>> On Thursday, June 27, 2024 at 11:14:42 AM UTC+8 [email protected] >>>>>> wrote: >>>>>> >>>>>>> Hi Ruochun, >>>>>>> >>>>>>> After removing the line which prescribe the linear motion, the >>>>>>> particles can contact with the plate. However, if we have to prescribe >>>>>>> a >>>>>>> velocity for the particles, where should we add this line? >>>>>>> >>>>>>> Thank you, >>>>>>> Weigang >>>>>>> >>>>>>> On Friday, June 21, 2024 at 3:12:06 PM UTC+8 Ruochun Zhang wrote: >>>>>>> >>>>>>>> Hi Weigang, >>>>>>>> >>>>>>>> This is because you prescribed the linear motion of family 1 (which >>>>>>>> is for all the particles) to be -1.0. When the velocity is prescribed, >>>>>>>> the >>>>>>>> simulation entities won't accept the influence of physical contacts, >>>>>>>> and >>>>>>>> will keep the prescribed velocity no matter what. This is exactly what >>>>>>>> we >>>>>>>> see in the simulation. Removing that line should fix it. You probably >>>>>>>> meant >>>>>>>> to add an initial velocity. >>>>>>>> >>>>>>>> Ruochun >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Friday, June 21, 2024 at 9:05:11 AM UTC+8 [email protected] >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Ruochun: >>>>>>>>> >>>>>>>>> The script is attached below. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Weigang >>>>>>>>> >>>>>>>>> On Thursday, June 20, 2024 at 7:27:35 PM UTC+8 Ruochun Zhang wrote: >>>>>>>>> >>>>>>>>>> I assume you are doing it via a custom force model. In that case, >>>>>>>>>> this problem is very similar to the exact demo we provided (which >>>>>>>>>> runs). >>>>>>>>>> You have to tell us what you changed in order for us to give >>>>>>>>>> suggestions. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Ruochun >>>>>>>>>> >>>>>>>>>> On Thursday, June 20, 2024 at 6:55:10 PM UTC+8 >>>>>>>>>> [email protected] wrote: >>>>>>>>>> >>>>>>>>>>> Hi Ruochun, >>>>>>>>>>> >>>>>>>>>>> I am currently modelling the impact of a rock block against a >>>>>>>>>>> plate. However, as shown below, the spheres penetrate through the >>>>>>>>>>> plate >>>>>>>>>>> without any contact with the plate. Could you give some suggestions? >>>>>>>>>>> [image: 微信图片_20240620185350.jpg] >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Weigang >>>>>>>>>>> >>>>>>>>>>> On Thursday, June 20, 2024 at 5:02:38 PM UTC+8 Ruochun Zhang >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>>>> [email protected] 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 < >>>>>>>>>>>>>>>>>> [email protected]> 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 >>>>>>>>>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>>>>>>>>>>>>> [email protected] 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 >>>>>>>>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>>>>>>>> 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/projectchrono/1f087425-d695-440b-8cb4-8d52258fa9bcn%40googlegroups.com.
