Cold-start definition of CompleteSaExample for customization and study

I am carrying out some convergence studies for the validation cases of GSPH 5.0 in grey-box mode. Here grey means manipulating parameters at the level of the command line option rather than of the problem’s source code.

The outcomes of the Dambreak3D example are expected. Project Chrono is disabled and the runs begin with a cold start. If I reduce the particle spacing from 0.0150 to 0.040 units, the number of fluid particles shown in the simulation report increases from ~22k to ~1.5M; the output files contain the fields for the same number of time steps (301); the size of each output files grows from ~5MB to ~160MB. All which could be anticipated.

The outcomes of CompleteSaExample example are unexpected, or rather, an expected fail. Project Chrono is enabled and the initial data are read in from given input files. If I reduce the particle spacing from 0.0150 to 0.040 units, the number of particles in the simulation report is the same; the output files contain information for different numbers of time steps (405 and 50); the size of the output files is the same in the two cases but grows from 17 to 33M in the course of the run. Although I have not spotted a warning catching this, I attribute this behaviour of CompleteSaExample to the fact that the problem sizes defined in the input files and in the command line do not match. Hence, accidents follow.

Would it possible to distribute/forward the version of CompleteSaExample.cu referring to the cold start? This would help me run these simulations with increasing particle numbers as done with Dambreak3D. This is particularly valuable since, if I am not wrong, completeSaExample is the very template for applications with floatings and the Chrono library, so users may want to start from this to customize their problems.

Directions and corrections welcome.

The issue with CompleteSaExample and all problems using the unified semi-analytical wall-boundary model in general is that the meshing of the boundary and the fluid filling is not done within GPUSPH, but with external tools such as SALOME and Crixus. This prevents run-time selection of the ∆p from the command-line, although I agree that the problem should fail more gracefully with a clear indication of the fact that dynamic particle spacing is not supported.

The problem definitions in GPUSPH were provided by EDF, that has so far been the main sponsor for the development and implementation of the SA boundary model. I’ll forward your request.

Hello @sph_tudelft_nl

can you verify if the .zip file provided in this comment to issue #46 on GitHub provides you with the necessary files to recreate CompleteSaExample at different resolutions?