boundcorrection of v4.3

A question about the new function of boundcorrection of v4.3:
Is the gap between the fluid and the particles was corrected in the boundcorrection of 4.3?

Comments

  • I have tried to run the example of boundcorrection. I found that the gap has been removed between the fluid and boundary. but the boundary must be fixed . If I use the floating . the gap between the fluid and floating is still existed.
  • Dear user

    The boundcorrection is still under development.
    And beta version 4.3 only includes that correction for fixed and moving boundaries with simple geometries, but no for floating rigid objects.
    We will extend and improve this correction for v4.4

    Regards



  • @Alex thanks for your reply and sorry for my email with the same question.
  • no problem
    thanks to you
  • @Alex
    I have a question about the floating . In the xml I use drawmode=full to generate sphere So the sphere is full of granules. And I use drawmode=full to generate a poly (stl) but the poly is empty and only the boundary are granules. So will it have some effection to accurancy calculation?
  • HI, with .stl files gencase only generate particules on surfaces (the drawmode does not matter). Generaly, it will impact your simulation.
    In order to fill your geometry with particule you should use fillbox (see XML_v4.0_GUIDE.pdf page 44)
    Basically, you specify a seed, a reference point and a size of box. Then the program wil instantiate particule from the seed inside the box while the modfill is true (in your case I'd put void)
    bye
  • edited November 2018
    @TPouzol
    You mean if I use stl to generate floating, the floating must be filled with particles or the result may be wrong?
    the interaction between fluid and floating is different from boundary?

    Is it relate to the relativeweight.do you think so?
    Regards
  • @Alex @TPouzol
    These days I read the JSphBoundCorr.h and JSphBoundCorr.cpp. But I am confused with these variables:
    //-Configuration parameters.
    TpDirection AutoDir; ///<Direction configuration for automatic definition.
    double AutoDpFactor; ///<Point is calculated starting from bound particles at distance dp*AutoDpFactor.
    tdouble3 LimitPos; ///<Limit between boundary and fluid.
    tdouble3 Direction; ///<Direction to fluid particles.
    tfloat4 Plane; ///<Plane in limit.

    Although there are explanition after the definitons.
    Is AutoDpFactor to remove the gap between fluid and boudnary?
    What is the role of limit between boundary and fluid?

    Is there any papers about the metheod of boundary correctiong recommended ?

    All regards.
  • This is still under development.
    We are now improving and testing the algorithms and then we will produce some journal papers.
    We will let you know when we have more improvements.

    Regards
  • @Alex
    The boundarycorrection can just be used on CPU calculation, and could not be used on GPU now, right?
  • Hi @Alex @TPouzol
    About the boundary correction I see 8 directions in the JSphBoundCorr.h,top/bottom/front/back/left/right/none/defined. So I want to know if the correction can be applied to the complex boundary, like a stl boundary(fixed boundary)?
  • Recenctly I am trying to make boundary correction between floating boundary and fluid to move the gap, so that I can get more accuracy result under low resolution. And the gap between fixed boundary and fluid has been moved successfully in version 4.3. I reference the code JSphBoundCorr.h and JSphBoundCorr.cpp but it is difficult to achieve. So I want to get your idea if it is significant to do this work, and is there any other approaches to improve the accuracy? Because the cost of small dp is so high that we can not accept to simulate some simple cases.
  • I think @Alex answered your question in his first post in this subject.

    "Dear user

    The boundcorrection is still under development.
    And beta version 4.3 only includes that correction for fixed and moving boundaries with simple geometries, but no for floating rigid objects.
    We will extend and improve this correction for v4.4

    Regards"

    Regards
  • @dong what sound of speed are you using in your calculation? Often setting too high a sound of speed will increase simulation times a lot.

    Your sound of speed should be 10 times higher than the highest velocity in your simulation. Ie. if the highest velocity in your simulation is 1, set it to 12 (just to be safe) - don't use the physical correct value of your fluid since the only purpose of sound of speed is to ensure incompressibility according to Tait's equation.

    I hope it helped a bit.

    Kind regards
  • In fact when you define the sound speed you have to consider both situations; one the one hand to ensure enough incompressibility according to Tait's equation but also use the value of maximum speed in your system.

    You should also pay attention to the use of:

  • @Alex I agree with enough incompressibility, but not understanding what you mean with "use the value of maximum speed in your system"? I've always just used this relationship.



    Also seems like some of your comment is missing, I can't see anything after "You should also pay attention to the use of:"?

    Kind regards
  • You should also pay attention to the use of:
    parameter key="DtAllParticles" value="0" comment="Velocity of particles used to calculate DT. 1:All, 0:Only fluid/floating (default=0)"
  • Oh yes. To be honest I have always used the default of 0, but I assume that everything which has an object with a prescribed motion it would be smartest to use 1. Thanks for clarifying!
  • @Asalish3d
    Thanks for your reply, and I am trying some testcase considering your idea.
  • @dong, great hope it improves simulations times a fair bit! Please let us know / describe your case in detail if it does not
  • Hi
    Today I run a example of floating in /examples/main/12_Floatingwaves/CaseFloatingWaves_Def.xml
    There is a floating box with density 680kg/m3 . I change the initial positon of the box
    case 1: the initial position is above water and got the result as follows

    case2: the initial position is below freesurface and in the water and got the result as follows


    In case1 the gap between fluid and floating is obvious but in case 2 the gap is not obvious.
    So why is the result different?
  • Hi @dong

    It's because particles are created in a cartesien grid
    so if you create your floating in water there is going to be particles directly next to it.
    However, this is not a solution. if your floating goes out of water then the gap will properly form.
    You can observe this by putting a moving part under your floating and liftthe floating out of water and then in again

    The same effect can be seen in boundaries also. if you look at example dam break you'll see water having no gap in the inital area and then having the gap in other locations
  • @Alex
    @TPouzol
    @Asalih3d

    About the correction of boundary . I see the clarification of Dynamic Boundary Conditions in Guide.pdf.

    That means when the floating interacts with the fluid and the distance between fluid particles and boundary particles are less than 2 times smoothing length, the density of the boundary particles increases , resulting in an increase in pressure, thereby creating an interaction between the fluid and the floatings.
    In version 4.3, what is the modification of the boundary of the fixed boundary, what is the basis for the correction, and how is the interaction between the fluid particles and the boundary particles? What is the difference with Dynamic Boundary Conditions?
  • @Alex
    Could you make some explaination? Thanks a lot
    regards
  • We will give more information about the correction for DBC once we finished that
    Only v4.3 include some preliminary stuff, but that was a BETA version for delegates of the 4th DualSPHysics User Workshop. However since it is only BETA and this work is now under development we can not release that and there is no proper documentation... So there is no sense to explain now what we are working on....
    I am sorry

    Regards
Sign In or Register to comment.