Question regarding the wheel file format in the DEME demo WheelSlopeSlip

[Victor Michel]

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

[Ruochun Zhang]

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

[Victor Michel]

Hello Ruochun,

Thank you for your answer and for the explanation, you made it very clear.

Victor.

[Victor Michel]

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.

[Ruochun Zhang]

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

[Victor Michel]

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.

[Ruochun Zhang]

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

[Victor Michel]

Hi Ruochun,

Thank you for your precious advice.

1-2) After correcting my implementation of Scale and re-running the simulations, the simulation with smaller wheel end up taking less time. I think the explanation might be that my previous implementation of Scale was altering the shape of the wheel ?

 3) I'm sorry I should have joined the mesh file right away. Here are two meshes that I tried to use (same wheel shape but different size). I don't think they are that much more refined that the curiosity rover wheel file used in the other demos ?

Thank you again for your help !
Victor

[Ruochun Zhang]

Hi Victor,

I'll try to answer all the questions together as they should be all related to the mesh.

First, I was surprised that the "smaller" wheel mesh is around 10000 times smaller than the other one... I don't know why it's designed this way, but it leads to problems: If you directly use it, then it's too small to represent anything physically meaningful; Most of the 6 or 7 digits that you have presenting the XYZ of each node are wasted since they are used to store the mesh's offset from the origin (0,0,0), rather than the relative difference in spatial locations among mesh nodes. This mesh is probably yanked from something else bigger, but that doesn't mean you don't have to pre-process it to make it reasonable.

Speaking of scaling a mesh that is not centered at the origin: It will also enlarge the distance between the origin and the mesh. This is because the scaling function will just multiply the XYZ of each node---it's a very lightweight utility anyway. For example, since your mesh originally sits at Y coordinate being around 5, so if you want the mesh to appear in the simulation at Y being near 0, then the initial Y coordinate of the mesh must be -5; and if the mesh is enlarged 10 times by Scale, then you have to set the initial to be -50. You could correct the CoM (drag it back to 0,0,0) of the mesh by using Move before setting the initial location of the mesh, but I guess at this point, the easiest thing you can do is instead just re-create the mesh, so its CoM lies directly on the (0,0,0) point of your mesh. 

Also you should InstructBoxDomainDimension to make sure your domain is big enough to hold everything you have in the simulation.

I suspect the many anomalies you observed are caused by the wheel being at unexpected locations and having unexpected sizes or shapes when the simulation starts. But all these you should be able to spot by outputting and rendering the system after initialization. Did you try that and can you show us if the initial status of the simulation looks all right?

Thank you,

Ruochun

[Victor Michel]

Hello Ruochun,
I'm sorry for the late reply.
You were right, the mesh was the issue. I had it re-made centered and now the simulation seems to work fine !
And yes one of them was very small because I'm still trying to figure out how mesh size is adapted into the simulation and how to scale them exactly how I want ! But yes this small was probably a bit overkill.

Thank you again for your help !
Victor