Clean up formatting

docs/source/Learn/bskPrinciples/bskPrinciples-10.rst

@@ -1,14 +1,14 @@
 .. _bskPrinciples-10:
 
-.. warning:: 
+.. warning::
 
     This section refers to a deprecated way of operating with C modules. Refer to previous documentation pages for the updated way.
 
 Deprecated: Using old-style C modules
 =====================================
 In more recent Basilisk scripts, whether a module is implemented in C++ or C should not make
 any difference on how this module is used in Python scripts. However, this has not always been
-the case, and you might encounter some code that uses the older syntax. This documentation 
+the case, and you might encounter some code that uses the older syntax. This documentation
 summarizes how to use this older syntax.
 
 Previous documentation pages have taught us that C++ modules (and new-syntax C modules) are
@@ -27,13 +27,13 @@ In order to perform the same operations on an old-syntax C module, one would do:
     moduleWrap.modelTag = "someModuleName"
     scSim.AddModelToTask("taskName", moduleWrap, moduleConfig, priority)
 
-Note that in this case, we created a "Config" object ``someModule.someModuleConfig``. Connecting 
+Note that in this case, we created a "Config" object ``someModule.someModuleConfig``. Connecting
 messages and setting parameters of the module is done through this object. Then, the ``setModelDataWrap``
 method of the simulation object is called on the "Config" object, which generates the "Wrap" object.
 The unique name must be set on the "Wrap" object. Finally, the module is added to the simulation by
 using both the "Wrap" and "Config" objects in the ``scSim.AddModelToTask`` method.
 
-The need for separate "Config" and "Wrap" objects arises from the lack of classes in the C programming language. 
+The need for separate "Config" and "Wrap" objects arises from the lack of classes in the C programming language.
 The "Config" objects, as well as the relevant ``updateState``, ``Reset``, and ``SelfInit`` methods,
 are written in pure C for C modules. However, the simulation framework is written in C++ and it expects
 the modules to be C++ classes. The "Wrap" object is this C++ class, which holds references to

docs/source/Learn/bskPrinciples/bskPrinciples-11.rst

@@ -2,7 +2,7 @@
 
 .. _bskPrinciples-11:
 
-.. warning:: 
+.. warning::
 
     This section refers to a deprecated way of logging variables. Refer to previous documentation pages for the updated way.
 

docs/source/Learn/bskPrinciples/bskPrinciples-2a.rst

@@ -44,5 +44,3 @@ If you execute this python code you should see the following terminal output:
     0.0
     BSK_INFORMATION: C Module ID 1 ran Update at 0.000000s
     1.0
-
-

docs/source/Learn/bskPrinciples/bskPrinciples-8.rst

@@ -45,5 +45,3 @@ To disable a single task, this is done with the :ref:`SimulationBaseClass` metho
     BSK executed a single simulation step
     BSK_INFORMATION: C Module ID 1 ran Update at 4.000000s
     BSK executed a single simulation step
-
-

docs/source/Learn/bskPrinciples/bskPrinciples-9.rst

@@ -32,4 +32,4 @@ at 1Hz as this method is called at the task update period.
 The integration type is determined by the integrator assigned to the primary ``DynamicObject`` to
 which the other ``DynamicObject`` integrations is synchronized.  By default this is the ``RK4``
 integrator.  It doesn't matter what integrator is assigned to the secondary ``DynamicObject`` instances,
-the integrator of the primary object is used.
+the integrator of the primary object is used.

docs/source/Learn/makingModules/advancedTopics/creatingDynObject.rst

