Proper handling of units in the user interface
fhagemann opened this issue · 7 comments
It would be nice to allow for units in the user interface, especially for plotting, e.g.
plot(simulation.electric_field, xlims = (-4u"cm", 4u"cm"))This also comes with nice unit handling in configuration files (see #182).
We should take a look at UnitfulRecipes.jl.
Regarding the input and output units of the signal generation.
I think we should return the signal in units of (induced) charge and not "energy" anymore.
The conversion from charge to energy is done by the electronics which is not part of SSD.
The conversion from the energy of the hit table (input) to number of charge carriers
should happen before the drift is simulated as the self-repulsion needs charge.
Sounds good.
I encountered that some keyword arguments (max_tick_distance) always require units which forces the user to install and load Unitful. We should also allow for giving it just values that will be interpreted in SI units.
Adding UnitfulRecipes.jl as additional dependency fixes the plotting issue
(we can then just pass values with units to plot and they will automatically be added to the axes labels, quite neat!)
using Plots, Unitful, UnitfulRecipes
plot([1,2]u"m", [1,2]u"m", xlabel = "x", ylabel = "y", legend = false)
If you add more stuff with other units, it will keep the units from the first plot command
plot!([1200,1300]u"mm", [1000,1100]u"mm")
So, we can just add the internal units to all the objects/values when we plot them.
The question is how we want to deal with external units... Should we allow for a keyword argument in the plot recipe, something like plot(..., length_unit = u"mm")?
It should be possible to handle units when it comes to CartesianPoint or CylindricalPoint when passing this to Event, for example...