Enabling electrostatic simulations

[marc-flex]

[dbochkov-flexcompute]

• 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:

1. introduce an intermediate class UnstructuredSimulation(AbstractSimulation) that will absorb the duplicated functionality, and so that HeatSimulation(UnstructuredSimulation) and ChargeSimulation(UnstructuredSimulation). Similar for other classes.
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.

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

[marc-flex]

• 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]

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]

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

[marc-flex]

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]

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.