@@ -35,4 +35,3 @@ scenarios as with the spacecraft example.  See the discussion in :ref:`bskPrinci
 Basilisk modules that inherit from the ``DynamicObject`` class can be linked.  If linked,
 then the associated module ordinate differential equations (ODEs) are integrated
 simultaneously.
-

docs/source/Learn/makingModules/cModules/cModules-1.rst

@@ -83,4 +83,3 @@ For example, assume the module needs an array of input messages of type ``SomeMs
 The module needs to implement separate logic to determine how many messages have been set.  For example, the reset function could loop over this array and up to what slot the associate message object has been linked.
 
 As the C wrapped message object can act as either input or output messages, the above example can readily be converted to an outpout message example by renaming the array variable ``moreOutMsgs``.
-

docs/source/Learn/makingModules/cModules/cModules-3.rst

@@ -101,4 +101,3 @@ Assume the module has an array called ``moreInMsgs`` which contain input message
 .. code:: cpp
 
     inMsgBuffer = SomeMsg_C_read(&configData->moreInMsgs[3]);
-

docs/source/Learn/makingModules/cppModules/cppModules-1.rst

@@ -105,4 +105,3 @@ To define a vector of output messages, we define a vector of message pointer usi
 
     public:
         std::vector<Message<SomeMsgPayload>*> moreOutMsgs;      //!< variable description
-

docs/source/Learn/makingModules/cppModules/cppModules-3.rst

@@ -110,4 +110,3 @@ Note that with the ``new`` call above the memory associated with this output mes
             delete this->moreOutMsgs.at(c);
         }
     }
-

docs/source/Learn/makingModules/pyModules.rst

@@ -9,10 +9,10 @@ Making Python Modules
 
 Python modules are a good alternative to C and C++ modules for quick prototyping.
 They are defined entirely in a Python script, which means that there is no need
-for a header (``.h``), definition (``.cpp``), or SWIG interface file (``.i``). However, they 
+for a header (``.h``), definition (``.cpp``), or SWIG interface file (``.i``). However, they
 are much slower than C or C++ modules, which will significantly slow down your simulation.
 
-Python modules are implemented by subclassing ``SysModel`` from ``Basilisk.architecture.sysModel``. 
+Python modules are implemented by subclassing ``SysModel`` from ``Basilisk.architecture.sysModel``.
 Then, one can implement the ``__init__``,
 ``Reset``, and ``updateState`` methods in the same way that one would
 implement these methods in C++. Remember to always call ``__init__`` of

docs/source/Support/bskReleaseNotes.rst

@@ -43,8 +43,8 @@ Version 2.3.0 (April 5, 2024)
 - Fixed a python version checking bug that prevented Basilisk from compiling on Windows
 - Created a new example scenario :ref:`scenarioHaloOrbit` demonstrating a near-Halo orbit simulation
 - Updated versioning to better follow the `semantic versioning <https://semver.org>`_ standard, in the format
-  ``MAJOR.MINOR.PATCH``. Releases will increment the minor version number, while pull requests into develop will 
-  automatically increment the patch number. This allows users to reference/require specific versions of Basilisk 
+  ``MAJOR.MINOR.PATCH``. Releases will increment the minor version number, while pull requests into develop will
+  automatically increment the patch number. This allows users to reference/require specific versions of Basilisk
   outside of the release cycle.
   Online documentation is only built for the ``MAJOR.MINOR.0`` releases
 - updated plotting of ``opNav`` example scenarios to work again with latest version of ``matplotlib``
@@ -164,7 +164,7 @@ Version 2.2.1 (Dec. 22, 2023)
 - Added a new method ``setDataBuffer()`` to :ref:`simpleStorageUnit` and :ref:`partitionedStorageUnit` to add or remove data from specified partitions.
 - Refactored ``simIncludeGravBody``. The most notable change for users is that the commonly used line
   ``scObject.gravField.gravBodies = spacecraft.GravBodyVector(list(gravFactory.gravBodies.values()))``
