FSI module

[Mohammad Wasfi]

Hello, 

I am trying to create a simulation based on the single-wheel demo. In my simulation, I am using a screw instead of a wheel. I started with changing the way the material properties are imported into the simulation. Everything worked fine as shown in the attached video. However, now, I am trying to reduce particle diameter ( as well as initial spacing). The simulation seems to freeze at the beginning and no error is printed. I was wondering if more insight could be provided into why the simulation freezes when reducing the particle diameter with no error printed. 

Thank you in advance for your help, 

[Dan Negrut]

Mohammad – we’ll try to take a look, things are backed up, hopefully we can help in some way…

Dan

---------------------------------------------

Bernard A. and Frances M. Weideman Professor

NVIDIA CUDA Fellow

Department of Mechanical Engineering

Department of Computer Science

University of Wisconsin - Madison

4150ME, 1513 University Avenue

Madison, WI 53706-1572

608 772 0914

http://sbel.wisc.edu/

http://projectchrono.org/

---------------------------------------------

--
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 projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/239386b1-d155-40a8-bf1c-6999db12484fn%40googlegroups.com.

[Mohammad Wasfi]

Thank you so much, Professor. I have tested the code with some other initial spacing values and it seems that the code starts working again when I set my initial spacing value to 1.5*particle diameter (originally, the initial spacing value was set to be 0.0033m while the particle diam is 0.003m). It would still be helpful to look into why the code froze and no errors were outputted whenever you have time for it. 

Thank you so much for all the help, 

[Luning Fang]

Hello Mohammad, 

From the error message, the job was terminated for exceeding time limit, meaning the job is still running, it just takes a very long time. From the output message, the FSI solver did not get initialized either. Your FSI parameters look good to me  

Without running your simulation, I think it's likely that something is wrong with CreateMeshPoints(), which is for generating BCE markers that describe the screw geometry. Since decreasing resolution will take longer time to generate the markers, the program could still be computing the markers. The implementation right now doesn't scale well with higher resolution. It might also got stuck in some infinite loop ... I will need the screw geometry to look into this more.

You can also generate the BCE markers yourself, and read the points in the FSI program, then attach them to the screw body using AddPointsBCE(). That way you have control over how to place the grid points so it can capture the geometry. You can also speed up the process by parallelize your implementation. You only need to do it once. 

Thank you,

Luning

[Mohammad Wasfi]

Thank you, Luning, 

I have a few more questions that I hope you can answer for me.

1- In the single-wheel demo, the wheel's movement is restricted in the x-direction, and the wheel is allowed to move in the y-direction. However, for this simulation, I am trying to change the movement restriction for the screw from the x to the y direction and allow the screw to move in the x-direction. I have tried to change multiple things but nothing seems to work as I intended. Right now, it seems that my screw is restricted from moving in both the x and y directions. I am just trying to remove any restrictions put on the screw in the X-direction as the screw tried to propel itself and move.  I was wondering if you could take a look at my code and tell me if you see such a restriction set.

2- Similar to the single wheel demo, I use the function " ComputeMassProperties" to compute the screw mass, cog, and inertia tensor. For some reason, the results returned by that function are different from what my CAD program provides for the same material. I was wondering why that is. 

Example:

Computed mass from code: 0.00078467 ( I am not even sure what the units of this should be. All parameters I used had units of kg/m/etc. I assume that this is supposed to be kg. However, It is a very small value compared to what CAD provides). 

computed mass from CAD: 1.71 kg

Thank you so much,  

[Mohammad Wasfi]

Apologies, I uploaded the wrong cpp file. Attached is my latest one. 

[Luning Fang]

Hello Mohammad,

In the single wheel test demo for FSI, the longitudinal direction is global X, the lateral direction is global Y, the wheel's motion is restricted in Y direction, while the X direction has a prescribed motor function. 

When you connect bodies with links, be careful with how you define the degree of freedom of the constraint. Specifically, for prismatic joint, it allows translation along the Z axis. For instance in this line of your code,

prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2)));

The joint frame is aligned with Q_from_AngX(Ch_C_PI_2), which rotates 90 degrees around global X, since the ground is fixed, the chassis can move freely in the global Z direction, but not X or Y direction. However, the actuator is applying a motion in X direction, but restricting motion in Y and Z. That's why the screw is not moving in any direction.

I suggest you play with some demos in the mbs folder, such as demo_MBS_motor.cpp or demo_MBS_crank.cpp. The visualization can help you better understand how joint frames are defined in Chrono. You can also have a mbs model of the screw setup only (without the FSI terrain, but the chassis-axel-screw setup). All you need is the code in the CreateSolidPhase(). Again, with the visualization, it's easier to figure out what was wrong.

