An easy to use immersed boundary method in 2D, with full implementations in MATLAB and Python that contains over 75 built-in examples, including multiple options for fiber-structure models and advection-diffusion, Boussinesq approximations, and/or artificial forcing.
I'm only going to speak to this from the VTK output perspective, not the internal plotting.
Let's suppose you run a simulation with grid parameters as follows (see Flow_Around_Cylinder):
Nx = 512
Ny = 128
Lx = 1.0
Ly = 0.25
For simplicity, let's consider only the x-direction. The important thing here is that the fluid domain is of unit length (periodic) in the x-direction, from 0 to 1.0. However, when the VTK files are written, if you look at the mesh points in the x-dimension, you'll find something surprising: they begin at x=0.0 but end at 0.9980341. That last number is not roundoff error. Here's what I think happened:
IB2d solved for the fluid velocity at the center of each grid cell.
The lower-left data point was placed at the Euclidean origin, because that is the lower left corner of all IB2d simulations
However, because the lower left data point is actually the center of the lower left cell and not it's lower left corner, this actually was a spatial translation of the original domain. The result is that all data points are now misplaced spatially by dx/2 and dy/2.
The end x-mesh value of 0.9980341 is (within roundoff error) given by 1.0 - 1/512 (dx=1/512). That's because the right-most center cell is (originally) located at 1.0-dx/2, and the shift placed it a further dx/2 to the left.
This is a problem because it means that the fluid data is incorrectly placed in the spatial domain with respect to the original parameters of the simulation. The error is slight and amounts to a straight translation (the domain is now [-0.00098, 0.9990]x[-0.00098,0.246] in this example, instead of [0,1]x[0,0.25]), but in some applications it could matter, particularly where the results are being used for something other than just visualization of the fluid flow.
My suggestion for solving this is two part:
The VTK writer should be updated to print out the correct spatial mesh information.
Verify that the correct mesh coordinates are used for internal plotting and fix as necessary. As long as we explicitly specify the spatial limits of the plots, everything should still display with (0,0) in the lower left corner, even if the lower left mesh point is placed at (dx,dy). For quiver plots, everything is straightforward. For pcolormesh etc., some extrapolation to the edge of the domain may be needed, though this is technically interpolation if the periodic boundary condition can be used. It may not be worth fooling with.
Until this is addressed, Planktos will expect this inconsistency and auto-correct it. So please notify me in LOUD terms if this issue is closed!!
I'm only going to speak to this from the VTK output perspective, not the internal plotting.
Let's suppose you run a simulation with grid parameters as follows (see Flow_Around_Cylinder): Nx = 512 Ny = 128 Lx = 1.0 Ly = 0.25
For simplicity, let's consider only the x-direction. The important thing here is that the fluid domain is of unit length (periodic) in the x-direction, from 0 to 1.0. However, when the VTK files are written, if you look at the mesh points in the x-dimension, you'll find something surprising: they begin at x=0.0 but end at 0.9980341. That last number is not roundoff error. Here's what I think happened:
This is a problem because it means that the fluid data is incorrectly placed in the spatial domain with respect to the original parameters of the simulation. The error is slight and amounts to a straight translation (the domain is now [-0.00098, 0.9990]x[-0.00098,0.246] in this example, instead of [0,1]x[0,0.25]), but in some applications it could matter, particularly where the results are being used for something other than just visualization of the fluid flow.
My suggestion for solving this is two part:
Until this is addressed, Planktos will expect this inconsistency and auto-correct it. So please notify me in LOUD terms if this issue is closed!!