The parameters for the boundary conditions are mapped from the cell entities (agents) to the correct boundary piece through a value in solver.boundary_markers (which is saved alongside the mesh, of course).
Getting the boundary piece index for the cells is currently just an enumeration of the cell list and because the grid placement was deterministic, the mapping between cell id and boundary piece index was repeatable.
As a result the x,y,z values in cell.p would always match the physical location in the mesh.
When the assignment of cell types is independent of x,y,z we don't notice the difference, but for clustering that probably won't work so well.
Our options I think, are:
fix the seed in the random placement (least effort, but we could not generate replicates over random (physical) placement, though still over cell type assignments)
store the cell positions with the mesh and load it together (cleanest solution, but greatest implementation effort)
If we do number one, we really wouldn't need to rerun the placement all the time, but if we cache the information, we might as well do No. 2.
The parameters for the boundary conditions are mapped from the cell entities (agents) to the correct boundary piece through a value in
solver.boundary_markers(which is saved alongside the mesh, of course). Getting the boundary piece index for the cells is currently just an enumeration of the cell list and because the grid placement was deterministic, the mapping between cell id and boundary piece index was repeatable. As a result the x,y,z values incell.pwould always match the physical location in the mesh. When the assignment of cell types is independent of x,y,z we don't notice the difference, but for clustering that probably won't work so well.Our options I think, are:
If we do number one, we really wouldn't need to rerun the placement all the time, but if we cache the information, we might as well do No. 2.
Originally posted by @lukaskiwitz in https://github.com/lukaskiwitz/thesis/issues/9#issuecomment-996685504