-  can be replaced by ``gravFactory.addBodiesTo(scObject)`` (where ``scObject`` is a ``spacecraft.Spacecraft`` 
+  can be replaced by ``gravFactory.addBodiesTo(scObject)`` (where ``scObject`` is a ``spacecraft.Spacecraft``
   or  ``spacecraftSystem.SpacecraftSystem``, and ``gravFactory`` is a ``simIncludeGravBody.gravBodyFactory``)
 - Added condition in :ref:`thrustCMEstimation` to avoid measurement updates when input ``attGuidInMsg`` has not been written.
 - Added :ref:`scenarioSepMomentumManagement` to show how to use a dual-gimbaled electric thruster to perform contunuous
@@ -218,7 +218,7 @@ Version 2.2.0 (June 28, 2023)
 - Refactored the :ref:`prescribedMotionStateEffector` dynamics module to vary the prescribed states across the dynamics
   integration time step.
 - The encryption build option for the project's conan zmq dependency is disabled because it is uneeded.
-- Added an optional ``controllerStatus`` variable and ``deviceStatusInMsg`` message to the :ref:`simpleInstrumentController` to 
+- Added an optional ``controllerStatus`` variable and ``deviceStatusInMsg`` message to the :ref:`simpleInstrumentController` to
   match the functionality of the corresponding data and power modules
 - Corrected tasks priorities in several scenarios and added checks in two modules to ensure that C MSG read errors are not thrown
 - Reworked how integrators are implemented. New Runge-Kutta integrators may
@@ -376,7 +376,7 @@ Version 2.1.4 (Oct. 1, 2022)
 - added new attitude pointing scenario :ref:`scenarioAttitudeFeedback2T_stateEffTH` that uses
   the new :ref:`thrusterStateEffector`
 - added ability to simulate faults within :ref:`coarseSunSensor` module
-- created a 1-DoF rotating rigid body class ``SpinningBodyStateEffector``. It is built in a general way to simulate 
+- created a 1-DoF rotating rigid body class ``SpinningBodyStateEffector``. It is built in a general way to simulate
   any effector with a single spinning axis.
 
 
@@ -456,7 +456,7 @@ Version 2.1.1 (Dec. 15, 2021)
 
 Version 2.1.0 (Nov. 13, 2021)
 -----------------------------
-- added BSpline function to ``utilities`` and related UnitTest. 
+- added BSpline function to ``utilities`` and related UnitTest.
 - added kinematic relations between angular accelerations and second derivative of MRP set to
   :ref:`rigidBodyKinematicsutilities` library
 - updated the installation script to function with the latest ``conan`` program and the recent
@@ -473,7 +473,7 @@ Version 2.1.0 (Nov. 13, 2021)
 - added new scenario :ref:`scenarioVariableTimeStepIntegrators`
 - updated :ref:`scenarioIntegrators` to include the ``rkf45`` and ``rkf78`` options
 - changed the way :ref:`spacecraftReconfig` gets the deputy's mass properties. It now receives that information
-  through a message of the type ``VehicleConfigMsgPayload`` instead of an internal variable. Relevant example 
+  through a message of the type ``VehicleConfigMsgPayload`` instead of an internal variable. Relevant example
   scripts have been updated.
 - new tutorial example scenario script :ref:`scenarioTAMcomparison`
 - new mass sensor that converts a ``simulation`` mass properties message to a ``FSW`` vehicle configuration message :ref:`simpleMassProps`
@@ -518,13 +518,13 @@ Version 2.0.6
   using the above new MTB related modules to change the momentum, as well as drive the nominal momentum to
   a desired value using :ref:`rwNullSpace`.
 - created a new architecture based on ``BskSim`` called ``MultiSatBskSim``. It exploits the new messaging system to create a simulation
-  with any number of spacecraft in a highly modular way. It allows for the addition of homogeneous or heterogeneous satellites without 
+  with any number of spacecraft in a highly modular way. It allows for the addition of homogeneous or heterogeneous satellites without
   having to hard code their properties into a single dynamics or FSW script. It will be a foundation to test the upcoming multithreading
   capabilities of Basilisk.
-- added three example scenarios that showcase this new architecture. See :ref:`scenario_BasicOrbitMultiSat`, :ref:`scenario_AttGuidMultiSat` 
+- added three example scenarios that showcase this new architecture. See :ref:`scenario_BasicOrbitMultiSat`, :ref:`scenario_AttGuidMultiSat`
   and :ref:`scenario_StationKeepingMultiSat`.
 - added a new FSW module :ref:`formationBarycenter`. It computes the barycenter's position and velocity of a swarm of satellites. This barycenter
-  can be either computed with cartesian coordinates (usual mass-weighted average), or using orbital elements weighted average. Will be useful 
+  can be either computed with cartesian coordinates (usual mass-weighted average), or using orbital elements weighted average. Will be useful
   for spacecraft formations defined around the barycenter of the swarm and not a chief spacecraft.
 - enhanced :ref:`locationPointing` to support the target input msg being either a location message or an
   ephemeris message
@@ -558,7 +558,7 @@ Version 2.0.5
   two modules are connected
 - updated :ref:`gravityEffector` documentation to properly pull in the RST documentation and link to the
   PDF describing the gravity models
-- updated ``setAllButCurrentEventActivity`` method in :ref:`SimulationBaseClass` to work with multiple satellites. We can now add an index at the 
+- updated ``setAllButCurrentEventActivity`` method in :ref:`SimulationBaseClass` to work with multiple satellites. We can now add an index at the
   end of each event name that guarantees only events with the same index are affected. The ``useIndex`` flag must be set to ``True``.
 - added new magnetic torque bar effector in :ref:`MtbEffector`
 - added new FSW module to control the RW momentum using MTBs in :ref:`mtbMomentumManagement`
@@ -764,7 +764,7 @@ Version 2.0.0
 - updated ``spacecraftPlus`` to allow the attitude motion to be prescribed through
   an optional input message of type ``attRefMsg``.
 - fixed sign issue in :ref:`simpleSolarPanel`
-- support Vizard 1.6.0 scripting  
+- support Vizard 1.6.0 scripting
 
 
 
@@ -862,7 +862,7 @@ Version 2.0.0
   BSK messages.  For example, this allows :ref:`vizInterface` store the simulation data into a Vizard compatible manner.
 - Updated :ref:`spiceInterface` to allow for optional overriding the IAU planet frame with custom values
 - Updated :ref:`vizInterface` to allow setting ``show24hrClock`` and ``showDataRateDisplay`` flags for Vizard files
-  supported in Vizard v1.3.0 
+  supported in Vizard v1.3.0
 
 Version 1.7.4
 
@@ -1143,7 +1143,7 @@ simple and robust solution.
 
 -  added new tutorial on calling Python Spice functions within a Monte Carlo BSK simulation
 -  Added Keplerian Orbit utility class which is swig'd. This first implementation takes in elliptical orbit elements and can produce a range of related outputs like position, velocity, orbital period, etc.  This makes it easier to create Keplerian orbits within python.
--  Added a LimbFinding module for OpNav: limbFinding. This module performs a Canny transform to find the end of the planet and saves away the non-zero pixels for pose-estimation. 
+-  Added a LimbFinding module for OpNav: limbFinding. This module performs a Canny transform to find the end of the planet and saves away the non-zero pixels for pose-estimation.
 - made BSK compatible with both swig version 3 and 4
 
 .. raw:: html

docs/source/Vizard/vizardAdvanced/vizardSettings.rst

@@ -416,14 +416,14 @@ cones can be setup in Vizard, but can also be scripted from Basilisk
 using the helper function ``createConeInOut``:
 
 .. code-block::
-	
+
 	viz = vizSupport.enableUnityVisualization(scSim, simTaskName, scObject, saveFile=fileName)
 	vizSupport.createConeInOut(viz, toBodyName='earth', coneColor='teal',
                                normalVector_B=[1, 0, 0], incidenceAngle=30\ macros.D2R, isKeepIn=True,
                                coneHeight=5.0, coneName=‘sensorCone’)
 	vizSupport.createConeInOut(viz,toBodyName='earth', coneColor='blue', normalVector_B=[0, 1, 0],
                                incidenceAngle=30\ macros.D2R, isKeepIn=False, coneHeight=5.0, coneName=‘comCone’)]
