I am creating Navier-Stokes simulation of flow around particle aggregates imitating marine snow. I need the simulations to be programmatically produced to look at stochastic effects. When creating the grid, I get the error:
"Error using matlab.internal.math.interp1
Sample points must be unique and sorted in ascending order.
Error in featool"
Interestingly, the code sometimes works but other times not - I assume it has something to do with the stochastic production of sub-particles.
Below is the code that I use to generate the geometry, and how I wish to create the mesh. I am not sure if the error can be solved by "sorting" some aspect of the fea.geom.object properties or if the error is located in the gridgen function. Any help would be appreciated.
% Geometry and grid parameters.
h = 0.02; % Height of rectangular domain, m.
l = 0.02; % Length of rectangular domain, m.
xc = h/2; % x-coordinate of particle center.
yc = l/2; % y-coordinate of particle center.
diam = 0.003; % Particle, m.
Thank you for the issue report. As the geometry is randomly generated I have not been able to produce a configuration that gives this error. Could you run your script again, and save (and attach) the resulting data and workspace produced after the error with a command such as:
but any lower 'hmax' value seems to take forever. Please share the exact gridgen function call signature for the attached mat file if you still observe this issue. You can also try using the 'triangle' and 'gmsh' grid/mesh generators to see if any of them work better in these cases.
The geometry generation now works great, however there seems to be an issue with the I/O interface to the Fortran Gridgen2D framework. I get the error:
startio: illegal unit number
apparent state: unit -413691250
Seems like there are negative numbers in the data being sent to Gridgen?
Thank you for including the grid generation command, I still don't get any crash but the grid generator never seems too finish. It could potentially be a system/os dependent error in this case (if memory runs out or so).
What I do notice that the initial boundary mesh distribution already contains a million or so grid points which will lead to an extremely dense mesh. Are you sure you have the geometry dimensions in consistent units? As the geometry in the FEATool_FortranIOBug.mat file is of dimension ~5, and with a target boundary mesh size is 20-100e-6 would eventually lead to a mesh with the order of (5/50e-6)^2 = 1e10 grid cells which would be hard to fit in to memory (and take very long to solve).
If you really do need this mesh size and the other mesh generators (triangle or gmesh) doesn't work another work around might be to first create a coarser grid (but refined in regions of interest), and then use the "gridrefine" command to make a finer grid. For example