⚡ Charge API & `SPICE` common types standardization #2106

daquinteroflex · 2024-12-05T17:42:07Z

Possibly supersedes #2077 if we want to go with this approach?

So I will be documenting design decisions here:

Ultimately HEAT and CHARGE are TCAD simulation tools and I think it'd be of our benefit to have a well defined tcad directory as it expands so I've reorganised, the way the sofware is structured internally.
We need to make sure that our theoretical interfaces are compatible with the other material definitions within our fdtd tools (for the correct frequency range)
We need to name the classes independent of their plot/application in order for them to be extensible for future users.
Chatting with Damian about how to best share electrical data/models between RF and charge as this ultimately needs to be integrated. Seems like a common SPICE electrical standard seems like it could work.
We need to make sure our RF and CHARGE monitors and data are intercompatible, or at least defined with the same class name (and internally check the given data structure)

Things for the future:

This could be an unpopular suggestion. I am of the opinion we should use Yannick's serializable strings in order to define the mobility/recombination/etc. models, and enable users to define their own for a given set of parametric properties. However, maybe this is for a future extension and PR
The VoltageMonitor that we should should be the same as the RF VoltageMonitor. I've separated them for now since we're only doing electro-static simulations, really.
Create SPICE temporal and frequency analysis type definitions - on the lines of these DC ones, possibly that can be co-shared with the RF usage @dmarek-flex just an idea
Create the ElectroStaticDataArray -> spice.Capacitor or diode model definition compilation functions, based on the internal parameter declaration

daquinteroflex · 2024-12-05T18:21:33Z

Re the RF integration:

I'd like to make a proposal. I am keen to introduce standard SPICE electrical definitions that both RF lumped element classes and the charge tcad API can compile into/abstract from. The problem is that in the current charge implementation, we're basically defining the same electrical elements in slightly different ways and it'd be good to have a shared language at some level. Something on the lines of creating a data type compatible with each component in these spice docs
eg. section 3.3.1:
ngspice resistor definition:

RXXXXXXX n+ n- <resistance|r=>value <ac=val> <m=val>
+ <scale=val> <temp=val> <dtemp=val> <tc1=val> <tc2=val>
+ <noisy=0|1>
so we make an equivalent pydantic data type. Then, this type of class definition can represent both charge ressitors and RF lumped element resistors if it were compiled into spice.

I'm debating whether they should be inherited or whether it would go something on the lines f(LumpedResistor) -> SPICEResistor . If it were inherited, then we'd have a common electrical interface accross the solvers that should in principle make our integration much easier in the future. This also makes a clear boundary between tcad models and rf models in cosimulation.
Still debating how to implement so thought to propose for your thoughts.
So like, for example, one problem that is clear is that Voltage in RF and "potential" in charge ultimately should share some aspect of the the data definition in order to provide clear interconnection in the future.
Maybe this is something we don't necessarily have to solve now, but it'd be good to chat about how we see the solvers being integrated at some point and what data structures are shared and what is separate.
I'm making a draft implementation how the shared data types could look like and maybe we can discuss on top of that?
Yep exactly. Like for every electrical component defined in SPICE including DC voltage source (for example a given device material permittivity might change its RF performance under a DC bias). For example, in heat, the heating element is actually a resistor with some charge through it. In a lumped element case, it might be a 50ohm terminator which might eventually warm up based on some RF power applied onto it. It is concievable we might want to cosimulate this behaviour.

daquinteroflex · 2024-12-08T17:44:48Z

Hi @marc-flex , hope you're enjoying the long weekend! So writing this for whenever you get back into this:

What do you think about replacing all these classes with a standard dispersionless Medium definition?

class ChargeSpec(AbstractHeatChargeSpec):
    """Abstract class for Charge specifications"""

    permittivity: float = pd.Field(
        1.0, ge=1.0, title="Permittivity", description="Relative permittivity.", units=PERMITTIVITY
    )


class InsulatorSpec(ChargeSpec):
    """Insulating medium. Conduction simulations will not solve for electric
    potential in a structure that has a medium with this 'electric_spec'.

    Example
    -------
    >>> solid = InsulatingSpec()
    >>> solid2 = InsulatingSpec(permittivity=1.1)

    Note: relative permittivity will be assumed 1 if no value is specified.
    """


