colin/fdtd-coremem
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

README: clarify how to implement _compound_ materials

Browse Source
This commit is contained in:
Colin
2025-01-15 01:47:14 +00:00
parent 641dd9a5a1
commit f8ae96ef13
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@@ -227,6 +227,16 @@ to add a new material:
- for `WgpuBackend` simulations: do the above and add a spirv entry-point specialized to your material. scroll to the bottom of - for `WgpuBackend` simulations: do the above and add a spirv entry-point specialized to your material. scroll to the bottom of
[crates/spirv_backend/src/lib.rs](crates/spirv_backend/src/lib.rs) and follow the examples. [crates/spirv_backend/src/lib.rs](crates/spirv_backend/src/lib.rs) and follow the examples.
to use your new material alongside other materials like `IsomorphicConductor`, leverage the compound type wrappers
in [`compound.rs`](./crates/cross/src/mat/compound.rs):
`let my_sim = SpirvSim::<f32, DiscrMat2<IsomorphicConductor<f32>, MyMat>>::new(...)`
if the compound wrappers seem complicated, it's because they have to be in order to be compatible with SPIR-V, which
does not generally allow addresses to refer to more than one type.
hence something like `enum { A(IsomorphicConductor<f32>), B(MyMat) }`
has to instead be represented in memory like `(u8 /*discriminant*/, IsomorphicConductor<f32>, MyMat)`.
in practice, we do some extra tricks to fold the discriminant into the other fields and reduce memory usage.
as can be seen, the Material trait is fairly restrictive. its methods are immutable, and it doesn't even have access to the entire cell state (only the cell's M value, during `move_b_vec`). i'd be receptive to a PR or request that exposes more cell state or mutability: this is just an artifact of me tailoring this specifically to the class of materials i intended to use it for. as can be seen, the Material trait is fairly restrictive. its methods are immutable, and it doesn't even have access to the entire cell state (only the cell's M value, during `move_b_vec`). i'd be receptive to a PR or request that exposes more cell state or mutability: this is just an artifact of me tailoring this specifically to the class of materials i intended to use it for.
## What's in the Box ## What's in the Box