# Problem with Crixus settings **URL:** \ **Category:** Applications\ **Created:** [November 19, 2020, 5:24pm UTC](https://gpusph.discourse.group/t/problem-with-crixus-settings/126 "2020-11-19T17:24:18Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Manuel](https://avatars.discourse-cdn.com/v4/letter/m/67e7ee/32.png) [@Manuel](https://gpusph.discourse.group/u/Manuel)\ **Post date:** [November 19, 2020, 5:24pm UTC](https://gpusph.discourse.group/t/problem-with-crixus-settings/126/1 "2020-11-19T17:24:18Z")
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 ---
**Author:** ![Manuel](https://avatars.discourse-cdn.com/v4/letter/m/67e7ee/32.png) [@Manuel](https://gpusph.discourse.group/u/Manuel)\ **Post date:** [November 19, 2020, 5:44pm UTC](https://gpusph.discourse.group/t/problem-with-crixus-settings/126/2 "2020-11-19T17:44:20Z")
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 ---
**Author:** ![Manuel](https://avatars.discourse-cdn.com/v4/letter/m/67e7ee/32.png) [@Manuel](https://gpusph.discourse.group/u/Manuel)\ **Post date:** [November 23, 2020, 4:21pm UTC](https://gpusph.discourse.group/t/problem-with-crixus-settings/126/3 "2020-11-23T16:21:03Z")
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 ---
**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 25, 2020, 5:03pm UTC](https://gpusph.discourse.group/t/problem-with-crixus-settings/126/4 "2020-11-25T17:03:52Z")
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. ---
**Author:** ![Manuel](https://avatars.discourse-cdn.com/v4/letter/m/67e7ee/32.png) [@Manuel](https://gpusph.discourse.group/u/Manuel)\ **Post date:** [November 26, 2020, 10:09am UTC](https://gpusph.discourse.group/t/problem-with-crixus-settings/126/5 "2020-11-26T10:09:28Z")
Hello @giuseppe.bilotta, thank you very much for the info. Regards Manuel