How to fill a tank from a seed
Hello all
I have tried to fill a tank from a seed point unsuccessfully.
'<' symbols are removed because if not the text cannot be viewed in web:
- Using fillpoint: pointmin-pointmax box is filled
setmkfluid mk="0" cmt="Water"/>
fillpoint x="1" y="1" z="1">
modefill>void
/fillpoint>
- Using fillbox: All box is filled outside the container
setmkfluid mk="0" cmt="Water"/>
fillbox x="1" y="1" z="0.5">
modefill>void
point x="0" y="0" z="0"/>
size x="10" y="10" z="1"/>
/fillbox>
Changing "void" with "border | fluid" the results are the same.
Putting this in the beginning or at the end of the results are the same.
Do you know what is the mistake?
I have tried to fill a tank from a seed point unsuccessfully.
'<' symbols are removed because if not the text cannot be viewed in web:
- Using fillpoint: pointmin-pointmax box is filled
setmkfluid mk="0" cmt="Water"/>
fillpoint x="1" y="1" z="1">
modefill>void
/fillpoint>
- Using fillbox: All box is filled outside the container
setmkfluid mk="0" cmt="Water"/>
fillbox x="1" y="1" z="0.5">
modefill>void
point x="0" y="0" z="0"/>
size x="10" y="10" z="1"/>
/fillbox>
Changing "void" with "border | fluid" the results are the same.
Putting this in the beginning or at the end of the results are the same.
Do you know what is the mistake?
Comments
I allways use the command fillbox, like yours.
You have to be certain, that the point in the line "fillbox x=..." is inside your container and that your container is closed (closed or the position and size is not outside the range of your container).
Remember that the origin is often chainched if you convert 3D-files into a STL-file.
Sebastian
In this simulation there is no problem of water leakage in the simulation if water is set like other solids instead of using fillbox or similar.
Anyway I will prepare a simple sample to test this.
Regards
Iñaki
The value of "h" can be obtained by looking in the XML file produced by GenCase.
It is important to consider the problem of rounding error when going from fixed vertex geometries to the final discretised particle distribution.
As you say, if you can produce a more comprehensive example of your problem we can probably help more.
Regarding your recommendation "it is very important to try and maintain a distance of 2h from the boundary particles for fluid particles.", I have a question about the smoothing length "h".
It is defined as h=coefficient*sqrt(dx2+dy2+dz2), so we only have control over the coefficient, which is suggested in the dualsphysics documentation as 0.866025.
1. How can we maintain a 2h distance from boundary particles for fluid particles? At the beginning of the simulation one can generate a geometry with mkvoid, is this what you mean? I wonder if during the simulation the fluid particles will move into this void space between them and the boundary? Does mkvoid generate particles with no properties that maintain this separation between fluid and solid particles?
2. Is dx, dy, dz the overall size of the geometry space used? That would mean that sqrt(dx2+dy2+dz2) is the biggest diagonal of the model space. In which case h is a fairly large number relative to the size of the space occupied by the simulation. Do you have recommendations regarding how to choose the size of h?
3. Would a coefficient value of 1 mean that all particles are used in the calculation of each particle in every step?
If you can help me clear this concepts I would greatly appreciate it.
In my case I am simulating the impact of a sphere into a slim water tank with close boundaries.
Thank you so much.
'h' is the SPH kernel smoothing length, you rightly say how it is calculated, but in this case dx, dy and dz are in fact the initial particle separation (i.e. 'dp'), not the size of the domain, as GenCase currently creates particles in a cubic lattice, dx, dy and dz will all be the same.
The only reason I say it can be important to try and ensure the fluid particles don't start to close to the boundary particles is that, as the boundary produces a repulsive force 'field', any fluid particles that are initially closer than 2h (their own smoothing length and the boundary particle smoothing length) will be immediately repulsed, resulting in a cascade effect on the whole simulation. Of course you could allow things to settle before performing any meaningful simulation with the fluid, but being a bit careful with your initial placement of the fluid particles compared to the boundary particles can help reduce this effect.
The value for the smoothing length coefficient given in the documentation has been chosen as one that provides a good balance between performance (as the underlying neighbour searching algorithm uses the smoothing length to define the grid size) and accuracy. Saying that, I personally find I need to reduce it slightly in cases where I have a highly transient fluid, but reduce it to much and the SPH kernel support will be too low to capture good fluid dynamics. As with most parameters it's a case of having a play with values in a reasonable range and applying engineering judgement! The supplied value is a good starting point however.
Hopefully you can now see that a coefficient of 1 would not result in a value of 'h' equal to the size of the domain.
Could I kindly ask for your help to please explain what effect does "real |dp |bound " have? I am not sure how to choose in which order prioritize real/bound/void/dp.
For explanation sake lets say there is a cube of 1 x 1 x 1 filled with water, a dp of 0.02, and a box in mkvoid with a width of "dp" between he water and the cube on each wall of the box. And lets also say that the code first has the information for boundary, then for the fluid, and last for the mkvoid. Since two particles cannot coexist in the same place, what choices does the programme makes to define the position of each particle? What would change if for example I stated dp only?
Thank you for your time and help, I am very happy to be able to share my questions and doubts in this forum.
Those parameters just affect what is output by GenCase as far as I know.
The only thing that alters the order in which things are "created" is the order in which they appear in the XML file input in to GenCase.
So, for example, if I had an unbounded fill command first in my list and then followed that by the boundary which surrounds it, the fill would end up trying to fill the domain and not be bounded by the boundary, whereas if they were the other way round, the boundary would bound the fill.
So if you defined a set of fluid particles and then a void area (note: not void particles, just an area void of particles) then the fluid particles in that area would be removed, whereas if you did it the other way round then the void would "void" nothing, and then the fluid particles would just occupy the void.
Hope that makes sense!
Problem fixed!.
The best way is using fillbox. The trick is that the seed point has to be inside the modefill box. Considering water in a tank, the upper side of the modefill box is the water level (^_^).
Best regards
Iñaki