Problem with MDBC
First of all, I strongly thank you for the release of the 5th version.
I have read the pdf guides about the MBDC. Then I read the examples.
For the extreme of "mdbc\06_WaveTank" I have faced some questions. I would be thankful if you help me:
1- For the "beach", the method of "automatic" is used for generating normals. But for piston, the method of "Explicit" is used. Why?
2-The parameter " maxdisth" is equal to "0.0" for the piston. It's default value is "2.0". What is the reason?
3- Can we use the "automatic" method for generating normals for both "beach" and "piston"?
4- I have used the "automatic" method for generating normals for both "beach" and "piston".
The file is attached.
I get the following warnings in the "Preprocessing" stage. What are them?
1. Free-particles feature is not finished so it can present some problems in combination with other XML operations.
2. Free-particles are also included in Vtk-Cells file but it present some issues since this file format was not thought for Free-particles.
I get the following warning in the "Processing" stage. What is it?
1. There are 3 of 1791 fixed or moving boundary particles without normal data.
5- The gap between piston and water is observed, although the mdbc is used. See the attached picture.
6- If we add a floating body in the flume, can we use the "automatic" method for generating its normals?
Comments
Response between lines:
1- For the "beach", the method of "automatic" is used for generating normals. But for piston, the method of "Explicit" is used. Why?
This is just an example of how to use both methods.
However in the case of the piston it is much easier to use the explicit method with "boundnormal_plane" than defining a box dp/2 bigger at the right, dp/ bigger at the left and dp/2 bigger at the top!!!
However note that the XML file in examples\mdbc\06_WaveTank\CaseWaveTank_Def.xml is using dp=0.03 m.
This value of dp was not a good option in fact, since positions at 0.03 m can be different for the piston than for the bottom when using "freedrawmode" in the bottom!!!!
In fact, you can observe how initially the particles of the piston are not located at the same x.position as the ones in the bottom
Perhaps working with dp=0.02m is better to understand these issues
2-The parameter " maxdisth" is equal to "0.0" for the piston. It's default value is "2.0". What is the reason?
Yes, the default value is 2, which means to use a maximum distance of 2h to compute normals from the boundary limit
This is the distance to the boundary limit and it is used to define if the normal vector will be computed for one boundary particle or not.
Here, we are using this with the piston....
if the piston has a width of 3h, then with v=2 normals will be associated only to particles at distance 2h to the boundary limit
and with v=0 there is NO maximum distance and normal vectors are computed for all boundary particles of the piston.
In this case, the piston has a width (in X) higher than 2h, so using v=0 is useful to compute normals for all boundary particles.
This is not properly explained in the documentation, so sorry.
3- Can we use the "automatic" method for generating normals for both "beach" and "piston"?
Yes of course, however only some options can be used for the automatic method such as:
- boundnormal_plane
- boundnormal_cylinder
- boundnormal_sphere
Therefore if you have more complex geos, using the geometry at dp/2 and saving geometry with Case_hdp_Actual.vtk is easier
4- I have used the "automatic" method for generating normals for both "beach" and "piston".
As mentioned before some problems can be due to the use of dp=0.03m, please try first with dp=0.02m and you have to be sure that your geo at dp/2 during the "automatic" method is exactly at dp/2 of the boundary particles...
You can plot Case_Bound.vtk and Case_hpd_Actual.vtk (wireframe) in Paraview to check it
I get the following warnings in the "Preprocessing" stage. What are them?
1. Free-particles feature is not finished so it can present some problems in combination with other XML operations.
2. Free-particles are also included in Vtk-Cells file but it present some issues since this file format was not thought for Free-particles.
This means that some corners when using slopes can present problems or even the filling options with fluid particles can not be perfect.
However this is only a warning, you can check your initial condition to verify if you are happy with the initial created particles (no holes, etc)
I get the following warning in the "Processing" stage. What is it?
1. There are 3 of 1791 fixed or moving boundary particles without normal data.
This means that 3 boundary particles are too far from fluid (more than 2h by default) so no normal vectors were created for those 3 particles.
You can also plot CfgInit_Normals.vtk (Glyph option) to see the normal vectores initially created.
5- The gap between piston and water is observed, although the mdbc is used. See the attached picture.
As mentioned before, your case is not correct since Case_hpd_Actual.vtk is not created at dp/2 of the boundary particles of the piston
Please try again with dp=0.02m and following all the suggestions here
5- If we add a floating body in the flume, can we use the "automatic" method for generating its normals?
mDBC approach is not implemented yet for floating bodies in v5.0
Best regards