Problem with Crixus settings

Applications
1

Hello,

I am trying to use Crixus to generate sets of particles for my simulation. The fluid domain is given by the internal cooling channels of a drill bit. I have one inlet, one outlet and walls. I generated the meshes using Salome and then exported as STL files. The “fluid.stl” includes all the boundaries (walls + inlet + outlet), whereas the “outlet.stl” and “inlet.stl” only the part of the mesh at the outlet and the inlet, respectively. I used the NetGen 1D-2D algorithm with a Local Length of 9e-05.
Then I set up the .ini file for Crixus as follows:

[mesh]
stlfile=fluid.stl
dr=0.00015
swap_normals=false
fshape=fluid.stl
[special_boundary_grids]
mesh1=outlet.stl
mesh2=inlet.stl
[fluid_container]
use=false
xmin=-0.001
ymin=-0.003
zmin=-0.003
xmax=0.012
ymax=0.003
zmax=0.003
[fill_0]
option=geometry
xseed=0.00195
yseed=0.00045
zseed=-0.00157
[output]
format=vtu
split=true

However, the particle generation works only if I set dr=1.5e-04. If I choose a different value, it doesn’t work properly. A bounding box of my simulation domain is fully populated with fluid particles, instead of only the domain delimited by the fluid.stl file. I understand that the particle spacing cannot be arbitrary because it has to be compatible with the mesh size used in Salome. However, I cannot figure out what the relation between the two quantities should be. I kept fixed the ratio between the two to 1.666 (=1.5e-04/9e-05), changed the mesh spacing to 6e-05. set up a new .ini file with dr=1e-04 (=1.666*6e-05) and finally executed Crixus again. But this time it didn’t work out even with the ratio which was successful before.
Could you please tell me how these two quantities relate to each other and accordingly how I should set the particle spacing with a given value of the mesh resolution?

Thank you very much for the help.

Regards

Manuel

2

Below an example of the Crixus output:

**************************************
*                                    *
*             C R I X U S            *
*                                    *
**************************************
* Version     : 0.5                  *
* Date        : 27.03.2014           *
* Author      : Arno Mayrhofer       *
* Contributors: Christophe Kassiotis *
*               F-X Morel            *
*               Martin Ferrand       *
*               Agnes Leroy          *
*               Antoine Joly         *
*               Giuseppe Bilotta     *
*               Eugenio Rustico      *
**************************************

Selecting GPU … Id: 0 (1024, 2147483647) … [OK]

INFORMATION:
threadsPerBlock is not equal to maximum number of available threads.

Opening file fluid.stl … [OK]
Mesh size: 0.00012
Checking whether stl file is not ASCII … [OK]
Reading 170760 facets … [OK]

Information:
Origin of domain:           	(-0.000833237, -0.002499, -0.002499)
Size of domain:             	(0.0118332, 0.004998, 0.004998)
Number of vertices:         	86289
Number of boundary elements:	170760

Calculating surface and position of boundary elements … [OK]
Sorting boundary elements and computing indices … [OK]

Normals information:
Positive (n.(0,0,1)) minimum z: -0.00193812 (0.00101518)
Negative (n.(0,0,1)) minimum z: -0.00249524 (-0.998539)

Calculating volume of vertex particles … [OK]

Checking whether special boundary grid #1 (outlet.stl) is available … [YES]
Checking whether special boundary stl file #1 is binary … [YES]
Reading 6114 facets of special boundary geometry #1 … [OK]

Checking whether special boundary grid #2 (inlet.stl) is available … [YES]
Checking whether special boundary stl file #2 is binary … [YES]
Reading 566 facets of special boundary geometry #2 … [OK]

Checking whether special boundary grid #3 (DrillOnePhaseStill_sbgrid_3.stl) is available … [NO]

Defining fluid particles …
Checking whether fluid geometry (fluid.stl) is available … [YES]
Checking whether fluid geometry stl file is binary … [YES]
Using whole geometry as fluid container.

Option for fill #0: geometry
Seed point (0.00195, 0.00045, -0.00157)
Distance from fluid particles to vertices and segments: 0.00012
Reading 170760 facets of fluid geometry … [OK]
Merging arrays and preparing device for filling … [OK]

Creation of 174634 fluid particles completed. [OK]
Creating and initializing of output buffer of particles … [OK]
Output format: vtu
Sorting particles according to special boundary id… [OK]
Counted:

  • Fluid particles: 174634
  • Boundary particles, kent 0: 421484
  • Boundary particles, kent 1: 9311
  • Boundary particles, kent 2: 888
    Writing output to file DrillOnePhaseStill.fluid.vtu … [OK]
    Writing output to file DrillOnePhaseStill.boundary.kent0.vtu … [OK]
    Writing output to file DrillOnePhaseStill.boundary.kent1.vtu … [OK]
    Writing output to file DrillOnePhaseStill.boundary.kent2.vtu … [OK]

Thank you.

Regards

Manuel

3

Hello,

I found the problem. It has nothing to do with Crixus settings. The surface mesh created by Salome was not waterproof. This was not evident by visual inspection and Salome did not throw any warnings. However, by using an OpenFOAM utility (surfaceCheck) I could detect that there were holes in the stl. Reparing the stl file solved the issue and now Crixus can correctly perform the particle preprocessing.
Sorry for having bothered you with such a problem, but the fact that in the beginning I was able to run Crixus with only a specific resolution deceived me.

Regards

Manuel

4

Hello @Manuel,

sorry for the lack of replies, and thanks for reporting back about the actual source of the issue and its resolution. Do keep in mind that the semi-analytical boundary conditions and its support are currently in an unfavorable position, as their introduction was mainly supported by EDF, and they currently don’t have anyone involved into GPUSPH to support it, and the other GPUSPH developers aren’t deeply familiar with that part of the codebase or its auxiliary tools.

5

Hello @giuseppe.bilotta,

thank you very much for the info.

Regards

Manuel