Hi Victor, First, I'd suggest that you ensure enough RAM is on the system, so we exclude that as a cause for performance or stalling issues. Then...
1) Using a smaller wheel in this case should have a minimal impact on the performance. If you say it's slower than using a clump wheel, then that is possible. But if you say that's several times slower than before, that's not normal. I suggest you visualize the simulation to see if the particles are behaving normally (if the simulation is near-divergence, it may run slowly), and gauge how much slower it has become. A comparison between the metric output (timing stats, collab stats) is also important, and that's why I always have them in the demos. 2) Yes. The *Scale *function changes the size of that object in each direction by the amount specified as arguments, not scaling the object to that size specified by the arguments. It won't work as intended if you just use wheel radius and width as arguments. Instead, you have to figure out the ratio between the target size and the original size of the mesh. 3) Looks like the initialization didn't even finish. It's hard to say anything without seeing the mesh (if that's the only thing that got changed). Note that the mesh size is not important but the mesh quality is usually super important. You have to use a valid mesh: use a surface mesh that you would safely do FEA with. That aside, it's still hard to break the initialization though. Is the mesh so refined that it uses all the memory? Ruochun On Friday, August 23, 2024 at 2:12:27 PM UTC+8 Victor Michel wrote: > Hello Ruochun, > > Thank you again for the help you are providing me with. > I had definitely missed the *Scale *part, which I now added after > creating the wheel : > auto wheel = > DEMSim.AddWavefrontMeshObject(GetDEMEDataFile( > "mesh/rover_wheels/viper_wheel_right.obj"), mat_type_wheel); > wheel->Scale(make_float3(wheel_rad * 2, wheel_width, wheel_rad * 2)); > wheel->SetMass(wheel_mass); > wheel->SetMOI(make_float3(wheel_IXX, wheel_IYY, wheel_IXX)); > // Give the wheel a family number so we can potentially add prescription > wheel->SetFamily(10); > // Track it > auto wheel_tracker = DEMSim.Track(wheel); > > I also, as you suggested, lowered the load and mass of the wheel : > // Define the wheel geometry > float wheel_rad = 0.025; > float wheel_width = 0.02; > float wheel_mass = 0.034; > float total_pressure = 0.154 * G_mag; > float added_pressure = (total_pressure - wheel_mass * G_mag); > float wheel_IYY = wheel_mass * wheel_rad * wheel_rad / 2; > float wheel_IXX = (wheel_mass / 12) * (3 * wheel_rad * wheel_rad + > wheel_width * wheel_width); > > Now the simulation is effectively running but I have some new questions if > that is okay : > > 1) The simulation now seems to be running much much slower, which seems > counter intuitive to me because since the wheel is smaller and lighter it > should be causing a smaller perturbation of the material overall. Do you > know what may have caused that slowing down ? > > 2) After visualizing the output .vtk in Paraview, the wheel size doesn't > seem to match the values I imputed (the output vtk has a radius of 0.011 > and a width of 0.007). Did I use the *Scale *function wrong ? > > 3) I also tried to use another .obj mesh file for the wheel, however then > the simulation doesn't even seem to really start and the program just stops > after outputting *WARNING! Some clumps do not have their family numbers > specified, so defaulted to 0. *While the size of the wheel is different > in that new .obj file (about twice as big as the curiosity wheel in its > .obj file) I didn't think this was important since I then re-scale the > wheel, but maybe I was mistaken ? > > Thank you ! > Victor. > Le mardi 20 août 2024 à 03:50:50 UTC+9, Ruochun Zhang a écrit : > >> Hi Victor, >> >> Sounds to me like the simulation diverged. I note that in this demo, when >> you change the two variables, you don't automatically change the size of >> the wheel, because there is no scaling or anything applied to the mesh you >> loaded so it's still the same as before (you may want to add a *Scale *call >> to it). So by changing the radius and width, you just modified the mass and >> the moment of inertia of the wheel. And it appears that you didn't change >> the overall load (used to emulate the chassis the wheel carries), so it >> probably just makes the wheel hit the soil with a higher initial velocity, >> leading to divergence. There could be other reasons. >> >> To resolve that, you could try reducing the step size, or making the >> total load lower so that the simulation setup is more consistent with what >> you wanted (a.k.a. the suggestion given by the solver: relaxing the >> physics). Perhaps you just need to use a smaller step size for the starting >> one second or so, and remember you can change the step size on-fly via >> *UpdateStepSize*. I want to note that this current step size, 2e-6s, is >> already quite demanding, since there are super small particles involved in >> this GRC representation. For mobility tests or for project prototyping >> purposes, you can consider using much larger particles for the terrain to >> speed the simulation up without sacrificing too much accuracy, like in >> *DEMdemo_WheelDPSimplified*. That'd also allow for much larger step >> sizes. >> >> Thank you, >> Ruochun >> >> On Monday, August 19, 2024 at 7:05:29 PM UTC+8 Victor Michel wrote: >> >>> Hello Ruochun, >>> After trying some things with the demo (WheelSlopeSlip) I have a follow >>> up question : >>> After importing the mesh of the curiosity rover wheel (instead of the >>> "clump wheel") I manage to run the demo with no problem, which is great. >>> However, when I tried changing the size of the wheel by dividing the >>> wheel_rad and wheel_width (line 43 and 44) by 10, I then get a max velocity >>> exceed max allowance error. I joined the modified .cpp file I used as well >>> as a .txt of the output I got. >>> Since I'm trying to make the wheel smaller I don't think it is caused by >>> an initial penetration, but maybe I missed something ? >>> Do you have an idea about what could be causing this ? >>> Thank you in advance, >>> Victor. >>> Le mercredi 14 août 2024 à 17:04:53 UTC+9, Victor Michel a écrit : >>> >>>> Hello Ruochun, >>>> >>>> Thank you for your answer and for the explanation, you made it very >>>> clear. >>>> >>>> Victor. >>>> >>>> Le mardi 13 août 2024 à 21:45:51 UTC+9, Ruochun Zhang a écrit : >>>> >>>>> Hi Victor, >>>>> >>>>> There is no particular reason, other than it being a demo that shows >>>>> "big clumps" are possible and a use case of them. So you can use an obj >>>>> mesh to replace it. >>>>> >>>>> As for the physics, a clump representation offers more surface >>>>> roughness, so it could lead to higher drag compared to a smooth >>>>> mesh-represented surface, unless you specifically model the mesh surface >>>>> to >>>>> compensate. However, in the case where the drag is provided mostly by the >>>>> grousers, my experience is that the discrepancy becomes less pronounced. >>>>> >>>>> Thank you, >>>>> Ruochun >>>>> >>>>> On Tuesday, August 13, 2024 at 6:14:55 PM UTC+8 Victor Michel wrote: >>>>> >>>>>> Hello, >>>>>> In the WheelSlopeSlip demo of DEME the wheel is imported as a .csv >>>>>> because, as stated in the presentation of the demo, it is imported as a >>>>>> set >>>>>> of clumps. >>>>>> I was wondering if there was any particular reason to have done this >>>>>> (aside from proving it could be done) instead of importing a .obj mesh >>>>>> file >>>>>> like in the WheelDP demo? Or can I just adapt the WheelSlopeSlip demo to >>>>>> have it run importing .obj files (based on how it is done in the WheelDP >>>>>> demo)? >>>>>> >>>>>> Thank you ! >>>>>> Victor >>>>>> >>>>>> -- 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/2a5f19f6-ef8c-4bad-a514-413f750949c7n%40googlegroups.com.
