Reduce simulation file size for mode solver

[dbochkov-flexcompute]

In case of large simulations with custom media the total size of simulation file can be quite big. When calling server side mode solver, the entire simulation size is uploaded, however, typically only a small subset of data is required. Maybe we could introduce a way that uploads only the required data.

[tylerflex]

So this would involve potentially finding the part of the custom medium (or several custom mediums) that intersect the ModeSolver.plane and ignoring the rest? Would we need at least one pixel on either side of the plane to accommodate possible sub-pixel effects?

[tylerflex]

I wonder if (in the spirit of the .to_gds stuff) there could be some way to "export" part of a simulation. For example:

sim.subsection(region: Box) -> Simulation.   # generate a simulation containing only the `region`.

do you have something similar in heat solver?

[momchil-flex]

Assigning @dbochkov-flexcompute so that someone is responsible for this; it's a long-term thing though. I put it for 2.6 for now.

[dbochkov-flexcompute]

I wonder if (in the spirit of the .to_gds stuff) there could be some way to "export" part of a simulation. For example:

sim.subsection(region: Box) -> Simulation.   # generate a simulation containing only the `region`.

do you have something similar in heat solver?

Yeah, that makes sense to me. Probably we can expand it to do the following things:

• remove all structures, monitors, and sources outside of target region
• for structures intersecting target region - if they have custom medium select only related data (probably SpatialDataArray.sel_inside() is exactly what we need) https://github.com/flexcompute/tidy3d/blob/develop/tidy3d/components/data/data_array.py#L248
• if keep_monitors=False - remove all monitors
• if keep_sources=False - remove all sources

also care must be taken not to mess up symmetry

Another part of this task would be incorporating this into our webapi call, so that something like this happens:

1. extract mode plane from sub_sim = mode_solver.simulation.subsection(mode_solver.plane)
2. create new mode solver with restricted simulation mode_solver_sub_sim = mode_solver.updated_copy(simulation=sub_sim)
3. submit new mode solver for solving and get data back

One caveat: using a reduced simulation region might result in a slightly different computational grid, but it's probably ok because it won't be used for mode injection or decomposition.

Assigning @dbochkov-flexcompute so that someone is responsible for this; it's a long-term thing though. I put it for 2.6 for now.

I might get on top of this soonish, because it might be quite important for heat solver usability

[dbochkov-flexcompute]

I have a working prototype and now thinking how to split it between Simulation and mode solver plugin

• First option is to just keep everything in mode solver plugin. In this case, since it is used for a very specific purpose, I would not actually care to change simulation dimensions, just remove irrelevant structures/custom medium points and ensure that the same discretization grid is used. This makes it easy to deal with symmetry options, since we are not changing simulation center/size.
• Second option is to implement a standalone Simulation.subsection(region: Box) -> Simulation per Tyler suggestion. This could be potentially useful elsewhere eventually, but requires ironing out a couple of things. First, do we just transfer boundary conditions directly? Perhaps, one way could be to have an optional argument to specify new boundary conditions if needed. Second, have to be careful while dealing with symmetry. The approach that I could see there is the following. If subsection box doesn't go inside symmetry regions, just return a new simulation without a symmetry and center/size taken from the subsection box. If the subsection box does go into symmetry region, automatically expand it symmetrically so that new simulation center coincides with the old simulation center.

Any thoughts @tylerflex @momchil-flex ?

[tylerflex]

I'd say overall just depends on how useful this Simulation.subsection would be and if it's worth your time.

Regarding the specific implementation of that:

First, do we just transfer boundary conditions directly? Perhaps, one way could be to have an optional argument to specify new boundary conditions if needed.

I'd say transfer BCs with option to overwrite them yea.

Second, have to be careful while dealing with symmetry. The approach that I could see there is the following. If subsection box doesn't go inside symmetry regions, just return a new simulation without a symmetry and center/size taken from the subsection box.

That sounds reasonable on me.

If the subsection box does go into symmetry region, automatically expand it symmetrically so that new simulation center coincides with the old simulation center.

I might suggest simplifying this: if the subsection box is exactly centered at the symmetry, then the new simulation ha the same symmetry. If the subsection box intersects the symmetry plane but isn't centered, error? What you suggest probably works, but might be an edge case we dont need to handle and it could indicate someone setting something up incorrectly?

[dbochkov-flexcompute]

I might suggest simplifying this: if the subsection box is exactly centered at the symmetry, then the new simulation ha the same symmetry. If the subsection box intersects the symmetry plane but isn't centered, error? What you suggest probably works, but might be an edge case we dont need to handle and it could indicate someone setting something up incorrectly?

Yeah, I think this makes sense and is easier too, thanks!

[momchil-flex]

Should we close this now @dbochkov-flexcompute

[dbochkov-flexcompute]

yeah