Wrong definition of units involving "eV"

[casella]

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");

[paultjevdh]

Does this mean that eV should be moved to nonSI, and that conversion functions (to_eV, from_eV) should be added to "Conversions"?

[dietmarw]

Also, remember that $1 eV \neq 1 J$ so you can not simply change the units to J and 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]

Also, remember that 1eV≠1J so you can not simply change the units to J and 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.

Yes, and when we look at actual uses of it, e.g., Modelica.Electrical.Spice3.Internal.Bjt.bjtCalcTempDependencies using 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.CHARGE has 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]

Does this mean that eV should be moved to nonSI, and that conversion functions (to_eV, from_eV) should be added to "Conversions"?

I guess that would be the clean way forward.

[paultjevdh]

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]

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

This seems like a modification I could do myself (volunteering), provided it's the right direction for the library. It will
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.

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]

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]

As I remember it, in the old days the idea was to mix SI and non-SI units in models,...

This fits probably to #3158

[HansOlsson]

As I remember it, in the old days the idea was to mix SI and non-SI units in models,...

This fits probably to #3158

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]

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]

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 displayUnit conversions 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]

The specification allows the use of custom user-defined units

Does it? In Section 19 I read

Unless otherwise stated, the syntax and semantics of unit expressions in Modelica conform with the international standards International System of Units (SI) by BIPM superseding parts of ISO 31/0-1992 General principles concerning quantities, units and symbols and ISO 1000-1992 SI units and recommendations for the use of their multiples and of certain other units."

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]

Right below the synax block where unit-symbol is defined:

It is required that basic and derived units of the SI system are recognized, but tools are allowed to additionally support user-defined unit symbols.