MNT: updates paths after refactoring the data folder

README.md

@@ -161,7 +161,7 @@ env = Environment(
     latitude=32.990254,
     longitude=-106.974998,
     elevation=1400,
-) 
+)
 
 tomorrow = datetime.date.today() + datetime.timedelta(days=1)
 
@@ -182,7 +182,7 @@ A sample Motor object can be created by the following code:
 
 ```python
 Pro75M1670 = SolidMotor(
-    thrust_source="data/motors/Cesaroni_M1670.eng",
+    thrust_source="data/motors/cesaroni/Cesaroni_M1670.eng",
     dry_mass=1.815,
     dry_inertia=(0.125, 0.125, 0.002),
     center_of_dry_mass_position=0.317,
@@ -215,8 +215,8 @@ calisto = Rocket(
     radius=0.0635,
     mass=14.426,  # without motor
     inertia=(6.321, 6.321, 0.034),
-    power_off_drag="data/calisto/powerOffDragCurve.csv",
-    power_on_drag="data/calisto/powerOnDragCurve.csv",
+    power_off_drag="data/rockets/calisto/powerOffDragCurve.csv",
+    power_on_drag="data/rockets/calisto/powerOnDragCurve.csv",
     center_of_mass_without_motor=0,
     coordinate_system_orientation="tail_to_nose",
 )

docs/development/rocketpy_as_developer.rst

@@ -16,13 +16,13 @@ Go into the cloned repository folder by typing on a terminal
 Open your preference editor by typing on a terminal
 
 .. code-block:: console
-    
+
     <editor name> .
 
 For example, to open VS Code type on terminal
 
 .. code-block:: console
-    
+
     code .
 
 Alternatively, you can open the folder directly through your editor's interface.
@@ -45,7 +45,7 @@ To create the folder, type on the terminal:
 And, to add it on .gitignore, type:
 
 .. code-block:: console
-    
+
     echo <folder name>/ >> .gitignore
 
 It is important to remember that all the files inside this folder will not be included in any commit so, if it is important to the solution, do not add them inside it.
@@ -57,7 +57,7 @@ Importing the RocketPy files
 ----------------------------
 
 First, create a python (or .ipynb) file to make the simulation.
-To ensure you are using the local files and not the files as a python package (if you installed the library via pip for example), add 
+To ensure you are using the local files and not the files as a python package (if you installed the library via pip for example), add
 
 .. code-block:: python
 
@@ -66,15 +66,15 @@ To ensure you are using the local files and not the files as a python package (i
 Alternatively you can use the following command to pip install the local library:
 
 .. code-block:: console
-    
+
     import sys
     sys.path.append('../') # if you are using a notebook
     sys.path.append('../rocketpy') # if you are using a script
 
 Import the classes that will be used, in case:
 
 .. code-block:: python
-    
+
     from rocketpy import Environment, SolidMotor, Rocket, Flight, Function
 
 If it is the first time you are using rocketpy and you do not have all required libraries installed, you could use the command:
@@ -99,7 +99,7 @@ It contains information about the local pressure profile, temperature, speed of
 
     env = Environment(latitude=32.990254, longitude=-106.974998, elevation=1400)
 
-RocketPy can use local files via the Ensemble method or meteorological forecasts through OpenDAP protocol. 
+RocketPy can use local files via the Ensemble method or meteorological forecasts through OpenDAP protocol.
 To work with environment files, it will be very important ensuring tha that you have the netCDF4 library installed.
 Assuming we are using forecast, first we set the simulated data with:
 
@@ -122,14 +122,14 @@ Weather forecast data can be visualized through two info methods.
 Creating the motor that boosts the rocket
 -----------------------------------------
 
-Now we need to create the motor. 
+Now we need to create the motor.
 For example, we will use a solid motor called Pro75M1670, but other configurations are also possible.
 The motor class contains information about the thrust curve and uses some geometric parameters to calculate the mass variation over time, as well as the total thrust and other important outputs.
 
 .. code-block:: python
 
     Pro75M1670 = SolidMotor(
-        thrust_source="../data/motors/Cesaroni_M1670.eng", #copy here the path to the thrust source file
+        thrust_source="../data/motors/cesaroni/Cesaroni_M1670.eng", #copy here the path to the thrust source file
         burn_time=3.9,
         grain_number=5,
         grain_separation=5 / 1000,
@@ -160,8 +160,8 @@ The first step is to initialize the class with the vital data:
         mass=19.197 - 2.956,
         inertia_i=6.60,
         inertia_z=0.0351,
-        power_off_drag="../../data/calisto/powerOffDragCurve.csv",
-        power_on_drag="../../data/calisto/powerOnDragCurve.csv",
+        power_off_drag="../../data/rockets/calisto/powerOffDragCurve.csv",
+        power_on_drag="../../data/rockets/calisto/powerOnDragCurve.csv",
         center_of_dry_mass_position=0,
         coordinate_system_orientation="tail_to_nose",
     )
@@ -171,7 +171,7 @@ The first step is to initialize the class with the vital data:
 Then the rail buttons must be set:
 
 .. code-block:: python
-    
+
     calisto.set_rail_buttons(0.2, -0.5)
 
 In sequence, the aerodynamic surfaces must be set.

docs/development/testing.rst

@@ -2,13 +2,13 @@ Testing Guidelines
 ==================
 
 This page describes the testing philosophy used throughout RocketPy's
-development with pytest. That includes the definition 
+development with pytest. That includes the definition
 and some technical discussion regarding:
 
 * Testing philosophy and style
 * Testing naming conventions
 * Directory structure
-* Unit tests definition 
+* Unit tests definition
 * Integration tests definition
 * Acceptance tests definition
 
@@ -21,7 +21,7 @@ First of all, it is worth noting the role of tests within the framework of Rocke
 
 * Unit tests are the minimum requirement for a feature to be accepted.
 
-That is, for each feature must correspond a testing unit which properly documents and tests the newly implemented feature. 
+That is, for each feature must correspond a testing unit which properly documents and tests the newly implemented feature.
 In even more practical terms that means the Pull Request containing the feature should include an unit test together with it.
 
 Testing Naming Conventions
@@ -48,7 +48,7 @@ RocketPy Team agreed upon following the testing convention where it's name exact
 * ``test_methodname_stateundertest``
 * ``test_methodname_expectedbehaviour``
 
-However, in any case, it is of utmost importance that the expected behaviour or state to be tested 
+However, in any case, it is of utmost importance that the expected behaviour or state to be tested
 **should be included within the docstring of the test**, just as illustrated below by the docstring
 of the same test:
 
@@ -66,7 +66,7 @@ of the same test:
 
 Do not get caught by the size of that docstring. The only requirements it has to satisfy is
 that the docstring contains precise information on the expected behaviour and/or behaviour
-to be tested. 
+to be tested.
 
 Directory Structure
 -------------------
@@ -93,14 +93,14 @@ RocketPy organizes its tests as follows:
             └── stochastic_file_2.py
 
 As one might guess, each kind of test should be included within it's correspondent kind of test. For instance, if one is writing
-an unit testing module called ``test_flight.py``, it should be included within the ``unit`` folder. The same holds for other tests. 
+an unit testing module called ``test_flight.py``, it should be included within the ``unit`` folder. The same holds for other tests.
 For a more detailed treatment of the directory containing the fixtures, read the next section.
 
 Fixtures
 --------
 
 Fixtures play a significant role within testing. In RocketPy it is no different. In fact, so many features are needed
-to properly test the code that the RocketPy Team decided to organize them a little different then one might find in 
+to properly test the code that the RocketPy Team decided to organize them a little different then one might find in
 small projects. The directory is structured as follows:
 
 ::
@@ -123,10 +123,10 @@ small projects. The directory is structured as follows:
 
 Rocketpy Team opted for this kind of structure since it allowed for a more convenient way of organizing
 fixtures. Additionally, it serves the purpose of putting the tests in a position where only strictly needed
-fixtures are imported. 
+fixtures are imported.
 
-**Important:** If a new module containing fixtures is to be created, do not forget to look for the 
-``conftest.py`` file within the tests folder to include your newly created module. 
+**Important:** If a new module containing fixtures is to be created, do not forget to look for the
+``conftest.py`` file within the tests folder to include your newly created module.
 
 To finish, let's take a quick look inside the tests directory structure. Consider the **motor**
 folder containing its fixtures:
@@ -150,16 +150,16 @@ Unit tests definition
 ---------------------
 
 Within a complex code such as RocketPy, some definitions or agreements need to be reviewed or sophisticated
-to make sense within a projec. In RocketPy, unit tests are/can be **sociable**, which **still** means that:
+to make sense within a project. In RocketPy, unit tests are/can be **sociable**, which **still** means that:
 
 * (Speed) They have to be **fast**.
 * (Isolated behavior) They focus on a **small part** of the system. Here we define unit in the method-level.
 
 *However*, as already said, they are/can be sociable:
 
 * (Sociable) The tested unit relies on other units to fulfill its behavior.
- 
-The classification depends on whether the test isolates the unit under test from its dependencies or allows them 
+
+The classification depends on whether the test isolates the unit under test from its dependencies or allows them
 to interact naturally. In practical terms, consider the test:
 
 .. code-block:: python
@@ -175,16 +175,16 @@ to interact naturally. In practical terms, consider the test:
         """
         assert isinstance(calisto_motorless.evaluate_total_mass(), Function)
 
-This test is **sociable** because it relies on the actual Rocket instance and tests its real behavior without 
-isolating the Rocket class from its potential interactions with other classes or methods within its implementation. 
-It checks the real implementation of ``evaluate_total_mass`` rather than a mocked or stubbed version, ensuring that 
+This test is **sociable** because it relies on the actual Rocket instance and tests its real behavior without
+isolating the Rocket class from its potential interactions with other classes or methods within its implementation.
+It checks the real implementation of ``evaluate_total_mass`` rather than a mocked or stubbed version, ensuring that
 the functionality being tested is part of the integrated system.
 
 Please note that writing an unit test which is solitary is allowed, however: make sure to back it up with proper contract
-tests when applicable. 
+tests when applicable.
 
 The classification regarding solitary and sociable tests was clarified due to the specific needs developers
-naturally encountered within the software, while also hoping that since the developers had the need to further 
+naturally encountered within the software, while also hoping that since the developers had the need to further
 identify them, external contributors would probably fall into the same problem.
 
 Integration tests definition
@@ -235,28 +235,28 @@ The motivation behind lies in the fact that it interacts and calls too many meth
 to be considered an unit test.
 
 Please be aware that Integration tests are not solely classfied when interacting with external dependencies,
-but also encompass verifying the interaction between classes or too many methods at once, such as ``all_info()``. 
+but also encompass verifying the interaction between classes or too many methods at once, such as ``all_info()``.
 
 Further clarification: Even if the test contains traits of unit tests and use dependencies which are stable, such as
-.csv or .eng files contained within the project or any other external dependencies which are easy to access 
-and do not make the test slow, **then your test is still an integration test, since those are strongly I/O related.** 
+.csv or .eng files contained within the project or any other external dependencies which are easy to access
+and do not make the test slow, **then your test is still an integration test, since those are strongly I/O related.**
 
 Acceptance tests definition
 ---------------------------
 
 Acceptance tests configure the final phase of the testing lifecycle within RocketPy. These tests are designed to
-account for user-centered scenarios where usually real flights and configurations are setup and launched. 
+account for user-centered scenarios where usually real flights and configurations are setup and launched.
 
-This phase of testing presents the task of letting the developers know if the system still satisfies well enough the 
+This phase of testing presents the task of letting the developers know if the system still satisfies well enough the
 requirements of normal use of the software, including for instance:
 
 * Error free use of the software within the setup of a real launch.
 * Assertions regarding the accuracy of simulations. Thresholds are put and should be checked. RocketPy Paper results are a good reference.
-* Usually include prior knowledge of real flight data. 
+* Usually include prior knowledge of real flight data.
 
 In practical terms, acceptance tests come through the form of a notebook where a certain flight is tested.
-It is an important feature and also defining feature of the acceptance tests that thresholds are compared 
-to real flight data allowing for true comparison. 
+It is an important feature and also defining feature of the acceptance tests that thresholds are compared
+to real flight data allowing for true comparison.
 
 Docstrings
 ----------