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/e9464818-7abd-4b17-a162-7626471f7222n%40googlegroups.com.