For your second question, note that ComputeMassProperties() only has the information of the obj mesh, which is the geometry of the object, whatever computed has to be multiplied by the density to get mass and inertia of the object. 

Thank you,

Luning

[Mohammad Wasfi]

Hi Luning, 

Thanks for the reply. I have looked into links and how they are used by simulating different options for a short amount of time. I am a little confused as testing different options did not seem to make much sense. 

For a prismatic joint is defined as: 

prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), QUNIT));

The motion is allowed in the Z-dir. However, in the SingleWheel demo, the joint is defined as:

prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), Q_from_AngY(CH_C_PI_2)));

which results in the motion being allowed in both the x and z directions (two directions). However, when changing the input to this

prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2)));

The motion becomes restricted in both x and y and only free in z. Why is that?

To try to navigate through this, I started by removing the actuator completely from my implementation as I only added it to be able to extract the forces on the screw (Is there a way to extract the forces on the screw without having to use an actuator?). Then, I have only two prismatic joints left ( one between the ground and the chassis and one between the chassis and axle). I started my tests by having the input for my prismatic joint as Q_from_AngY(CH_C_PI_2). This resulted in my screw moving in the z and x directions as expected. Then, I changed the input to Q_from_AngX(CH_C_PI_2), and also as expected, the screw was allowed to move in z-direction but not in x and y. As a result, I started thinking that maybe the second joint is what is preventing my screw from moving in certain directions. As a result, I tried the following combinations:

1 - prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), Q_from_AngY(CH_C_PI_2)));

     prismatic2->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), QUNIT));

( screw moved in both x and z)

2- prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), QUNIT));

prismatic2->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), Q_from_AngY(CH_C_PI_2)));

(screw moved in x and z)

3- prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), QUNIT));

prismatic2->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), QUNIT));

(screw moved only in z)

4 - prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), Q_from_AngXCH_C_PI_2)));

     prismatic2->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), QUNIT));

( screw moved only in z)

5- prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), QUNIT));

prismatic2->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2))); 

( screw moved only in z)

6- prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(),  Q_from_AngX(CH_C_PI_2)  ));

prismatic2->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2))); 

( no movement)

I then thought that maybe the type of link I was using was not correct. I looked into different links (Project Chrono: Links) and could not find one that seems appropriate. I have also looked at the demos you specified to try to better understand (crank demo) and it does not look like the prismatic link is used there.  However, the ChLinkLockPointLine link seems like something that can be used in my case but I cannot tell what the difference is between this link and the prismatic link. As for the motor, the motor seems to work well so far as the screw rotates about its axis as it is supposed to. 

One final note, I have multiplied the mass obtained with ComputeMassProperties() by the screw density and got 0.9888. This is still quite different from what my CAD provides (1.71kg). Any insight about this? The inertia values are also off. 

Sorry about the very long message and thank you so much for all your help, 

[Luning Fang]

Hello Mohammad,

Can you attach a sketch of your setup that describes the actuator and the constraints. Specifically, what rotational and translational motion of the screw are supposed to be constrained? 

Thank you,

Luning 

[Mohammad Wasfi]

Hi Luning, 

I have attached my drawing for you. To mention again, I do not have an actuator in my system. My components are (screw, chassis, axle, Link1 (ground chassis), Link2 (axle, chassis), and motor (screw, axle)). The screw has a constant angular velocity and is supposed to propel itself and move in the forward direction ( y in the picture). Additionally, no motion is allowed in the x direction. and the screw is free to move in the z-direction. 

Thank you, 

[Mohammad Wasfi]

Hi, 

Just following up on this, 

Thank you

[Luning Bakke]

This should be the correct setup for the constraints,

 prismatic1->Initialize(ground, chassis, ChCoordsys<>(chassis->GetPos(), Q_from_AngX(CH_C_PI_2)));

 prismatic2->Initialize(chassis, axle, ChCoordsys<>(chassis->GetPos(), QUNIT));

prismatic joint allows translation in the z direction of the joint frame. For prismatic1, Q_from_AngX(pi/2) is a joint frame with its z aligning with global y, which is what you want for your setup. 

You said the screw only move in z direction, but there's no motion in y direction. Since the MBD setup is correct, there could be other issues. Have you looked at the forces from the terrain to the screw in global y direction? 

Thank you,

Luning