class ConductorSpec(ChargeSpec):
    """Conductor medium for conduction simulations.

    Example
    -------
    >>> solid = ConductorSpec(conductivity=3)

    Note: relative permittivity will be assumed 1 if no value is specified.
    """

    conductivity: pd.PositiveFloat = pd.Field(
        1,
        title="Electric conductivity",
        description=f"Electric conductivity of material in units of {CONDUCTIVITY}.",
        units=CONDUCTIVITY,
    )

instead using these standard parameters:

class Medium(AbstractMedium):
    permittivity: TracedFloat = pd.Field(
        1.0, ge=1.0, title="Permittivity", description="Relative permittivity.", units=PERMITTIVITY
    )

    conductivity: TracedFloat = pd.Field(
        0.0,
        title="Conductivity",
        description="Electric conductivity. Defined such that the imaginary part of the complex "
        "permittivity at angular frequency omega is given by conductivity/omega.",
        units=CONDUCTIVITY,
    )

I need to check the backend PR more closely, but if we do need to identify that a Medium is a conductor or insulator I have the impression we should be able to determine this from the defined parameters? This way we have direct integration with the RF material definitions accordingly. This means that the electric_spec could be broadly removed and determined from the FDTD medium models? I'm going to go ahead with this as think it should be broadly reasonable, but if not we can bring it back. If we need to split models based on the frequency dependence permittivity, we'll explore that I think then.

Removing some restrictions for HeatSourceFromElectricField source. Namely: * No need to specify structures, since it is applied everywhere * No need to specify a CONDUCTION simulation. It will fail if it can't load an electric solution ELECTROSTATIC UNSTEADY HEAT AND EQS addition plus Devsim setup: introduced DEVSIM as a simulation type. Requires the implementation of the lagic behind _get_simulation_types()

daquinteroflex · 2024-12-09T10:36:00Z

Hi @marc-flex , so the PR is still dirty in the sense that it needs polishing and some final tasks that we can split between ourselves (but some depend on the backend implementation).

It's a relatively large refactor of the tcad tools structure that in principle should be compatible to develop at least, has defined integration points for the RF cosimulation for the future, and a more clean data/software structure imo.

I've written in the code the TODOs that maybe we need to decide how to polish together since it's backend dependent. I believe the conceptual data should be pretty much identical to before, just that more closely integrated with FDTD models possibly.

We don't have to use this structure, and am open to doing it differently if we can come up with a better approach - but it's an attempt at least of how this tools makes sense to me both as a user and to extend. Happy to meet up via slack and chat if we want after you have a look.

dmarek-flex · 2024-12-09T13:58:40Z

What do you think about replacing all these classes with a standard dispersionless Medium definition?

I think I understand why @marc-flex did it this way, and it might be helpful to have the same or similar approach for the RF simulations. Being able to distinguish between an insulator or conductor is useful for helping to set up a valid Simulation. For one, it might make it easier to automatically apply LossyMetalMedium type to structures that would benefit. It could also be useful in a future validation step where we check that a LumpedPort is electrically connected to 2 conductors, which is required for a valid simulation. Another example is finding out which structures intersecting a plane are good conductors, which would help automatically setup path integrals for the WavePort.

I am not sure if it is better to make a user make that distinction or by checking the value of the conductivity automatically.

daquinteroflex · 2024-12-09T15:29:41Z

Nice, yeah that makes sense.

Would there be a reason we can't computationally distinguish a given medium model being an insulator or conductor based on, say, it's electrical conductivity parameter from the standard EM medium library above a given threshold? On this original implementation, the user would have to redefine the ChargeSpec on top of the EM medium spec if they were to do cosimulation - which can be tedious. From a user perspective, the easiest way to use it would be to define the broad material in the given structure and then let the tools manage the RF and CHARGE behavior on the backed automatically. It sounds like ultimately we want to consolidate these RF medium definitions and the charge ones anyway as they are within the same frequency domain for the physical parameters we care about.

