# Question about the new DUMMY\_BOUNDARY **URL:** \ **Category:** Uncategorized\ **Created:** [August 30, 2021, 1:59am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161 "2021-08-30T01:59:18Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![JoJo](https://avatars.discourse-cdn.com/v4/letter/j/ecd19e/32.png) [@JoJo](https://gpusph.discourse.group/u/JoJo)\ **Post date:** [August 30, 2021, 1:59am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/1 "2021-08-30T01:59:18Z")
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](https://global.discourse-cdn.com/free1/uploads/gpusph/original/1X/c48ddade2db9b5179adca7e149b5c75279fd0c21.png) 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);` ```auto 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. ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [August 30, 2021, 6:07am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/2 "2021-08-30T06:07:07Z")
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. ---
**Author:** ![JoJo](https://avatars.discourse-cdn.com/v4/letter/j/ecd19e/32.png) [@JoJo](https://gpusph.discourse.group/u/JoJo)\ **Post date:** [August 30, 2021, 6:56am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/3 "2021-08-30T06:56:21Z")
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. ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [October 11, 2021, 4:24pm UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/4 "2021-10-11T16:24:08Z")
Hello @JoJo, have you had the opportunity to talk to prof. Hu about this detail? ---
**Author:** ![JoJo](https://avatars.discourse-cdn.com/v4/letter/j/ecd19e/32.png) [@JoJo](https://gpusph.discourse.group/u/JoJo)\ **Post date:** [November 7, 2021, 4:36am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/5 "2021-11-07T04:36:49Z")
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](https://www.sciencedirect.com/science/article/pii/S0029801815000323). 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/](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](https://www.sciencedirect.com/science/article/pii/S0021999117300438). It is quite different with `DUMMY_CONDITION`. The most difference is that in this method the dummy particles no longer holds an unique values. ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [November 7, 2021, 7:19am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/6 "2021-11-07T07:19:13Z")
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. ---
**Author:** ![JoJo](https://avatars.discourse-cdn.com/v4/letter/j/ecd19e/32.png) [@JoJo](https://gpusph.discourse.group/u/JoJo)\ **Post date:** [November 7, 2021, 7:43am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/7 "2021-11-07T07:43:01Z")
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) ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [November 7, 2021, 7:49am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/8 "2021-11-07T07:49:04Z")
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. ---
**Author:** ![JoJo](https://avatars.discourse-cdn.com/v4/letter/j/ecd19e/32.png) [@JoJo](https://gpusph.discourse.group/u/JoJo)\ **Post date:** [November 7, 2021, 7:56am UTC](https://gpusph.discourse.group/t/question-about-the-new-dummy-boundary/161/9 "2021-11-07T07:56:37Z")
I agree. It’s really hard to meet all the needs. 🤣