so-rose
/
oscillode
1
0
Fork 0
Code Issues 50 Pull Requests Packages Projects Releases Wiki Activity
oscillode/TODO.md

57 lines
1.2 KiB
Markdown
Raw Normal View History

plan: Revamped TODO w/final planning
2024-04-27 19:49:46 +02:00
# Working TODO
fix: Inching closer. I'm of the belief that the correct abstractions are now actually available, and that most-to-all of the required functionality actually already exists within the code base. The art is bringing it together!
2024-05-01 13:54:16 +02:00
- [x] Wave Constant
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- Sources
feat: Feature-parity with past. We've added enough nodes to run simulations, and there is now only an "air gap" remaining between the math nodes and the sim design nodes. Of particular importance right now are: - Finalizing the exporter w/Sim Data output. - Finishing the plane wave, as well as other key source nodes (TFSF, Gaussian Beam, Plane Wave stand out in particular). - Reduce node, as we need to be able to reconstruct total flux through a field monitor, as well as generally do statistics. - Transform node, particularly w/pure-InfoFlow reindexing (we need to be able to reindex frequency -> vacwl), fourier transform (we need to be able to cast a time-domain field recording to frequency domain). - Finish debugging the basic structures, in particular the Cylinder primitive, but also the generic GeoNodes node, so we can build the membrane properly. - Ah yes, also, the grid definition. The default can sometimes act a little suspiciously.
2024-05-03 00:19:02 +02:00
- [x] Temporal Shapes / Continuous Wave Temporal Shape
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] Temporal Shapes / Symbolic Temporal Shape
- [x] Plane Wave Source
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- [ ] TFSF Source
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] Gaussian Beam Source
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- [ ] Astig. Gauss Beam
- Monitors
fix: Inching closer. I'm of the belief that the correct abstractions are now actually available, and that most-to-all of the required functionality actually already exists within the code base. The art is bringing it together!
2024-05-01 13:54:16 +02:00
- [x] EH Field
- [x] Power Flux
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] Permittivity
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- [ ] Diffraction
feat: Finished Library Medium node. It now supports selecting the variant, and exporting a generated LazyArrayRange of valid freqs/wls. The UI was also revamped, with greatly more readable range values, dynamic labels, link button pointing to the original data, etc. . While more LOC, the code structure is also far more explicit and predictable to maintain.
2024-05-02 14:24:23 +02:00
- Tidy3D / Integration
- [ ] Exporter
- [ ] Combine
- [ ] Importer
- Sim Grid
- [ ] Sim Grid
- [ ] Auto
- [ ] Manual
- [ ] Uniform
- [ ] Data
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- Structures
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] Cylinder
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- [ ] Cylinder Array
- [ ] L-Cavity Cylinder
- [ ] H-Cavity Cylinder
- [ ] FCC Lattice
- [ ] BCC Lattice
- [ ] Monkey
feat: Finished Library Medium node. It now supports selecting the variant, and exporting a generated LazyArrayRange of valid freqs/wls. The UI was also revamped, with greatly more readable range values, dynamic labels, link button pointing to the original data, etc. . While more LOC, the code structure is also far more explicit and predictable to maintain.
2024-05-02 14:24:23 +02:00
- Expr Socket
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] LVF Mode
feat: Finished Library Medium node. It now supports selecting the variant, and exporting a generated LazyArrayRange of valid freqs/wls. The UI was also revamped, with greatly more readable range values, dynamic labels, link button pointing to the original data, etc. . While more LOC, the code structure is also far more explicit and predictable to maintain.
2024-05-02 14:24:23 +02:00
- Math Nodes
- [ ] Reduce Math
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] Transform Math - reindex freq->wl
feat: Finished Library Medium node. It now supports selecting the variant, and exporting a generated LazyArrayRange of valid freqs/wls. The UI was also revamped, with greatly more readable range values, dynamic labels, link button pointing to the original data, etc. . While more LOC, the code structure is also far more explicit and predictable to maintain.
2024-05-02 14:24:23 +02:00
- Material Data Fitting
- [ ] Data File Import
- [ ] DataFit Medium
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- Mediums
feat: Finished Library Medium node. It now supports selecting the variant, and exporting a generated LazyArrayRange of valid freqs/wls. The UI was also revamped, with greatly more readable range values, dynamic labels, link button pointing to the original data, etc. . While more LOC, the code structure is also far more explicit and predictable to maintain.
2024-05-02 14:24:23 +02:00
- [ ] Non-Linearities
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- [ ] PEC Medium
- [ ] Isotropic Medium
- [ ] Sellmeier Medium
- [ ] Drude Medium
- [ ] Debye Medium
- [ ] Anisotropic Medium
- Integration
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] Simulation and Analysis of Maxim's Cavity
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
- Constants
fix: Inching closer. I'm of the belief that the correct abstractions are now actually available, and that most-to-all of the required functionality actually already exists within the code base. The art is bringing it together!
2024-05-01 13:54:16 +02:00
- [x] Number Constant
- [x] Vector Constant
- [x] Physical Constant
plan: Working TODO ready
2024-04-27 19:58:50 +02:00
feat: transform node w/sane `DataChanged`-chaining We also implemented a JIT-based `rescale` for `ArrayFlow`, where the same function as for `LazyArrayRangeFlow` passes through and can do an arbitrary symbolic shift/rescale/order-preserving whatever. To make this fast for `ArrayFlow`, we utilize a "test" variable `a`, put it through the function and rescale/strip its units, then `lambdify` it and broadcast the function onto `ArrayFlow.values`. It's an immensely clean way of working. The `lambdify` seems fast, interestingly, but ideally we would of course also cache that somehow. Some details remain: - Fourier Transform index bounds / length are currently not presumed known before actually computing them; it's unclear what's best here, as the design cross-section of physical expectation, mathematical correctness, and ease of implementation (especially trying to keep actual data out of the `InfoFlow` hot-path). For now, the `0..\infty` bounds **will probably break** the `Viz` node. - We've reverted the notion that particular `sim_symbol`s must have a unit pre-defined, which causes a little more complexity for nodes like `TemporalShape`. This question is going to need resolving - The whole `InfoFlow` object really seems to be at the heart of certain lagginess when it comes to the math system. It, together with the index representations, would benefit greatly from a principled refactor. - The `Viewer` node is broken for 3D preview; see #70. Closes #59. Progress on #54.
2024-05-19 07:20:23 +02:00
- [x] Fix many problems by persisting `_enum_cb_cache` and `_str_cb_cache`.