The best would be to just use the existing Medium definitions (since we can leverage the existing materials library and users don't have to redefine another spec for the same class that contains broadly the same information as the rf fdtd regime). If we need to distinguish between what electronic/electric model to apply, I am of the opinion that rather than creating a separate class, we should just make a method within the abstract Medium model class that basically computes in what regime the medium should be treated based the definedmaterial parameters. This method gets overwritten based on the medium model (if in the future we want to support say anisotropic co-simulations etc). Based on which medium models we primarily will use in the RF simulations, we can determine whether we should treat them as insulators or conductors on the backend possibly? However if we need and the above approach would not work for some reason, we can still create an InsulatorSpec, ConductorSpec, or LossyMetalMedium as originally intended within the high-level medium definitions with no problem (bringing that back is easier than reconsolidating likely anyway).

Just ideas, you know better than me how to best use this on the backend so we can keep it as it was originally with no problem.

daquinteroflex · 2024-12-12T09:23:41Z

So worth mentioning this is just a proposal structure anyways but these maybe open the questions we want to decide on anyways. We'll have to deal with cosimulation eventually and maybe it'd be good to plan this so we don't have to rewrite the structure/strategy in a way that affects users after we release.

Ultimatey the questions relate to shared simulation parameter definitions and shared output data structures.

It sounds like right now charge would be electrostatic but some of the parameters can be extended to be dynamic. And deciding between separate or shared monitors/dataarray accordingly also in terms of what is the easiest usage for the end-user creating these simulations.

Maybe @momchil-flex @dbochkov-flexcompute maybe you have some thoughts on how we could approach/structure this

marc-flex · 2024-12-12T09:50:44Z

tidy3d/components/data/data_array.py

+class ElectroStaticDataArray(DataArray):
+    # TODO proper docs Given the combinatorial amount of variations of electro-static performance parameters,
+    #  I think it makes sense to have a single data array that can handle these type of parameter sweeps, and we just
+    #  check for them. Note we need to validate the data aligns properly between the swept variaable. It might be the
+    #  case C-I-V all get swept at the same time
+    """
+    Semiconductor I-V curve data array.
+
+    Example
+    -------
+    >>> I = [0. 0, 1, 4]
+    >>> V = [-1, -0.5, 0, 0.5]
+    >>> td = ElectroStaticDataArray(data=I, coords={"Voltage (V)": V})
+
+    Semiconductor DC capacitance variations with respect to voltage.
+
+    Example
+    -------
+    >>> C = [0. 0, 1, 4]
+    >>> V = [-1, -0.5, 0, 0.5]
+    >>> td = ElectroStaticDataArray(data=C, coords={"Voltage (V)": V})
+    """
+
+    __slots__ = ()
+    _dims = ("Voltage (V)",)
+    _data_attrs = {"long_name": "Current (A)"}


The name has been generalized but this will print everything as I-V curve since _data_attrs = {"long_name": "Current (A)"}

I reckon we keep it as before but maybe think how to implement this more generally in the future.

marc-flex · 2024-12-12T10:01:00Z

tidy3d/components/scene.py

+        # TODO Replace with standard medium info.
+        # elif property == "electric_conductivity":
+        #     medium_list = [
+        #         medium for medium in medium_list if isinstance(medium.electric_spec, ConductorSpec)
+        #     ]
+        #     cond_list = [medium.electric_spec.conductivity for medium in medium_list]


Is there electric conductivity data in medium?

marc-flex · 2024-12-12T10:07:06Z

tidy3d/components/spice/__init__.py

I think it's a good idea to have a common place to store common structures but I don't like the name SPICE 😂 it kind of says we're integrating the open-source tool

agreed, it might be misleading. could it be as simple as "components/circuit"

This is a good point. However, SPICE is just one type of standard of analogue/mixed-signal electrical language common to multiple tools https://en.wikipedia.org/wiki/SPICE#Successors so it does make sense to relate to it (I'm not super sure there's a comprehensive electrical modelling alternative in order to generalise further? Other tools specifically refer to SPICE too and it's directly useful and very common for users to require this tool abstraction.

Would be keen to retain this specific directory if that sounds good since ultimately it's our abstraction of the SPICE standard language?

marc-flex · 2024-12-12T10:24:00Z

tidy3d/components/spice/analysis/dc.py

+class TransferFunctionDC(Tidy3dBaseModel):
+    """This class sets parameters used in DC simulations.
+
+    Ultimately, equivalent to Section 11.3.2 in the ngspice manual.


I'm not sure about this name. It sort of implies we get the response of a device/circuit for a range of input values (e.g., voltage) which may not be the case? We could be interested in a single point operating point?

marc-flex · 2024-12-12T10:36:03Z

tidy3d/components/spice/analysis/dc.py

+    sources: StaticTransferSourceDC | MultiStaticTransferSourceDC = []
+
+    absolute_tolerance: Optional[pd.PositiveFloat] = pd.Field(
+        default=1e10,
+        title="Absolute tolerance.",
+        description="Absolute tolerance used as stop criteria when converging towards a solution. Should be equivalent to the"
+        "SPICE ABSTOL DC transfer parameter. TODO MARC units, TODO check equivalence. TODO what does this mean?",
+    )
+
+    relative_tolerance: Optional[pd.PositiveFloat] = pd.Field(
+        default=1e-10,
+        title="Relative tolerance.",
+        description="Relative tolerance used as stop criteria when converging towards a solution.  Should be equivalent to the"
+        "SPICE RELTOL DC transfer parameter. TODO MARC units, TODO check equivalence. TODO what does this "
+        "mean?",
+    )
+
+    dc_iteration_limit: Optional[pd.PositiveInt] = pd.Field(
+        default=30,
+        title="Maximum number of iterations.",
+        description="Indicates the maximum number of iterations to be run. "
+        "The solver will stop either when this maximum of iterations is met "
+        "or when the tolerance criteria has been met. Should be equivalent to the ngspice ITL1 parameter. TODO units, "
+        "TODO devsim ngspice equivalence",


Another point here is that we're defining here tolerances for this DC case. This should be defined somewhere else since we'll need them for he transient cases as well.

Also, I find it a bit too verbose, which may be annoying from a user standpoint. Like we use heat_spec as opposed to heat_specification to make code more compact. Of course, this is a matter of preference

Yep I think we follow the standard tolerance setting on ngspice for the transient configuration then which will be defined.

Hahaha bringing back the good old question:

https://www.informit.com/articles/article.aspx?p=1824790

https://softwareengineering.stackexchange.com/questions/141175/why-is-verbosity-bad-for-a-programming-language

I do incline for clear understandability of variables even if they're long normally because it's easier to know what something is without reading the documentation but yeah it's a matter of preference. We can have both in pydantic normally but I do appreciate it's a bit more annoying.

Hmm will have a think how to make this better.

marc-flex · 2024-12-12T10:46:46Z

tidy3d/components/spice/sources/dc.py

+class AbstractStaticTransferSourceDC(Tidy3dBaseModel):
+    name: str
+    start: Optional[pd.PositiveFloat] = 0
+    stop: Optional[pd.PositiveFloat] | None = None
+    """
+    TODOMARC chat Either they define the stop or they define the step, how do we want to enforce, validator?
+    """
+
+    step: Optional[pd.PositiveFloat] = pd.Field(
+        1.0,
+        title="Bias step.",
+        description="By default, a solution is computed at 0 bias. "
+        "If a bias different than 0 is requested, DEVSIM will start at 0 and increase bias "
+        "at 'dV' intervals until the required bias is reached. ",
+    )
+    # TODO units


I like how you organized this. It makes a lot of sense now that I see it!
I do have a concern, though: the way you'd define a simulation here would differ from the way sources are defined in FDTD and HEAT, wouldn't it? The source would be inside a TransferFunctionDC and not at the simulation object level, right?

So I believe as we enter more electronic simulations, the definition of what a simulation is will evolve since they can require a combination of DC stimuli and RF stimuli together. As such, we need a way to discretise the relevant simulation steps and combine analysis in flexible ways. This is different from the frequency domain FDTD method so I do think this makes sense to extend though.

On the way the sources get integrated, I am of the opinion in this case it does make sense because of the 1D parametric nature of this source that - still - might directly interact with other sources from other solves. Towards where we need to go I think this structure makes sense and can be integrated in the normal flow.

I don't think the simulation object necessarily needs to evolve for this but maybe we need to think about having a workflow object with which we can define some sort of (loosely) coupled simulations (charge and heat can and should/will be fully coupled but I don't think we'll ever have fully coupled charge-RF or Charge-FDTD). What do you think? @momchil-flex @dbochkov-flexcompute

Yes, sounds good! We could keep the current ***Simulation definitions while combining them in some sort of super-class later on. We can revisit this but to be fair our initial discussions about having a single Simulation-like class that can contain all sorts of components (e.g. optical, heat, charge sources) and then trying to parse what to do internally based on that always sounded to me a bit too ambitious and potentially still not ideal even if we did manage to handle it well, because again it would be hard for the user to have a mental map of what exactly is happening (i.e. how our "translational layer" works). I think similarly to what we discussed about MultiPhysicsMedium, having the separate media that go into different solvers explicitly defined is a bit more cumbersome to initialize, but at least much more explicit from the user point of view. Similarly I would probably imagine us heading to a MultiPhysicsSimulation where simulations associated to various solvers are defined, as well as some specification about how they couple - even if this will not be the most concise way to do things. This could be the same as the Workflow object @marc-flex mentions, or more likely there could be a translation from a MultiPhysicsSimulation to a Workflow that explicitly shows the order of solves that will be done and how e.g. one monitor becomes a medium or a source in another simulation, so the user can exmaine it in advance.

Again, I'm sure we'll be iterating on this a lot but it's probably what I'm leaning towards after our recent discussions.

marc-flex · 2024-12-12T13:37:36Z

tidy3d/components/tcad/boundary/abstract.py

+class HeatChargeBC(ABC, Tidy3dBaseModel):
+    """Abstract heat-charge boundary conditions."""


If we're going to change the directory we might as well change the naming here to TcadBC or something along those lines?

@momchil-flex what do you think about this directory name? Is it ok?

We can still make things like the HeatSimulation backwards compatible by just changing the import location at the tidy3d top level and making sure no internals change at all in the updated PR.

I am not sure. On one hand I feel like TCAD is a bit too general here. Also when you think what it means, not referring to any specific physics but just to computer-aided design, it seems strange to call things e.g. TcadBC. On the other hand, it is widely used and understood to be centered around exactly what we're solving here. Maybe my suggestion would be to rename the folder while still keeping HeatCharge in component names? Does that make sense?

Yep nice, I agree

marc-flex · 2024-12-12T13:42:32Z

tidy3d/components/tcad/boundary/charge.py

+class VoltageBC(HeatChargeBC):
+    """Electric potential (voltage) boundary condition.
+    Sets a potential at the specified boundary.
+    In charge simulations it also accepts an array of voltages.
+    In this case, a solution for each of these voltages will
+    be computed.
+
+    Example
+    -------
+    >>> bc1 = VoltageBC(voltage=2)
+    >>> bc2 = VoltageBC(voltage=[-1, 0, 1])
+    """
+
+    voltage: Union[pd.FiniteFloat, Tuple[pd.FiniteFloat, ...]] = pd.Field(
+        title="Voltage",
+        description="Electric potential to be applied at the specified boundary.",
+        units=VOLT,
+    )


Shouldn't this now derive from AbstractStaticTransferSourceDC or I misunderstood?

Is the intention to use BCs to apply the bias voltage?

I was thinking about this more today.

Should we have the VoltageBC also work as an iterative parameter? Part of me thinks the proper setup would be to create a boundary condition from a DC source rather than iterate directly from it.

I think I'm not following. So far this is always DC. Maybe we can have a chat? I we might be thinking about different things? 😅

marc-flex · 2024-12-12T13:52:43Z

tidy3d/components/tcad/data/monitor_data/charge.py

+class StaticChargeCarrierData(HeatChargeMonitorData):
+    """Class that stores free carrier concentration in Charge simulations."""


Maybe DCFreeCarrierData?

One reason why the static naming maybe makes sense is due to the temporal nature of our simulations, which when they are multi-physical then this changes. For example, free carriers may change on a static heat simulation, independent of a DC voltage/current. As such static represents this temporal relationship clearly I think.

marc-flex · 2024-12-12T13:55:32Z

tidy3d/components/tcad/data/monitor_data/charge.py

+class StaticVoltageData(HeatChargeMonitorData):
+    """Data associated with a :class:`VoltageMonitor`: spatial electric potential field.


What about ElectrostaticPotentialData? Also, with minimum modifications this one and the free carrier one can be reused for harmonic response so they would not longer be DC or static. Having said that, maybe derived classes could also be defined

marc-flex · 2024-12-12T14:06:23Z

tidy3d/components/tcad/materials/charge.py

+class ElectronicSpec(AbstractHeatChargeSpec):
+    # TODO does this account for the whole temporal dynamics? If not then it should be called ElectroStatic, which it was called before, but unsure why it got changed?
+    """
+    This class is used to define electro-static semiconductors.


This was called SemiconductorSpec because it only makes sense for semiconductors. Temperature is included, not only in the different models but, more importantly, in the drift-diffusion equations, which consider Boltzmann statistics

Yeah that makes sense.

The issue I have with the definition of SemiConductor is that this does not imply the "active" nature of a material. Si, Si02 are all semiconductors, but they can also be treated as insulators, or even good conductors, depending on the simulation conditions ie optical/electrical. Electronic is probably not the answer you are right. "ActiveSemiConductorMedium" maybe sounds good to me.

Maybe we can chat about this in #2124

marc-flex · 2024-12-12T14:07:58Z

tidy3d/components/tcad/materials/charge.py

+    electrons_effective_density: pd.PositiveFloat = pd.Field(
+        2.86e19,
+        title="Effective density of electron states",
+        description="Effective density of electron states",
+        units="cm^(-3)",
+    )
+    N_e = electrons_effective_density
+
+    holes_effective_density: pd.PositiveFloat = pd.Field(


These names are confusing. The literature universally calls this effective density of states with Nc and Nv as symbols.

Broadly inclined to bring back your standard naming on this and maybe just make the description longer explaining it more.

marc-flex · 2024-12-12T14:14:35Z

tidy3d/components/tcad/mobility.py

+    exponent_temperature_reference_doping: float = pd.Field(
+        2.4,
+        title="Exponent of thermal dependence of reference doping.",
+        description="Exponent of thermal dependence of reference doping.",
+    )
+    exp_t_d = exponent_temperature_reference_doping


This is what I don't like about verbose names: you end up needing to duplicate variables with shorter names otherwise equations become 100 lines. On top of that, you already have title and description to help users. I personally find these counterproductive. Just my opinion though 😅

We don't really have a well-established guideline about this. I wouldn't use exp_t_d but I do see the point that exponent_temperature_reference_doping is super long. Something like exp_temp_ref_doping seems like a middle ground that sounds OK to me?

Maybe in this very specific model cases it makes sense to have it as it was originally, if we can provide a mathematical description of the equation in the documentation of the class. I do tend for verbosity because that way I don't have to check extra comments or documentation on a variable, but in this case that doesn't make sense as it is a mathematical model and it is required to check it anyway.

Can we have a latex formula in the description? That would make this a bit easier to follow

I think something like this should work

:math:`\\alpha = \\alpha_0 + \\beta I`

This is from our two photon absorption spec, it appears in the main docstring but I'm pretty sure the descriptions are parsed in the same way. Alternatively you can also add a Note, you can also refer to that class: https://docs.flexcompute.com/projects/tidy3d/en/latest/_modules/tidy3d/components/medium.html#TwoPhotonAbsorption

dmarek-flex · 2024-12-12T14:21:18Z

tidy3d/components/spice/components/capacitor.py

@@ -0,0 +1,18 @@
+from typing import Optional


I understand how I could reuse everything in the components folder, but for the RF solver I don't see how I would make use of the classes in analysis or sources. At some point if we support cosimulation with spice it would make more sense, but at the moment I think the main operation would be to extract S parameters from device using Tidy3D and then using the S parameter model of the device in a larger circuit.

marc-flex

Thanks @daquinteroflex for having looked at this. I think this was needed. A common interface between RF and charge is definitely required and this provides just that!

marc-flex · 2024-12-12T14:29:59Z

tidy3d/components/tcad/simulation/heat_charge.py

+        for structure in structures:
+            if isinstance(structure.medium.electric_spec, ElectronicSpec):
+                if (
+                    structure.medium.electric_spec.donors is not None
+                    or structure.medium.electric_spec.acceptors is not None
+                ):


I thought you had removed electric_spec from Medium?

So I've set the foundations of the new structure in #2124 but I think we need to have a discussion how we want to manage the new approach based on that potential API

momchil-flex · 2024-12-13T10:25:33Z

If this is merged, would it make the HeatSolver not backwards compatible?

daquinteroflex · 2024-12-13T19:40:55Z

So made a plan with Marc on how we'll implement this in stages so will close this PR for now. Some of this stuff will be reused with your feedback in a different PR likely. It'd still be great to discuss the feedack points as some of these things would be relevant for the future.

daquinteroflex changed the title ~~⚡ Charge API Consolidation~~ ⚡ Charge API & SPICE common types standardization Dec 6, 2024

daquinteroflex assigned marc-flex and daquinteroflex Dec 8, 2024

marc-flex and others added 25 commits December 8, 2024 19:24

Charge solver with devsim

1bd8270

Minor change

63f789f

Typo

5500b6d

Begin first tcad restructure

500a1d6

Continue with the restructure

9fcc518

Continuing restructure

36c9117

Restructure ongoing still

ed19000

Even more restructure

06ea6d8

Starting to introduce DC sources and create compatibilities

517442a

Restructure on the sources

af6eac4

Continued restructure of the generic types

609d54b

further types

0145ba4

further types

6104985

still deciding structure here

cf8c52c

Need to think how to define materisl here

8d378bd

still refactoring for imports

7a9fd6b

still refactoring for imports

7fe237d

bloody circular imports

7bf0082

finally importing

3817e93

at least tests are not failing immediately

0b09ef4

let's see if stable

77b2a00

what happened

36eea06

wtf is happening

21ff906

I don't get what happened

9b38243

daquinteroflex added the 2.8 will go into version 2.8.* label Dec 8, 2024

daquinteroflex added 5 commits December 8, 2024 20:13

I'm pretty sure there's a problem with gdspy

164ddf7

status

a7b7f01

need to check no backwards damage with the changes

1fcdabf

need to check no backwards damage with the changes

c2a0a82

a little bit more renaming

a4d5a75

marc-flex reviewed Dec 12, 2024

View reviewed changes

dmarek-flex reviewed Dec 12, 2024

View reviewed changes

marc-flex reviewed Dec 12, 2024

View reviewed changes

daquinteroflex closed this Dec 13, 2024

daquinteroflex mentioned this pull request Dec 14, 2024

⚡ Charge API & SPICE/medium common types #2124

Closed

22 tasks

daquinteroflex mentioned this pull request Dec 21, 2024

⚡ Charge API, SPICE, & MultiPhysicsMedium consolidation #2137

Merged

41 tasks

		class HeatChargeBC(ABC, Tidy3dBaseModel):
		"""Abstract heat-charge boundary conditions."""

		class StaticChargeCarrierData(HeatChargeMonitorData):
		"""Class that stores free carrier concentration in Charge simulations."""

		class StaticVoltageData(HeatChargeMonitorData):
		"""Data associated with a :class:`VoltageMonitor`: spatial electric potential field.

⚡ Charge API & SPICE common types standardization #2106

⚡ Charge API & SPICE common types standardization #2106

Conversation

daquinteroflex commented Dec 5, 2024 • edited Loading

daquinteroflex commented Dec 5, 2024 • edited Loading

daquinteroflex commented Dec 8, 2024 • edited Loading

daquinteroflex commented Dec 9, 2024

dmarek-flex commented Dec 9, 2024

daquinteroflex commented Dec 9, 2024 • edited Loading

daquinteroflex commented Dec 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marc-flex Dec 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daquinteroflex Dec 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marc-flex left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

momchil-flex commented Dec 13, 2024

daquinteroflex commented Dec 13, 2024

⚡ Charge API & `SPICE` common types standardization #2106

⚡ Charge API & `SPICE` common types standardization #2106

daquinteroflex commented Dec 5, 2024 •

edited

Loading

daquinteroflex commented Dec 5, 2024 •

edited

Loading

daquinteroflex commented Dec 8, 2024 •

edited

Loading

daquinteroflex commented Dec 9, 2024 •

edited

Loading

marc-flex Dec 16, 2024 •

edited

Loading

daquinteroflex Dec 14, 2024 •

edited

Loading

marc-flex left a comment •

edited

Loading