Solver Structure Overhaul

[ZephirFXEC]

Current Setup

• We start from sourcing volumes generated in Houdini, which are given to HNano nodes as <Coord*, Value*> pairs.
• The <Coord*> array is used to build a sparse Topology Grid on the GPU.
• Once the topology is built, the <Value*> array is loaded into it to form a usable grid structure.
• This process is repeated for multiple quantities such as Density, Temperature, and Fuel before performing the Advection step.
• The generation of the Topology Grid is expensive, and doing it multiple times (once per quantity) is time-consuming.

Improvement 1: Reusing the Velocity Topology

Concept:
Instead of building a new topology for each quantity (Density, Temperature, Fuel), reuse the topology that is already built for the Velocity field. Since all these quantities exist within the region defined by the Velocity field’s topology, We can directly fill this existing topology with new values instead of recreating it.

Pros:

• Reduced Overhead:
  Eliminates the costly creation of multiple topologies for each quantity. We generate the topology once (for Velocity) and reuse it.

Cons:

• Higher Memory Usage:
  The Velocity field topology might be more expansive (covering a larger area) than the other quantities. Filling this large topology with data for smaller fields wastes memory, as many entries will be zero (or simply unused).

When Useful:

• If the Velocity topology size is not overwhelmingly larger than that of the other fields, this approach can still be a net gain, trading some memory overhead for fewer topology-building steps.
• If we have ample GPU memory and the cost of building topologies is significantly high, this might be beneficial.

Improvement 2: Using the Vector Field Topology as an Index Grid

Concept:
Instead of directly placing values into the reused topology, the Velocity field’s topology could store references (offsets) into a separate Value* array. Essentially, the topology becomes an indirect indexing structure. The <Coord*, Value*> pairs for each quantity are mapped onto the Velocity topology, and indices (or offsets) are stored instead of actual data values.

Pros:

• Memory Efficiency at the Topology Level:
  The topology itself holds only indices (small integers) rather than full floating-point values, potentially reducing the memory footprint of the topology structure.

Cons:

• Sparse Value Arrays:
  The value arrays still need to align with the topology, meaning we may end up with large arrays filled mostly with zeros to match the coordinate space of the Velocity topology.
• Data Access Complexity:
  Every lookup now involves an extra level of indirection (topology -> offset -> value), adding complexity and potentially extra overhead at runtime.