---
# System prepended metadata

title: WMTK 2024 Post-SIGGRAPH TODO

---


# Current (May 2024)

## Major tasks
1. Remove hash
    * Distinguish "have seen" semantic vs asserts
    * replace "have seen" with some auxilliary datastructure
2. Optimize *Operation object constructors
    * identify which meshes 
3. Nonmanifold support
    * Check that edge in tetmesh works (seems to fail in nonmanfiold trimesh in tetmesh on wild meshing)
    * distinguish is_manifold vs is_boundary vs is_navigatable
        * (is_manifold || is_boundary = is_navigatable)
        * implemented by facet-facet matrix keeping -1 for boundary, -2 for nonmanifold
        * certify that setting VF / EF to -1 for nonmanifold simplices is useful
            * might be best to set this to be -1 and add an auxilliary list of dynamically sized values?

## Secondary Tasks
1. Unify EdgeOperationData between dimensions
    * reduce one level of variant storage data for different operation dimensions
2. Performance tuning
    * use wildmeshing / daniel's application / some 2d as integrat tests for checking performance
3. Tet swap before checks should use orient_vertices instead of ccw (but it's painful right now)
4. 2d edge insertion

# Old (January 2024)
## Toolkit Performance Cleanup
1. Operation failure performance degradation @4RoToHCcTEuOOFq6LfZS0w
    * test on the 3d sphere example?
2. Create scope after `before()` @danzin 
3. Reducing heap allocations in simplex operations @danzin 
    * union-type operations like open/closed star take unions of faces_single_dimension, which returns multiple small vectors
4. Simplifying cache dereferencing / refactor Accessor classes
    * switch to composition for accessors?
5. Re-evaluate use of inlining / accessor construction
    * double check inlining hot paths
6. Refactor split/collapse to remove indices @Jiacheng
    * Navigation currently works on 0 0 1 triangles, but we should make sure this works
7. Rationals / rational+ieee754 simplex insertion @teseoch /@4RoToHCcTEuOOFq6LfZS0w
8. Re-evaluate parallelism
    * Might have to remove cached accessors / move them per-thread
    * Add a "parallelism manager"
8. Clear component @danzin 
9. documentations and website @teseoch @4RoToHCcTEuOOFq6LfZS0w @danzin 

`./wmtk_app -j ../data/unit_test/wildmeshing_2d.json`
`./wmtk_app -j ../data/unit_test/wildmeshing_3d.json`
`./wmtk_app -j ../data/unit_test/marching.json` @danzin  

## General Items
### Toolkit Cleanup
* make components uniform
* revisit attribute transfer, it should be the same for int and double
* bitset and is interior inconsistency
* are hashes necessary?
* Revisit what the Cache is (does it store temporary files? does it represent the toolkit state?)
* Flag Accessors
* Rename "*Manager" objects?
    * mtao: I still like this name, but others don't. the "AttributeManager" manages the attributes of hte Mesh, teh "MultiMeshManager" manages the multimesh data for the mesh
    * At the very least, move MultiMeshManager to the multimesh folder/namespace
* Refactor for use of CellType rather than PrimitiveType (so we don't need to deal with halfedges everywhere)

### Extensions
* (DZ) Polygons - given the progress we had with Ryan on seamless parametrization this became urgent; several things I have in mind depend on this: quadrangulation, subdiv/spline patch conversion, compression etc.  
* (DZ) Polyhedra, to replace what's now in Polyfem.  Less urgent
* (DZ) Progressive-mesh style mapping, i.e. mesh->mesh bijective maps incrementally defined  by sequences of split/swap operations.  Critical for all parametrization work that changes mesh connectivity, or for doing anything scalable in this space.  E.g., cannot implement already published papers on conformal maps and Penner coordinates. 

### Components
* Tetwild
* Cut-cells
* Triwild
* (DZ) Curved Triwild - I have a slow-going project depending on this, and while it is ok mostly with th old code, there were multiple instances when it was in the danger of stalling without a fix to a code no one want to deal with anymore.
### JSON Interface
* Planning out a python interface (actually using the json as an interchange format)
* Scoping / reusing blocks of json
* More pervasive to/from json for configuration generation?
    * Will let us transfer C++ or python implementations of components between one another
    * Interface for attribute transfer
        * scoping is really necessary for this to reduce redundancy
* Multimesh naming / loading (Allow for dot notation to request a multimesh from the cache)
    * Mostly implemented, just being debugged