Question about the new DUMMY_BOUNDARY

1

I notice that next have included the new BOUNDARY CONDITION, DUMMY.
Actually, I have written it before, basing on another code.

There are some points that I am very interested in.
If my understanding is right. This boundary condition is proposed by S.Adami(JCP, 2012).
However, the equation calculating the pressure
image
is different with that of GPUSPH.
const float3 accel_delta = d_gravity - make_float3(dummyVelArray[index]);

In Adami’s paper. a_w is the acceleration of boundary, instead of particles accelerate used in GPUSPH.
However, the above is only understood literally.

In EULER, dummyVelArray is valued by the boundary linear acceleration and its angular acceleration, which means dummyVelArray in COMPUTE_BOUNDARY do represent the accelerate of the boundary.
as_float3(pdata.vel) = d_rblinearvel[obj] + cross(d_rbangularvel[obj], relPos);

pdata.acceleration = pdata.ptype == PT_BOUNDARY ?
		(pdata.vel - pdata.acceleration)/dt :
		make_float4(NAN);

Moreover, dummyVelArray has information of the angular acceleration of each particle.
Then, only one is different. That is in S.Adami’s model. the angular acceleration of particles is ignored while it is considered in GPUSPH.

Is my understanding consistent with that of developers.
Regards.

2

I actually think this is unclear from the paper. The test case that highlights the importance of the acceleration contribution only deals with linear acceleration (freefall test case, 7.1), and the one where the acceleration due to angular motion is present (7.3) does not mention if it was used or not. I guess we should design a few test cases (one with only linear, one with only angular, and one with both kinds of acceleration) to see which approach gives the best results.

3

I think angular acceleration should be considered.
I have tested water entry of a rotating object before, the result is bad due to particle penetration. Now I think the ignorance of angular acceleration could be a factor.

Anyway, I can ask prof. Hu next time.

4

Hello @JoJo, have you had the opportunity to talk to prof. Hu about this detail?

5

I didn’t ask prof.Hu.
They will host a virtual meeting on Friday this week. However, in Chinese.

However, I think you are right. a_w should be particle acceleration. Details can be found in Numerical simulation of interactions between free surface and rigid body using a robust SPH method - ScienceDirect.
In GPUSPH-next, the acceleration is calculated by (u_n+1-u_n)/dt. But I think we can leave it to chrono to obtain the linear and angular acceleration. Then implement them on calculating the acceleration of a single particle.

BTW, prof.Hu have their own open-source code. https://www.sphinxsys.org/
I have noticed that in their code, this boundary condition is not included instead of a oneside Riemmen problem A weakly compressible SPH method based on a low-dissipation Riemann solver - ScienceDirect. It is quite different with
DUMMY_CONDITION. The most difference is that in this method the dummy particles no longer holds an unique values.

6

Hello @JoJo,

thanks for looking into this, and for the references. I agree that the particle acceleration should be computed from the body acceleration directly. The current approach was used as a “quick & dirty” solution that could be computed directly on GPU without restructuring too much of the code host-side.
It’s true that with Chrono we can get the linear and angular acceleration from Chrono,
but we must also support users that don’t use Chrono (e.g. because they only have moving bodies with prescribed motion), so it looks like fixing this will require some Problem API breakage, since we need the user functions to also set the acceleration.

7

Actually, as a user, I enable Chrono no matter if I am computing a floating object, since it can measure forces. Also I think it won’t take much time (but I never enable collision or something else)

8

Of course if the user needs the forces they are going to enable Chrono, but if all they need is e.g. a simple wave maker or other moving part without force feedback, there is no need for Chrono. This is why it’s important to support this case too. Of course this isn’t much more complicated that the Chrono case. The only downside is that the user will also have to set the acceleration, so the moving body data will need some extra fields, and we should check that they are set when DUMMY is enabled.

9

I agree. It’s really hard to meet all the needs. :rofl: