|
|
A remesh in a scenario will move mesh element IDs all over the place rendering a new channel useless for design purposes.
The maximum wsel equations makes the mesh look like a kalediscope.
Uber uses Hexagons to subdivide the world, and I am suggesting that ICM leverage something similiar to divy out 2D mesh IDs. This way if I modify the mesh in one hexagon - the remaining hexagons do not get renumbered.
Otherwise, I need to build a mesh level zone into the base mesh everytime a design iteration occurs, and painfully edit the zone in the scenarios to make everthing looks only halfway decent.
Thank you for your suggestion regarding the stability of 2D mesh element IDs across iterations, such a great idea. I understand the challenges of remeshing, particularly when comparing results between scenarios and ensuring that modifications remain localised without unnecessary renumbering of elements.
Currently, InfoWorks ICM follows a structured approach to meshing to ensure computational efficiency and to maintain the integrity of the simulation process. However, I acknowledge that this structure means that even small changes to the mesh can result in a broad renumbering of element IDs, making direct comparisons between iterations more difficult. To address this, we have provided the Export to Raster tool as a practical solution. This enables users to compare results across scenarios without relying on element IDs, facilitating a smoother workflow for analysing design changes. While not a perfect substitute for persistent element IDs, it offers a robust way to visualize differences while maintaining computational efficiency.
We are continuously exploring ways to enhance usability without disrupting core functionality and the foundational architecture. For now, our focus remains on supporting the existing meshing approach with additional tools that make life easier for users, such as enhanced comparison capabilities. We greatly appreciate your insights, and your feedback will help inform our long-term roadmap as we evaluate future improvements to ICM’s meshing workflow.
If you have any specific use cases where the current workflow is particularly challenging, we would be happy to discuss them further to see if additional enhancements could be made within the existing framework. I will move this idea to Gathering Support so it can be considered in the future.
https://youtu.be/ay2uwtRO3QE?si=-xjMGOVR6S3fokCN&t=895
Hi Matt, this is an interesting suggestion. When I checked their presentation, I came across the problem of subdivision. This would be relevant for terrain sensitive meshing, since hexagons don't allow perfect subdivision (like squares, or our current unstructured mesh). For Uber this is acceptable, but for computational meshing they could introduce modelling inaccuracies? Perhaps these would be minimal, and worth investigating. If you have ideas let me know 👍🏽