Tyler Hughes

It's fine, I think what we can do is if the 3.0 mode solver is good, we can just support it natively as a new plugin.

yea I agree. although I think there's a possible design where we keep it as a plugin but just dont have it accept `Simulation`.

Can maybe include this in #1414, thinking of closing this.

Actually will leave it open if only for the error message

Note for later: maybe when validating `input_structures`, we can just convert to regular `Structure`, add to `structures`, and then do everything else normally. Similar to how the `permittivity_jax` field works...

Somewhat related: seems `JaxSimulationData.plot_field` also doesn't work when applied to an output field monitor because `JaxSimulation.get_monitor_by_name` doesn't look in `output_monitors`. I think I'll just try to do a refactor where...

I think it would be good to define our 'layers of abstraction' a bit more concretely. Starting from the most fundamental / abstract we might have something like ### Core...

Also, could be worth thinking about: 1. A simple, concrete demo (maybe with generic objects) to demonstrate the benefit of potentially separating the schema / pydantic bits from the methods....

> . Apart from that, and as part of testing, we should sprinkle this around in a bunch of notebooks. I feel like in some cases it will be quite...

It also occurred to me that this will potentially conflict with #1473 so just a note to self that the adjoint run_time calculation will probably need to also change to...