GitHub packages is useless because public repositories require an authenticaton token.

Instead, we're going to use a different repository.

• Find a repository we want to use
• Configure repository to build release and send to public (can be correlated with GitHub releases page but perhaps not?)

This partially builds on #10 but is the actual pluggable solvers.

I know that @Caeleron was working on a pretty cool solver that used LRC circuit components and was more stable than a basic MNA solver.

We could also make a non-smooth dynamic systems solver.

This issue is more to suggest building such a solver, and a new issue should be linked and created if we actually have concrete ideas for a solver we want to implement.

I've been told multiple times that we should rename it from libelectric since it does a whole lot more than electrical simulations, and I tend to agree.

I've suggested names like libsim and I've also heard things like simlib and libeln suggested.. but there's no consensus yet.

Once this is done, we can unblock uploading this to Maven (try not to name conflict with anything up there).

A generic circuit API has been partially implemented but is not particularly useful at the moment.

Thoughts were that we could design an API that could be used for abstracting away different simulators and be simply the information required to express the state of a circuit to a simulator and then get the missing information from the simulator (eg, branch currents, node/pin voltages, etc.)

It would also be cool to have an HTTP/2 based API, but that can be handled in another issue.

We need a (new) thermal system solver since I deleted the non-functional one.

Ideally, it would be a volumetric solver and not just a "same size block, move energy on tick" type solver like Electrical Age 1 had.

This would take into account the thermal conductivity of the materials and also take into account the surface area of the faces in the calculation (likely resulting in a measurement of watts per square meter across surfaces).

We have a file (Materials.kt) in the project that already contains thermal conductivity of copper and other common materials that would participate in the thermal simulation, but we can certainly add more.

Allow the mode of the diode to be fetched from the Diode class via a method.

It should probably use an enum to specify this state as forwarding or not forwarding.

enum class DiodeState {
    FORWARDING, BLOCKING
}