-	
+
 The following table illustrates the
 arguments for the ``createConeInOut`` method:
 
@@ -1829,5 +1829,3 @@ the MSM radii are stored in the list ``rListDebris``.  The sample code is::
                                               , saveFile=fileName
                                               , msmInfoList=[msmInfoDebris]
                                               )
-
-

examples/BskSim/models/BSK_FormationDynamics.py

@@ -140,4 +140,3 @@ def InitAllDynObjects(self):
         self.SetSimpleNavObject()
         self.SetReactionWheelDynEffector()
         self.SetExternalForceTorqueObject()
-

examples/BskSim/models/BSK_SEPDynamics.py

@@ -19,7 +19,7 @@
 import numpy as np
 from Basilisk.utilities import (macros as mc, unitTestSupport as sp, RigidBodyKinematics as rbk, simIncludeRW)
 from Basilisk.simulation import (spacecraft, simpleNav, simpleMassProps, reactionWheelStateEffector,
-                                 ReactionWheelPower, boreAngCalc, spinningBodyOneDOFStateEffector, 
+                                 ReactionWheelPower, boreAngCalc, spinningBodyOneDOFStateEffector,
                                  spinningBodyTwoDOFStateEffector, thrusterStateEffector, facetSRPDynamicEffector)
 from Basilisk.architecture import messaging
 
@@ -168,8 +168,8 @@ def SetRotatingSolarArrays(self):
         self.RSAList[0].r_SB_B = [0.5 * 1.53, 0.0, 0.44]
         self.RSAList[0].r_ScS_S = [-0.036, 2.827, -0.469]
         self.RSAList[0].sHat_S = [0, 1, 0]
