Massive boost.
Hard to quantify everything.
We're almost batch/inverse design!
- All units are now correct at realization (they weren't before), and
several operations were simply wrong.
- Near-optimal "flow narrowing", which globally minimizes `DataChanged`
even in the face of complex internal property dependencies.
- Sockets now cache `FlowKind` output themselves, with invalidation
provided for and flow narrowing happening before it even enters the
node flow.
- New FlowKind (`PreviewsFlow`) w/plotting, 3D, efficient caching, with
all previewed nodes already adapted.
- Drastically prettified plot output, due to seaborn theme integration,
dict-like data transport w/better labelling, etc. .
- Deep, reliable unit/unit dimension deduction and arithmetic for
`PhysicalType` deduction using dimensional analysis on arbitrary
expression operations.
- Fourier transform w/Nyquist limits as boundary conditions (preserving original shift).
- Vastly improved math node operation checks.
- Symbol constant node, integrating domain presumptions.
- Flow integration for ExprSocket, including for flow-dynamic capabilities and color.
- Viewer node got a big update, incl. live-display of sympy types (even
matrix) and a few Tidy3D types, as well as seperating deeper options
into a "Debug" mode
- Deeply streamlined symbolic flow, including
- **Differentiable Box structure**, w/generic lazy parameter support - only the start!
We implemented a node to load various kinds of data, notably `.npy`,
`.txt`, `.txt.gz`, and `.csv`. The `DataFileImporterNode` really should
expose some settings for setting name/mathtype/physical type/unit of
each unit, and/or treating a column from 2D data as index coordinates.
But the nuances of doing this in a manner general enough to deal with
!=2D data was a lot, and we needed similar abilities in the general math
system anyway.
So, we delved back into the `FilterMathNode` and a little into the
`TransformMathNode`. Fundamentally, a few difficult operations came out
of this:
- Filter:SliceIdx: Slice an array using the usual syntax, as baked into the
function.
- Filter:PinIdx: Pin an axis by its actual index.
- Filter:SetDim: Set the `InfoFlow` index coordinates of an axis to a specific,
loose-socket provided 1D array, and use a common symbol to set the
name+physical type (and allow specifying an appropriate unit).
- Transform:IntDimToComplex: Fold a last length-2 integer-indexed axis
into a real output type, which removes the dimension and produces a
complex output type. Essentially, this is equivalent to folding it as
a vector and treating the `R^2` numbers as real/imaginary, except this
is more explicit.
By combining all of these, we managed to process and constrain the medium data to
be a well-suited, unit-aware (**though not on the output (yet)**) `wl->C` tensor.
In particular, the slicing is nice for avoiding discontinuities.
Workflow-wise, we'll see how important these are / what else we might
want. Also, it turns out Blender's text editor is really quite nice for
light data-text viewing.
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.
We reimplemented the OperateMathNode entirely, and it should now be
relatively to entirely robust. It works based on an enum, just like
`MapMathNode`, which enormously simplifies the node itself. Note that
we're not quite done with sympy+jax implementations of everything, nor
validating that all operations have an implementation valid for all the
`InfoFlow`s that prompted it, but, nonetheless, such fixes should be
easy to work out as we go.
We also finally managed to implement "remembering". In essence,
"remembering" causes `FlowPending` to not reset the dynamic enums in
math / extract nodes. The implementation is generally per-node, and a
bit of boilerplate, but it seems quite robust on the whole - allowing
one to "keep a node tree around" even after removing simulation data.
Extract of sim data is of course more leniant, as it also "remembers"
when there is `NoFlow`. Only new `Sim Data` will reset the extraction
filter enum.
Caches are kept (not memory efficient, but convenient for me), but
only `FlowPending` is actually passed along the `InfoFlow`. This is the
semantics we want - having to deal with this all is a tradeoff of
having data-driven enums, but all in all, it still feels like the right
approach.
We also implement `BLField` support for Blender `IDStruct` types.
There's a crash haunting us specifically with the cylinder array. Other
primitives (esp. ring) work just fine, as does previews of nested-linked
node groups. The crash triggers specifically when the file is saved and
reloaded, whereafter all the `load_post` handlers run fine (like -
extremely fine, we can perfectly access and dereference all of the node
groups, seemingly all the objects, etc.). Then, crash.
We're also discovering that `id_properties_ui` is completely useless for
after-the-fact updating of custom properties within sockets. Which is a
great surprise, and I have trouble thinking it's on purpose - the data
is stored somewhere, after all. All the forced updates/redraws/etc. in
the world don't seem to change this.
We may have to go back to the drawing board with dynamically-updated
min/max. The entire infrastructure with `SocketDef` altering sockets
after creation is entirely, _violently_ unsuited to do a static
modification. But the bare fact is, the dynamic modification methods are
falling short. It's kind of important stuff, this stuff.
We now have a single node for all temporal shapes, which is extremely
usable. Note that we found a bug where input socket caching seems to
survive changes to loose inputs / socket set-driven alterations, which
prevents output from being able to switch with the socket set. We'll
make an issue for it whenever convenient.
Work also continued very briskly with the `SimSymbol` abstraction, which
is really, really working out.
Closes#67.
Driven solely by the Expr socket, we've completely replaced the
dedicated NumberConstant and PhysicalConstant nodes. We also
demonstrated symbolic variable operations w/visualization and
end-node realization, validating that this approach to Expr sockets is
key.
We prepared for a new `BLPropType`, namely dynamic lists of dataclasses,
which will represent dynamic user-adjustable lists. This is the only
proper UI design for declaring symbols directly in an Expr node.
For now, we'll do without symbols, but will be a core feature for design
space exploration (aka. batch-run a bunch of sims), and for inverse
design.
Else, a few fixes: Naming of `ManagedBLImage` was updated, the expr
socket info display was fixed to display even when only output
information is available,
A few TODOs remain in the Expr Constant, but they are less important
before dynamic symbol declarations are in place.
We greatly enhanced the field, flux monitors, and added the permittivity
monitor.
mobj naming is still a bit borked; we need a node-tree bound namespace
to go further with it.
For now, don't duplicate nodes, and don't use multiple node trees.
Some rather foundational things were fundamentally broken, especially related to the initialization procedures of fields / cached properties.
- We completely revamped `bl_cache`, fixing many to-be-discovered bugs.
- We completely streamlined `BLField` property logic into reusable
`bl_cache.BLProp` and `bl_cache.BLPropType`.
- We implemented `BLInstance` superclass to handle ex. deterministic
persistance of dynamic enum items, and other nuanced common
functionality that was being duplicated raw.
- We implemented inter `cached_bl_property` / `BLField` dependency
logic, including the ability to invalidate dynamic enums without
@on_value_changed logic. This **greatly** simplifies a vast quantity
of nodes that were traditionally very difficult to get working due to
the sharp edges imposed by needing manual invalidation logic.
- We gave `ExprSocket` a significant usability upgrade, including
thorough parsing logic in the `SocketDef`.
It's not that existing nodes are as such broken, but their existing bugs
are now going to cause problems a lot faster.
Which is a good thing.
BREAKING CHANGE: Closes#13. Closes#16. Big work on #64. Work on #37.
It's recommended to add license headers to all files in an AGPL project, in case a file is viewed outside the context of its main repository. We're using a `pre-commit` tool to manage this, to make sure it's consistently applied to all our Python files.
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!
The performance difference isn't as clear cut as hoped.
However, the plotting procedure is enormously more straightforward, and
performance is more predictable.
So it's worth it.
We're managing to perfectly reuse figure/canvas/axis, but still hovering at around 70-80ms.
Mind you, the tested machine is an older laptop.
Still, things feel interactive enough, especially together with the
other modifications.
To really amp it up, we can look into blitting. It requires alterations
to the plotting methodology, but it offers a cached approach to drawing
only altered pixels (the bottleneck with `canvas.draw()` is that it
needs to render all the pixels, every time).
We can also try to lower the resolution if it's too slow.
The Viz node now detects the shape of the data, and presents compatible
plot options.
Not all are implemented, but a few quite important ones are.
Additionally, a number of dataflow-related bugs were investigated and
fixed. A few were truly damaging, but many simply resulted in gross
inefficiencies - we must be careful declaring BLFields that are updated
in hot loops!
Moreover, it is exceptionally easy to add more as needed, as we analyze
more and more sims.
The only limit is `matplotlib`, which is... well, yeah.
Due to the BLField work, the dynamicness of the Viz node is quite
under control, so there will not be any critical issues there.
The plotting lags (70ms total in the hot loop), but that's actually
entirely fixeable.
It's also entirely the `managed_bl_image`'s fault.
Fixing these inefficiencies will also make Tidy3D's builtin plots
near-realtime, incidentally.
We profiled the following currently:
- 25ms: Creating `fig = plt.subplots`. We can reuse fig per-managed
image.
- 43ms: The BytesIO roundtrip, including `savefig`. We can instead use
the Agg backend, `fig.canvas.draw()`, and a `np.frombuffer` to both
plot directly to the memory location,
- ~3ms: Actual plotting functions in `image_ops`. They are seriously fast.
- ~0ms: Blitting pixels to the Blender image - this was optimized in
4.1, and it shows; the time to copy the data over is essentially nothing.
BLField has gotten a huge facelift, to make it practical to wrangle
properties without the sharp edges.
- All the "special" UI-exposed property types can now be directly
constructed in a BLField marked with 'prop_ui'.
- The most appropriate internal representation will be chosen to
represent the attribute based on its type annotation, including sized
vector-like `bool`, `int`, `float` for `tuple[...]`.
- Static EnumProperties can now be derived from a special `StrEnum`, to
which a `to_name` and `to_icon` method is attached.
- Dynamic `EnumProperty` can now be used safely, with builtin
workarounds to the real-world reference-loss-crash (realized
in the Tidy3D Cloud Task node) and jankiness like empty enum.
- The update method is now fully managed, negating all bugs related to
improper update callback naming.
- Python-side getter caching is preserved for ui-exposed
properties, with the help of node/socket base class support for
passing a `Signal.InvalidateCache` to BLFields that are altered in the
UI.
The cost to all this niceness is rather low, and arguably, positive:
- Dynamic Enum/String searchers no longer "magically" invoke all the
time, since the values seen by Blender are cached by the BLField.
- To regenerate the searcher output, an `@on_value_changed` should be
made by the user to pass `Signal.ResetEnumItems` or
`Signal.ResetStrSearch` to the `BLField`.
- Since searching is no longer eager, there is no danger of
out-of-reference strings (which crash Blender from EnumProperty), but
also a greatly reduced performance problems associated with
the hot-loop regeneration of EnumProperty strings.
- The base classes are now involved with BLField invalidation, to ensure
that the getter caches are cleared up when the UI changes. For the
price of that small indirection (done cheaply with set lookup),
all attribute lookups are generally done in a single lookup, completely
avoiding Blender until needed.
- This does represent another increase in confidence wrt. the event
system's integrity, but so far, that has been a very productive
direction.
**NOTE**: The entire feature set of BLField is not well tested, and will
likely need adjustments as the codebase is converted to use them.
Enormously important changes to the data flow semantics and invalidation
rules. Especially significant is the way in which the node graph
produces a deeply composed function, compiles it to optimized machine
code with `jax`, and uses a seperately cached data flow to insert values
into the function from anywhere along the node graph without recompiling
the function.
A critical portion of the math system, namely the unit-aware dimensional
representation, is also finished. The `Data` node socket type now
dynamically reports the dimensional properties of the object flowing
through it, courtesy the use of a seperate data flow for information.
This allows for very high-peformance unit-aware nearest-value indexing built on binary
search.
Also, dependency management is completely ironed out. The `pip install`
process now runs concurrently, and the installation log is parsed in the
background to update a progress bar. This is the foundational work for a
similar concurrent process wrt. Tidy3D progress reporting.
The serialization routines are fast and effective.
Overall, the node graph feels snappy, and everything updates smoothly.
Logging on the action chain suggests that there aren't extraneous calls,
and that existing calls (ex. no-op previews) are fast.
There will likely be edge cases, and we'll see how it scales - but
for now, let's go with it!
We have a far more sane approach to nodeps now, which
allows us to essentially have two loggers - one that is
very useful, pretty, and clear, but requires a 'rich'
dependency, and one that is simple.
In this spirit, we factored out services/ too.
We can also set the initial console log level now when
packing the .zip.
There's still work to do with the actual flow for deps
installing / uninstalling.
But it should be far more robust now.
Finally, we have a barebones working `quartodoc`-based docs site.
It's super clever; see <https://github.com/machow/quartodoc>.
As it's "just" a quarto project with some python autodiscovery,
fleshing it out with ex. math, images, diagrams, and so forth
should be exceptionally easy.
As we develop, various linter-guided fixes are being realized.
This will be a long process, best done as we spiff everything up
in preparation for general release.
