Methodology

The goal of this code base is not to be the fastest but to be maintainable. This is why you'll see a lot of comments and descriptors of processes within the code. To be easily maintained python has been chosen as the primary language for this repository. There are command line interfaces (*.dll, *.exe) files but these are primarily third party files provided so we can more easily interface with equipment. If something needs to be faster try to default to C or C++ because these are more widely useable since they don't require a license such as MATLAB or Mathematica.

Adding Code

To add code to the data base because we want to keep it widely applicable. In the ideal case the experimental logic and analysis would not change between systems but we have different hardware so we want to make sure we follow the abstract classes guidelines when updating code. This provides a framework of expected functionality. An example of this is driving the NV using a SRS SG384 signal generator which generates a sine wave that has a frequency and an amplitude but we could reasonably also use a arbitrary wave generator(AWG) can also fulfill this requirement and experimentally we want this to be interchangeable without requiring a rewrite of the experimental logic.

This is why the function is called generate_sine_wave_hz_dbm() because it can be done by both the signal generator needs a frequency and power level but the AWG needs a duration as well so we code the signal generator class to take in all additional terms but not to use them. This means we don't change experimental logic and we can have transference of the code.

This is very difficult to do correctly on the first go which is why it is asked that you create a branch from the main branch when you start editing code. This can then be merged to the main branch after thorough consideration so we can avoid breaking others working experiments. We also want to iterate the version number located in the pyproject.toml file on every merge this will allow systems that want to update to update and revert to an earlier version more quickly if problems arise.

Units

When possible for abstract functions and definitions keep all units in base SI units. This is to enforce a basic expectation where if I switch between devices or systems we know what units to use. This is further emphasized for the use of variables followed by their unit. This just makes sure we know for sure what unit we are working with. This is a little clunky looking at first but it helps iron out issues overall

variable_unit;frequency_hz;temperature_k;omega_rad_per_s

• Frequency = Hertz (hz)
• Angular Velocity = radians per second (rad_per_s)
• Distance = Meter (m)
• Time = Seconds (s)
• Mass = Kilograms (kg)
• Temperature = Kelvin (k)
• Current = Amps (a)
• Voltage = Volts (v)
• Luminous Intensity = Candella (cd)
• Chemical Amount = Mole (mol)
• Fluid amount = Liter (l)

Labeling

This is so we can be able to tell what we are dealing with immediately and have some expectation on what should happen

• Classes are labeled with PascalCase where the start of a new word is capitalized and there is no space
• Variables, files, and functions are labeled using snake_case where everything is lower case and spaces are denoted by underscores