-        self.RSAList[0].dcm_S0B = [[0, 0, -1], 
-                                   [1, 0, 0], 
+        self.RSAList[0].dcm_S0B = [[0, 0, -1],
+                                   [1, 0, 0],
                                    [0, -1, 0]]
         self.RSAList[0].IPntSc_S = [[319.0, 0.0, 0.0],
                                     [0.0, 185.0, 0.0],
@@ -310,7 +310,7 @@ def SetSEPTrusterStateEffectors(self):
         self.SEPThruster1.kappaInit = messaging.DoubleVector([0.0])
         self.SEPThruster1.modelTag = "SEPThruster1"
         self.scObject.addStateEffector(self.SEPThruster1)
-        
+
         self.SEPThruster2.addThruster(thruster, self.platform2.spinningBodyConfigLogOutMsgs[1])
         self.SEPThruster2.kappaInit = messaging.DoubleVector([0.0])
         self.SEPThruster2.modelTag = "SEPThruster2"
@@ -387,4 +387,3 @@ def InitAllDynObjects(self, SimBase):
         self.SetInertialBoresight2(SimBase)
         self.SetSEPTrusterStateEffectors()
         self.SetFacetSRPDynamicEffector(SimBase)
-

examples/BskSim/scenarios/scenario_SEPPoint.py

@@ -102,7 +102,7 @@ def __init__(self, numberSpacecraft, prescribed):
             else:
                 scBodyList.append([self.DynModels[i].platform1.modelTag, self.DynModels[i].platform1.spinningBodyConfigLogOutMsgs[1]])
                 for j in range(self.DynModels[i].numRSA):
-                    scBodyList.append([self.DynModels[i].RSAList[j].modelTag, self.DynModels[i].RSAList[j].spinningBodyConfigLogOutMsg])                    
+                    scBodyList.append([self.DynModels[i].RSAList[j].modelTag, self.DynModels[i].RSAList[j].spinningBodyConfigLogOutMsg])
 
         # Enable Vizard
         viz = vizSupport.enableUnityVisualization(self, self.DynModels[0].taskName, scBodyList, saveFile=__file__)
@@ -267,7 +267,7 @@ def log_outputs(self):
                     self.AddModelToTask(DynModels[sc].taskName, self.platformRefAngleLogs[0])
                     self.platformRefAngleLogs.append(FswModels[sc].platform2ReferenceData.hingedRigidBodyRef2OutMsg.recorder(self.samplingTime))
                     self.AddModelToTask(DynModels[sc].taskName, self.platformRefAngleLogs[1])
-            
+
             if thrusterFlag == 1:
                 # log platform torques
                 if not self.prescribed:
@@ -395,7 +395,7 @@ def pull_outputs(self, show_plots, spacecraftIndex):
         T_F = [0, 0, 0.1]
         for i in range(len(dataCMLocation)):
             r_CM_B = r_BM_B + dataCMLocation[i]
-            
+
             if not self.prescribed:
                 theta1 = dataPlatformAngle[0][i]
                 theta2 = dataPlatformAngle[1][i]

examples/MultiSatBskSim/modelsMultiSat/BSK_MultiSatDynamics.py

@@ -183,7 +183,7 @@ def SetFuelTank(self):
         self.fuelTankStateEffector.r_TB_B = [[0.0], [0.0], [0.0]]
         self.tankModel.radiusTankInit = 1
         self.tankModel.lengthTank = 1
-        
+
         # Add the tank and connect the thrusters
         self.scObject.addStateEffector(self.fuelTankStateEffector)
         self.fuelTankStateEffector.addThrusterSet(self.thrusterDynamicEffector)

examples/OpNavScenarios/modelsOpNav/BSK_OpNavDynamics.py

@@ -369,7 +369,7 @@ def SetEphemConvert(self):
     def SetSimpleGrav(self):
         planet = self.gravFactory.createMarsBarycenter()
         planet.isCentralBody = True
-        
+
         self.gravFactory.addBodiesTo(self.scObject)
 
     # Global call to initialize every module
@@ -387,5 +387,3 @@ def InitAllDynObjects(self, SimBase):
         self.SetEphemConvert()
         self.SetCamera()
         self.SetCamera2()
-
-