Units for gamma in Modelica.Electrical.Spice3.Internal.Mos.mos2CalcCalcTempDependenciesRevised

[HansOlsson]

Modelica.Electrical.Spice3.Internal.Mos.mos2CalcCalcTempDependenciesRevised contains:

out_c.m_tVbi := in_p.m_vt0 - in_m_type*(in_p.m_gamma*sqrt(in_p.m_phi)) + ...
The in_m_type is just an integer, but the other variables are all voltages, which mean that we have voltage=voltage+voltage*sqrt(voltage), which clearly does not make sense.

Looking at references it seems that the formula looks ok, but gamma is computed as the square root of something, and thus likely should have unit sqrt(voltage) instead (which will require Modelica Language 3.7).

[AHaumer]

I'm pretty sure Modelica.Electrical.Spice3 is almost not used, and it's nearly impossible to maintain it since Christoph Clauss is retired, IMHO we should discuss how to get rid of that sublibrary.
@casella @christiankral what's your opinion?

[christiankral]

I am very much in favor of getting rid of the Spice3 package within the MSL.

One simple way is to indicate the Spice3 as obsolete in one the next releases -- possibly MSL 4.1.0 -- and remove it from MSL 5.0.0. We could then move the Spice3 library to a standalone package on GitHub and see if someone is going to maintain it (or a fork) in the future.

[casella]

I'm pretty sure Modelica.Electrical.Spice3 is almost not used

I'm not really sure about that. As far as I understand the FOSSEE project led by Kannan Moudgalya actually used it.

If the only problem of Spice3 is units, I wouldn't bother, since the original models did not have that attribute.

I would consider deprecating Spice3 if we had evidence that there is something actually broken in it, but I don't see why this should be the case, since I understand the original library was validated against Spice on multiple examples.

[beutlich]

This issue is about the gamma unit. And we have already seen in the comments of the corresponding PR #4377 that there's something more fishy than just the unit.

[HansOlsson]

This issue is about the gamma unit. And we have already seen in the comments of the corresponding PR #4377 that there's something more fishy than just the unit.

At least more fishy than the unit for that variable, it could be some non-unit issue or that the unit-issues are even more complicated than I thought; I don't know.