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/848d4ac9-dea1-4437-a756-3ec7841b3a53n%40googlegroups.com.
