Changing units in a consistent fashion

[rot4te]

Per David, there is no need to change the units of constants that are only used 'under the hood' which is to say, in the simulation. This means that we don't need a global constants: instead, we want functions like mass_of(), or velocity_of(), which take in an object and return a number for viewing, rather than for computation.

I've added a new type to ParticleTypes.jl that has name, charge, mass, spin, and anomalous magnetic moment attributes. A good (and extremely simple) task is to write a function for each numeric attribute that takes in the TrackedSpecies object and a unit type, and if possible returns the attribute in the requested units. After this, there should be a collection of functions that handle all the dimensionful constants in PhysicalConstants.jl that are not associated directly to particles, eg c_light and h_planck.

It turns out the desired functionality is way simpler than what you were trying to do earlier... whoopsie.

[DavidSagan]

I'm confused about what "return a number for viewing, rather than for computation." means.

Also thinking about it, it looks like function like mass_of() are not necessary since the mass is stored in the TrackedSpecies struct. For computational speed, the components of TrackedSpecies should hold the values appropriate for the units chosen by set_units().

[DavidSagan]

The name TrackedSpecies can be shortened to something like Particle since this structure can be used in contexts other than tracking.

[rot4te]

I'll change the name today.

My understanding of the requirements of set_units() is that it changes the units of output, but all of the calculations under the good still happen in the base unit system for simplicity. In order to extend the usefulness/compatibility of the package, I guess it's important to be able to change the units inside the tracking structure, but I would think it was more relevant to Bmad to take any output and convert the unit before display to the user. Is that correct?

On Tue, Apr 23, 2024, 00:15 David Sagan @.***> wrote:

The name TrackedSpecies can be shortened to something like Particle since this structure can be used in contexts other than tracking.

— Reply to this email directly, view it on GitHub https://github.com/bmad-sim/AtomicAndPhysicalConstants.jl/issues/19#issuecomment-2071374488, or unsubscribe https://github.com/notifications/unsubscribe-auth/APVF2CDH2TJ2OMJNWCYCMKLY6XN5HAVCNFSM6AAAAABGTSX6T2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZRGM3TINBYHA . You are receiving this because you authored the thread.Message ID: @.***>

[DavidSagan]

What is of prime importance is calculational speed. Set_units() should define what units the User wants to use in a calculation. Conversion to other units for display is secondary.

[DavidSagan]

Also thinking about it, it looks like function like mass_of() are not necessary since the mass is stored in the TrackedSpecies struct. For computational speed, the components of TrackedSpecies should hold the values appropriate for the units chosen by set_units().

Thinking about it a bit more, there is the issue of passing an instance of a Particle struct between packages that are using different units. In this case there needs to be a conversion. The easiest way to do this would be to have the mass and charge component of the Particle struct in some base unit and then the function mass_of() and charge_of() can return the correct value for the units used by the package. And yes this walking back from my previous response.

Proposal: When set_units() is called, besides constants like c_light being defined, a set of conversion factors like __mass_conversion_factor are defined as well. When mass_of(my_particle) is called, it returns my_particle.mass * __mass_conversion_factor. There would also be a two arg version, EG: mass_of(my_particle, :MeV) which could be used for display purposes and would convert to the units given.