Repository navigation
Wrong definition of units involving "eV" #4062
Description
The Modelica.Units.SI package contains several types involving the electronvolt unit
type FermiEnergy = Real (final quantity="Energy", final unit="eV");
type GapEnergy = Real (final quantity="Energy", final unit="eV");
type DonorIonizationEnergy = Real (final quantity="Energy", final unit="eV");
type AcceptorIonizationEnergy = Real (final quantity="Energy", final unit=
"eV");
type ActivationEnergy = Real (final quantity="Energy", final unit="eV");As I understand, the electronvolte is an accepted unit, like minute, hour, or degree, but it's not an SI unit. The SI unit for energy is "J". We should use "eV" as a displayUnit.
Hence, these declarations should be changed to
type FermiEnergy = Real (final quantity="Energy", final unit="J", displayUnit="eV");
type GapEnergy = Real (final quantity="Energy", final unit="J", displayUnit="eV");
type DonorIonizationEnergy = Real (final quantity="Energy", final unit="J", displayUnit="eV");
type AcceptorIonizationEnergy = Real (final quantity="Energy", final unit="J", displayUnit="eV");
type ActivationEnergy = Real (final quantity="Energy", final unit="J", displayUnit="eV");
Activity
paultjevdh commentedon Nov 27, 2022
Does this mean that eV should be moved to nonSI, and that conversion functions (to_eV, from_eV) should be added to "Conversions"?
dietmarw commentedon Nov 28, 2022
Also, remember that$1 eV \neq 1 J$ so you can not simply change the units to
Jand add a displayUnit. It needs to get converted. Which also means this is something that can be changed for the next major version at the earliest.HansOlsson commentedon Nov 28, 2022
Yes, and when we look at actual uses of it, e.g.,
Modelica.Electrical.Spice3.Internal.Bjt.bjtCalcTempDependenciesusing EnergyGapSi (where Si means Si, i.e., Silicon, not SI) I would not be comfortable quickly changing that to Joule instead.Especially not as
Modelica.Electrical.Spice3.Internal.SpiceConstants.CHARGEhas incorrect last decimal.There's a reason that eV, Dalton and au are listed under "Non-SI units that are accepted for use with the SI".
dietmarw commentedon Nov 28, 2022
I guess that would be the clean way forward.
paultjevdh commentedon Nov 28, 2022
This seems like a modification I could do myself (volunteering), provided it's the right direction for the library.
It will break some dependencies as the one mentioned above, when eV moves from SI to nonSI. Within the library this can be anticipated. Does a change like this (possible model breakage) require a new major version number?
I do not understand the remark of HansOlsson above though. Is he suggesting complete removal of eV as a unit?
That is unnecessary and undesirable I think.
dietmarw commentedon Nov 28, 2022
@paultjevdh Since this is a change that requires a conversion script, it needs to wait until the MAP-LIB project has decided to release a new major version. And this is still a long way off based on the current development pace. So This ticket needs revisiting once the decision on working on MSL 5.0.0 has been made.
HansOlsson commentedon Nov 28, 2022
No, I was merely stating that changing that will be a high-risk task, that will require special care to ensure that nothing changes and since the value for the electrical charge was incorrect it becomes trickier still.
casella commentedon Nov 28, 2022
As I remember it, in the old days the idea was to mix SI and non-SI units in models, e.g. for parameters. Then, at some point, a consensus emerged in the community that this would have led to chaos and confusion, and that it would have been best to stick as much as possible to SI units, and use other unit only for display purposes, exploiting the displayUnit attribute. However,
As a consequence, the MSL mostly avoids using non-SI units even when it would have been convenient, e.g. for temperatures HVAC systems, and relies on displayUnit to show the temperatures in degress Celsius (or Fahrenheit) instead of Kelvin. On the other hand, we kept (some) non-SI units in the library. BTW, I understand the number of non-SI units mentioned in the SI brochure is constantly shrinking, e.g. ,the last brochure doesn't even mention "bar", that we still use as a display unit.
Anyway, this happened long before the upgrade to MSL 4.0.0, possibly when we switched to 3.0.0, though I'm not sure. I guess when this former transition happened, nobody looked a the details of the Spice library, so there were some leftovers like the eV unit.
Though I believe keeping FermiEnergy with unit="eV" in SI was a mistake (it should at least have been moved to NonSI, where it belongs), I agree with @dietmarw that changing the type definition for FermiEnergy from unit="eV" to unit="J" is definitely non-backwards compatible, so it would need to be done in the next major release. There is no decision about that yet, but my recommendation would be to avoid such a thing at least until 2030, because it is so much of a pain from a management point of view. Even when conversion scripts are available.
If that is the current status, I guess tools will have to adapt to it.
tobolar commentedon Nov 30, 2022
This fits probably to #3158
HansOlsson commentedon Nov 30, 2022
Even if somewhat similar, it's different from #3158 where angles are something that users want to provide and propagate.
These EnergyGaps are not parameters that users should normally provide at higher levels (right?); it's normally just internal variables in the model. And even if someone did provide corresponding EnergyGaps for non-Silicon (like Diamond) it seems more likely that they are in eV (e.g., 5.47 eV for Diamond) than in Joules. Thus, I see less reason to change these.
I understand that if someone wants to add up the EnergyGaps to add to the total energy in Joules there is a need to convert, but I find that somewhat esoteric.
casella commentedon Dec 2, 2022
I agree, but then I think we should make it more explicit in the specification what are the allowed units to be used in unit strings. At the moment we are referring to ISO standards (which are not publicly available, you need to pay a fee to read them), and furthermore I understand that the non-SI allowed units in there change over time.
henrikt-ma commentedon Dec 12, 2022
The specification allows the use of custom user-defined units, and I think the freedom to work with different unit symbols is too deeply established in the ecosystem to remove this possibility now. I can also understand if some modelers have a strong preference for expressing energies in
"J", while others have a strong preference for"eV".The most basic feature needed to cope in a setting with mixed units is a safe way to convert between units, modelica/ModelicaSpecification#3300. (The tools in our community have been able to handle
displayUnitconversions for a long time, so I just find it odd that we don't unleash this power so that it can also be used to safely express equations with mixed units.)casella commentedon Dec 12, 2022
Does it? In Section 19 I read
This seems to me to rule out custom-defined units (not
displayUnits, mind you).Are there other places in the specification where exceptions to this rule are stated?
henrikt-ma commentedon Dec 13, 2022
Right below the synax block where
unit-symbolis defined: