Enabling electrostatic simulations #1561

marc-flex · 2024-03-21T15:29:29Z

No description provided.

dbochkov-flexcompute · 2024-03-22T16:44:28Z

I think we will have to iterate on naming a few times. My current suggestion would be:
semiconductor_dev/ -> device/
semicon_dev_spec -> charge_spec
AbstractSemiConDevSpec -> AbstractChargeSpec
InsulatingSpec -> InsulatorSpec
DeviceSpec -> ConductorSpec
PotentialBC -> other options could be BiasBC and VoltageBC
ElectricBoundarySpec -> maybe more explicit PotentialBoundarySpec or ElectricPotentialBoundarySpec
UniformChargeSource -> UniformChargeDistribution
ElectrostaticSimulation -> DeviceSimulation or ChargeSimulation
ElectrostaticSimulationData -> DeviceSimulationData or ChargeSimulationData
Note that this PR should be focusing on solving grad(sigma * grad(phi)) = 0 for conductors, rather than grad(eps * grad(phi) = rho for dielectrics (we will need that too, but later)
Thus, DeviceSpec/ConductorSpec should contain conductivity instead of permittivity
I see that you decided not to implement conversion back and forth on the backend and did this inside webapi. Do you plan to keep it this way?
A bigger question is the overall organization of the different solver classes. Currently ElectrostaticSimulation and related classes duplicate a lot of code from HeatSimulation and its related classes. We should definitely try to avoid that. I see two ways:

introduce an intermediate class UnstructuredSimulation(AbstractSimulation) that will absorb the duplicated functionality, and so that HeatSimulation(UnstructuredSimulation) and ChargeSimulation(UnstructuredSimulation). Similar for other classes.
start unifying heat and charge simulation in a single class DeviceSimulation. Meaning that depending on how you setup the simulation it will either calculate for heat, for charge, or for both.

Personally I am leaning towards the second path. But we can iron that out offline.

marc-flex · 2024-03-22T17:46:09Z

I see that you decided not to implement conversion back and forth on the backend and did this inside webapi. Do you plan to keep it this way?

Didn't have an idea in mind and doing it on the webapi seemed easy. I can try doing it on the backend. This possibly makes more sense since I'm going to refactor everything.

2. start unifying heat and charge simulation in a single class DeviceSimulation. Meaning that depending on how you setup the simulation it will either calculate for heat, for charge, or for both.

I think I prefer this option too. I will start form here and tailor the rest towards this. This will also avoid code duplication, I wasn't really happy with the version I had but I wanted a starting point.

tylerflex · 2024-04-10T02:15:17Z

Is it ok for me to convert this PR a "draft" or is it officially ready for review?

(note, we just tend to do this for PRs in progress to make it easier to see which PRs are currently awaiting review / merge)

dbochkov-flexcompute · 2024-04-10T04:52:16Z

Is it ok for me to convert this PR a "draft" or is it officially ready for review?
(note, we just tend to do this for PRs in progress to make it easier to see which PRs are currently awaiting review / merge)

Yeah, this is still in the draft state

dbochkov-flexcompute

Nice work! I think it's getting close. Some general comments:

this is not currently allowed, but for when we have coupled current/heat simulation, what do you think about plotting boundary conditions for different equations? because those can be defined on the same boundaries. Maybe just display either only heat or only electrical bc depending on plot arguments?
All new classes/components and different ways of using them will need to be covered by tests

tidy3d/__init__.py

tidy3d/components/device/boundary.py

tidy3d/components/device_spec.py

tidy3d/components/scene.py

tidy3d/components/device/source.py

tidy3d/components/device/simulation.py

tests/test_components/test_device.py

tidy3d/components/device/heat/simulation.py

tidy3d/components/device/monitor_data.py

tidy3d/components/device/sim_data.py

tidy3d/components/device/simulation.py

tidy3d/components/device/source.py

tidy3d/components/device_spec.py

tidy3d/constants.py

tidy3d/components/device/simulation.py

tidy3d/components/device/boundary.py

tidy3d/components/device/simulation.py

tidy3d/components/scene.py

tidy3d/components/device/simulation.py

tidy3d/components/device/source.py

tylerflex

Thanks @marc-flex, this is a really huge PR and I really appreciate all of the hard work you put into it.

I think the biggest question is whether we want to name this stuff Device simulation. I made a comment maybe we can discuss in a thread.

At a high level, if we can simplify any of the internals by using properties or defining things in the class datastructures, that will help us in the long run to cut down on the code complexity. I made comments where I noticed things.

Overall it looks quite good, thanks again!

tests/test_components/test_device.py

tidy3d/components/device/boundary.py

tidy3d/components/device/source.py

tidy3d/components/device_spec.py

tidy3d/web/api/webapi.py

dbochkov-flexcompute

added a few more comments after the big renaming

tidy3d/components/heat_charge/simulation.py

dbochkov-flexcompute · 2024-06-12T04:42:13Z

tidy3d/components/heat_charge/simulation.py

+        boundaries = self._construct_heat_charge_boundaries(
            structures=structures,
            plane=plane,
            boundary_spec=self.boundary_spec,


will this plot heat and condution bc at the same time? That's probably will not be very useful as they will overlap with each other generally. Probably we should add a parameter in plot_boundaries which tells whether to plot heat or charge bcs, so that when plot_property is called, only corresponding bcs are plotted

I'm thinking of changing all the features plot based on property so that if property="heat_conductivity", sources, bcs and monitors will be plotted for the HEAT setup, whereas it property="electric_conductivity" then all features will be CONDUCTION.

tidy3d/components/heat_charge/simulation.py

dbochkov-flexcompute · 2024-06-12T04:51:11Z

tidy3d/components/heat_charge/simulation.py

+                "Electric BC were specified but not all "
+                "structures have a '.medium' with `.electric_spec` present"


are we checking here for all structures to have electric_spec or just at least one?

it checks that at least one has electric_spec

tidy3d/components/heat_charge/source.py

tidy3d/web/api/webapi.py

daquinteroflex · 2024-06-12T10:04:41Z

tidy3d/components/heat_charge/sim_data.py

@@ -128,22 +128,27 @@ def plot_field(
        """

        monitor_data = self[monitor_name]
+        property_to_plot = None
+
+        if isinstance(monitor_data, TemperatureData):


Looks really interesting! I guess in the future we'll be able to also plot any specific overlapped relationships between the monitors too at the field level, although maybe this would be user-specific rather than provided possibly

daquinteroflex · 2024-06-12T10:05:59Z

tidy3d/components/heat_charge/simulation.py

+        Coupling between these simulations is currently limited to 1-way coupling between
+        heat and conduction simulations. Coupling is specified by defining a heat source of
+        type 'HeatFromElectricSource'. With this coupling, joule heating is calculated as part
+        of the solution to a CONDUCTION simulation and then read in to the HEAT simulation.
+        When using coupling we anticipate two scenarios:
+            1. one in which BCs and sources are specified for both HEAT and CONDUCTION simulations.
+                In this case one mesh will be generated and used for both the CONDUCTION and HEAT
+                simulations.
+            2. only heat BCs/sources are provided. In this case, only the HEAT equation will be solved.
+                Before the simulation starts, it will try to load the heat source from file so a
+                previously run CONDUCTION simulations must have run previously. Since the CONDUCTION


Just future improvement ideas: maybe we can make a little diagram to just illustrate this for people scrolling through the docs. Happy to help when I get some time as I've got the lucidchart available, or can share too!

I like that idea! I'll try to prepare something, thought maybe for another PR?

daquinteroflex

Looks great, thanks for such an incredible effort! Only API docs implementations are missing in the PR I believe.

Lots to think about of what this this will enable! It'd be interesting to do a demo of a standard basic CMOS electronic device (eg. MOScapacitor, etc) for that crowd too to some level - especially for parametric design.

marc-flex · 2024-06-12T15:07:47Z

Lots to think about of what this this will enable! It'd be interesting to do a demo of a standard basic CMOS electronic device (eg. MOScapacitor, etc) for that crowd too to some level - especially for parametric design.

@daquinteroflex If you have an example/paper I'll be happy to work on a notebook!

tylerflex

Make sure to update the CHANGELOG.md as well! including all of the relevant changes that a user might need to know. Thanks!

tylerflex · 2024-06-26T07:09:11Z

Hey @marc-flex when this looks all ready to merge, let me know and I will merge into pre/2.8! or you can do it if you have access.

Added test for HeatChargeSimulation Added functionality to compute heat source from conduction simulation

marc-flex requested a review from dbochkov-flexcompute March 21, 2024 15:29

dbochkov-flexcompute marked this pull request as draft April 10, 2024 04:51

dbochkov-flexcompute reviewed Apr 12, 2024

View reviewed changes