Hi Mohammad, Please read one of my previous replies in this thread. I talked about it, and you can add extra accelerations to simulation objects through prescription methods. That is equivalent to applying forces. Off-topic comment: Having graduated with a degree in physics, I always believe that the idea of forces is such a crude thing in describing interactions compared to fields, and that is why I don't connect the idea of force to these user methods in DEME :)
Thank you, Ruochun On Saturday, January 21, 2023 at 1:10:03 PM UTC-6 [email protected] wrote: > Hi Ruochun, > > I have one more question regarding this topic. Is it possible to apply > constant normal/shear force to a mesh? In particular, I am interested in > applying a normal force, let's say a 100N, to the screw. Would that be > possible in DEME? Would that be equivalent to applying an acceleration in > the normal direction with a value equal to (100/mass of mesh)? > > Thank you so much in advance, > > On Thursday, January 19, 2023 at 7:54:49 PM UTC-7 Mohammad Wasfi wrote: > >> Hi Radu, >> >> Thank you so much for your reply. I believe that we have figured out the >> source of the issue we faced. It seemed that my mesh's COM point was >> located at a point (x,y,z) and not at (0,0,0) as I assumed when I wrote my >> code. I have used the *method InformCentroidPrincipal *to tell the >> solver where exactly my COM point was. After, it seemed that everything is >> working as expected. >> >> I would for sure start looking into co-simulation between Chrono and DEME >> as I start simulating larger mechanical objects. I appreciate your help! >> >> Thank you so much, >> >> On Thursday, January 19, 2023 at 8:47:15 AM UTC-7 Radu Serban wrote: >> >>> Mohammad and Ruochun, >>> >>> >>> >>> I’m late to this party but something is concerning here. If you want to >>> constrain the motion of a mechanism part, you should use precisely that: >>> constraints! In other words, you should model the mechanical multibody >>> system you are co-simulating with the granular material so that it respects >>> whatever kinematics you desire. The granular code does **not** do >>> multibody dynamics. As such, imposing the state (velocity in this case) of >>> any part of the multibody system is not proper force-displacement >>> co-simulation (which is what DEME **should** be doing) but just a >>> hack. Multibody dynamics is not as simple as that. I will not go into >>> details here, but what you are likely seeing here is due to constraint >>> drift. >>> >>> >>> >>> Since it is already possible to do a proper co-simulation of a Chrono >>> multibody system with DEME granular material, why not just use a >>> cylindrical joint (which I assume is the kinematics you are looking for) in >>> your Chrono model? >>> >>> >>> >>> Sure, for a very simple case like what you have here, you may be able to >>> get away with prescribing the full state of your “screw” (that means also >>> prescribing position-level state which I gather you are not doing). But >>> then you do not solve a dynamics problem for your mechanism. That also >>> means you wouldn’t be able to get out of the simulation quantities that (I >>> would think) are important, such as reaction forces on that screw. >>> >>> >>> >>> --Radu >>> >>> >>> >>> *From:* [email protected] <[email protected]> *On >>> Behalf Of *Ruochun Zhang >>> *Sent:* Tuesday, 17 January 2023 08:09 >>> *To:* Mohammad Wasfi <[email protected]> >>> *Cc:* ProjectChrono <[email protected]> >>> *Subject:* Re: [chrono] Re: Motion Restriction in DEM >>> >>> >>> >>> Hi Mohammad, >>> >>> >>> >>> Then it's hard to say. I can only say the tracker reports what the >>> solver sees; indeed, in the solver, X of the mesh is not modified, while Y >>> and Z are. I don't know why it does not translate to the rendering. What I >>> thought was since the X of the CoM truly did not change, then the >>> X-translation you see has to be the contribution of the rotation, and that >>> means the CoM is in fact somewhere away from the center axis of the mesh. >>> But I cannot be sure with the given information. >>> >>> >>> >>> Can you render a movie and share with us? If you are going to generate >>> the movie: since you are already outputting vtk files, can you please >>> render the mesh as, well, a mesh, instead of some points? You can load the >>> vtk time series directly into Paraview. And if you can share the mesh file, >>> I can probably run it myself to understand what happened. >>> >>> >>> >>> Ruochun >>> >>> >>> >>> On Tue, Jan 17, 2023 at 12:40 AM Mohammad Wasfi <[email protected]> >>> wrote: >>> >>> Hi, >>> >>> >>> >>> This is a picture of my mass properties page in Solidworks. I also >>> included a picture of the module. >>> >>> >>> >>> Thank you, >>> >>> Mohammad >>> >>> On Monday, January 16, 2023 at 11:01:37 PM UTC-7 Ruochun Zhang wrote: >>> >>> Are you sure the mesh you loaded from the file is centered (i.e. its MOI >>> is at (0,0,0) in the mesh file)? Can you show a rendering of the >>> *screw.obj* file you used in some CAD tool for us to understand? >>> >>> >>> >>> Thank you, >>> >>> Ruochun >>> >>> On Monday, January 16, 2023 at 10:36:03 PM UTC-6 [email protected] >>> wrote: >>> >>> Hi Ruochun, >>> >>> >>> >>> Thank you so much for your reply. I have tried to implement these >>> methods and I am experiencing something not expected. I apply the following >>> methods to my cylindrical mesh: >>> >>> DEMSim.SetFamilyPrescribedLinVel(3, "0","none", "none", false); >>> DEMSim.SetFamilyPrescribedAngVel(3, "0", >>> to_string_with_precision(w_r), "0", false); >>> >>> >>> >>> my purpose is to have my cylindrical wheel spin about its axis (y-axis) >>> while disallowing linear motion in the axis perpendicular to the cylinder >>> axis (x-axis). For some reason, when I animate my simulation, my wheel is >>> spinning about its axis (which is what I want) but it is allowed to move >>> linearly in the X-direction while it is restricted to move in the >>> y-direction. However, when I obtain my mesh position through the tracker, >>> the simulation reports a change in the Y-axis but not in the x-axis. In >>> other words, my simulation animation is not consistent with my position >>> vector obtained from the simulation at each time step. For example, from >>> the simulation, my tracker returns the following values for the position: >>> >>> Frame: 91 of 206 >>> mesh position: -0.1, -0.00142017, -0.111681 >>> >>> Frame: 92 of 206 >>> mesh position: -0.1, -0.00152285, -0.113109 >>> >>> However, in the simulation, the animation shows a movement in the >>> x-direction. I attached some pictures to demonstrate this change. >>> >>> >>> >>> The weird thing is when I change the SetFamilyPrescribedLinVel to >>> restrict the y-axis instead I still see the same result. I attached my >>> simulation file for your reference. >>> >>> >>> >>> Thank you so much, >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Friday, January 6, 2023 at 2:48:34 PM UTC-7 Ruochun Zhang wrote: >>> >>> Hi Mohammad, >>> >>> >>> >>> I assume you meant "restrict the motion in one direction and *disallow* >>> it into other directions". You can do it. In fact, you can prescribe the >>> motion in one direction while allowing free movements in other directions, >>> too. >>> >>> >>> >>> The methods you should use are the following: >>> >>> *SetFamilyPrescribedLinVel* >>> >>> *SetFamilyPrescribedAngVel* >>> >>> *AddFamilyPrescribedAcc* >>> >>> *AddFamilyPrescribedAngAcc* >>> >>> >>> >>> A better example is DEMdemo_WheelDP.cpp >>> <https://github.com/projectchrono/DEM-Engine/blob/main/src/demo/DEMdemo_WheelDP.cpp>. >>> >>> There, *DEMSim.SetFamilyPrescribedAngVel(2, "0", >>> to_string_with_precision(w_r), "0", false)* means Family 2 will always >>> have 0 angular velocity in X, *w_r *angular velocity in Y, and 0 >>> angular velocity in Z. Other simulation entities cannot change the angular >>> velocities of the entities that are in Family 2. And, >>> *DEMSim.SetFamilyPrescribedLinVel(2, >>> to_string_with_precision(v_ref * (1. - TR)), "0", "none", false)* >>> further specifies that Family 2 will always be moving linearly along X at >>> *v_ref >>> * (1. - TR)* velocity, not moving linearly along Y, and the linear >>> motion is not prescribed along Z, meaning if the contact/environmental >>> forces make the entities to move along Z, it will accept these changes, >>> unlike in X or Y directions which are prescribed. >>> >>> >>> >>> You should keep the last argument to be *false *in your case. If it is >>> *false*, then angular/linear velocity directions/components that are >>> not specified *or* specified with "none", will just go with the >>> "simulation physics" (instead of any user prescription). If it is *true*, >>> then this family's angular/linear velocity becomes prescribed >>> unconditionally (the solver does not attempt to change them), and any >>> unspecified components will stay at the current value (0 as default). >>> >>> >>> >>> That is for the velocities. For the 2 acceleration-related methods, you >>> can only "add" extra accelerations to a family; you cannot prescribe the >>> acceleration that an entity experiences, because a contact is a contact, >>> and you cannot wipe it out. (And if you do wish to manipulate contacts, >>> custom contact models are your friends.) You can prescribe the consequence >>> of these forces though, and that is the velocity. >>> >>> >>> >>> The string arguments in these methods can be a number or some >>> expressions that may involve "t", the simulation time. So you can write >>> something like "*5 / 10*" or "*sin(3.14 * 2 * t)*" as the argument, >>> too. More such "user-referrable variables" might be added in future >>> versions. But if it is some super complex motion that cannot be described >>> with a simple expression, then you are better off just fixing the family ( >>> *SetFamilyFixed*), then using a tracker class to manually set the >>> positions and velocities of the entity in question, step by step. >>> >>> >>> >>> Thank you, >>> >>> Ruochun >>> >>> >>> >>> On Thursday, January 5, 2023 at 3:28:28 PM UTC-6 [email protected] >>> wrote: >>> >>> Hi, >>> >>> This is DEME related question >>> >>> >>> >>> Is it possible to restrict the motion in one direction and allow it into >>> other directions? For example, is it possible to apply some force to an >>> object (A) through an interaction with another object (B) and only allow >>> it (A) to move in the X direction when responding to that force but not the >>> Y and Z directions? An example code will be much appreciated. >>> >>> >>> >>> Thank you so much, >>> >>> -- >>> 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/91f6ec2b-f5b8-4014-8176-0cbd87010984n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/projectchrono/91f6ec2b-f5b8-4014-8176-0cbd87010984n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> >>> >>> -- >>> >>> Ruochun Zhang >>> Email: [email protected] >>> Email: [email protected] >>> Tel: 832-353-5111 <(832)%20353-5111> >>> >>> -- >>> 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/CAHvQpOtftnbiQx36NMvifUF0RA5uyFoWX%3DBYNWy9N6TH%2BCUPDQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/projectchrono/CAHvQpOtftnbiQx36NMvifUF0RA5uyFoWX%3DBYNWy9N6TH%2BCUPDQ%40mail.gmail.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 on the web visit https://groups.google.com/d/msgid/projectchrono/32f2b922-e34e-40b7-8b94-92a8e0d7b3c9n%40googlegroups.com.
