`Quantity` class for material parameters about ubermag HOT 4 CLOSED

The question is whether Quantity class should be separate class, or it can simply be a Field class to which unit is assigned. It is maybe not a smart solution to have a constant scalar field object just to represent A=8.87e-12 for example, but we should somehow take into account spatially varying parameters, which can be easily represented with scalar fields.

from ubermag.

The Field class could have a units attribute which is the Quantity object. We could then assume that the values in the field class need to be multiplied by the quantity object to get the actual field values. (It is not clear whether we want to allow the number in the Quantitity to be different from one - if we do, then lots of code will have to multiply the number with the actual Field (numpy array or scalar, say), which is both a repeated extra operation (performance) and might be forgotten (correctness). So in practice, we could use the units attributed just to store the physical dimensions, such as A/m.

For the latex representation, we can get the units from units, and we can get the number from the Field. If the Field is spatially varying, we could compute the average value, or some other statistical measure for the latex representation.

from ubermag.

A related question is whether we should use the Field class to represent objects that are often just a scalar, but could vary, such as the exchange constant A. I suppose we could do that; either by just accepting that we waste some memory if a scalar A is stored once for every cell. Or by having specialist Field classes for constants (which store the constants only once but provide the same interface). There may be a performance penalty though; this needs a little bit more thought / experimentation.

from ubermag.

This idea has been abandoned for simplicity. We assume everything is in SI units.

from ubermag.