Merge branch 'develop' into mnt/tank-cad-testing

.github/clear-local-branches.ps1

@@ -0,0 +1,2 @@
+# Delete local branches that no longer exists on remote (windows command line)
+git branch -vv | Where-Object { $_ -match 'gone\]' } | ForEach-Object { $_.Trim().Split()[0] } | ForEach-Object { git branch -D $_ }

.vscode/settings.json

@@ -5,12 +5,14 @@
     "python.testing.unittestEnabled": false,
     "python.testing.pytestEnabled": true,
     "autoDocstring.docstringFormat": "numpy",
-    "cSpell.enableFiletypes": [
-        "python",
-        "jupyter",
-        "markdown",
-        "restructuredtext"
-    ],
+    "cSpell.enabledFileTypes": {
+        "plaintext": true,
+        "python": true,
+        "jupyter": true,
+        "markdown": true,
+        "tex": true,
+        "rst": true
+    },
     "cSpell.language": "en-US",
     "cSpell.words": [
         "Abdulklech",

CHANGELOG.md

@@ -40,9 +40,11 @@ Attention: The newest changes should be on top -->
 ### Changed
 
 - MNT: Refactor Tank's testing Assertion with CAD data. [#678](https://github.com/RocketPy-Team/RocketPy/pull/678)
+- MNT: Place filename save parameter to the end. [#739](https://github.com/RocketPy-Team/RocketPy/pull/739)
 
 ### Fixed
 
+- BUG: Allow multiple sets of stochastic fins [#737](https://github.com/RocketPy-Team/RocketPy/pull/737)
 - BUG: forecast and reanalysis models - Update ECMWF dictionary values [#736](https://github.com/RocketPy-Team/RocketPy/pull/736)
 - BUG: forecast and reanalysis models - move wind_speed to correct position [#735](https://github.com/RocketPy-Team/RocketPy/pull/735)
 - BUG: Sideslip Angle and Damping Coefficient Calculation [#729](https://github.com/RocketPy-Team/RocketPy/pull/729)

docs/conf.py

@@ -40,6 +40,7 @@
     "sphinx.ext.napoleon",
     "sphinx.ext.viewcode",
     "sphinx.ext.mathjax",
+    "sphinx_tabs.tabs",
     "sphinx_copybutton",
     "sphinx_design",
     "jupyter_sphinx",

docs/development/build_docs.rst

@@ -31,64 +31,67 @@ requirements that are needed to run the sphinx generator.
 All these requirements are listed in the ``requirements.txt`` file inside the
 ``docs`` folder.
 
-To install the requirements, navigate the terminal to the ``docs`` folder and
-run the following command:
+The easiest way to install the requirements and build the documentation is by
+RocketPy's ``Makefile`` command:
 
 .. code-block:: bash
-    
-    pip install -r requirements.txt
 
-After installing the requirements, you can build the documentation by running
-the following command in your terminal:
+    make build-docs
 
-.. code-block:: bash
-    
-    make html
+This command will install the requirements and generate the documentation in the
+``docs/_build/html`` folder.
+
+.. note::
 
-The file named ``Makefile`` contains the commands to build the documentation.
-The ``make html`` command will generate the documentation in the ``docs/_build/html``
-folder.
+    This requires the ``make`` command to be available in your system. Check out
+    GNU Make documentation on how to install it.
 
 To see the documentation, open the ``docs/_build/html/index.html`` file in your
 browser.
 
-.. note:: Watch out for any warnings or errors that may appear in the terminal
-          when building the documentation. If you find any, fix them before
-          pushing the changes to the repository or at least warn the team about
-          them.
+.. important:: 
+
+    Watch out for any introduced warnings or errors that may appear in the terminal
+    when building the documentation. If you find any, fix them before
+    pushing the changes to the repository or at least warn the team about
+    them.
 
 Sometimes you may face problems when building the documentation after several
-times of building it.
-This may happen because sphinx does not clean the ``docs/_build`` folder before
-building the documentation again.
-To clean the ``docs/_build`` folder, run the following command in your terminal:
+times of building it. This may happen because sphinx does not clean the ``docs/_build``
+folder before building the documentation again.
+
+One can use the internal Makefile inside the ``docs`` folder generated by sphinx
+to have specific commands to build and clean the documentation.
+
+To clean the ``docs/_build`` folder, run the following commands in your terminal:
 
 .. code-block:: bash
 
+    cd docs/
     make clean
 
 After cleaning the ``docs/_build`` folder, you can build the documentation again
-by running the ``make html`` command.
+by going back to rocketpy root directory and using the ``make build-docs`` command
+described above.
 
 If the error persists, it may be related to other files, such as the ``.rst``
 files or the ``conf.py`` file.
 
 .. danger::
 
-    Do not modify the Makefile or the ``make.bat`` files. These files are \
-    automatically generated by sphinx and any changes will be lost.
+    Do not modify sphinx internal Makefile or the ``docs/make.bat`` files. 
+    These files are automatically generated by sphinx and any changes will be lost.
 
 
 How to integrate the documentation with ReadTheDocs
 ---------------------------------------------------
 
 The documentation is automatically built and hosted by `ReadTheDocs`.
-Every time a commit is pushed to the repository, `ReadTheDocs` will build the
-documentation and host it automatically. 
-This includes other branches besides the master branch.
-However, the documentation will only be available for the master branch, and you
-need to configure the `ReadTheDocs` project to build the documentation for other
-branches.
+Every time a commit is pushed to selected branches of the repository (such as `master` and `develop`), 
+`ReadTheDocs` will build the documentation and host it automatically. 
+
+However, custom branches need to be manually added. If you need to have your branch
+available on `ReadTheDocs`, ask to a maintainer for help.
 
 The connection between the GitHub repository and the `ReadTheDocs` project is
 already configured and defined in the ``readthedocs.yml`` file, available at the

docs/development/conflicts.rst

@@ -0,0 +1,123 @@
+Solving Git Conflicts
+=====================
+
+What Are Git Conflicts?
+-----------------------
+
+Git conflicts occur when Git is unable to automatically merge changes made to the \
+same lines of code or when changes overlap in a file across branches.
+This often occurs in RocketPy repository when two developers make changes to the same \
+file and try to merge them.
+In this scenario, Git pauses the operation and marks the conflicting files, \
+requiring manual intervention.
+
+Merge vs Rebase
+---------------
+
+**Merge**
+
+The ``merge`` operation combines the changes from one branch into another. \
+It creates a new commit that marks the merging of the two branches together.
+
+* Retains the full history of both branches.
+* Non-linear history shows how changes were combined.
+* The history can become cluttered if there are many branches, due to the number of merge commits.
+
+**Rebase**
+
+The ``rebase`` operation integrates changes from one branch into another by reapplying \
+the commits on top of the target branch. It results in a more linear history.
+
+* Produces a cleaner, linear commit history.
+* Easier to follow the sequence of changes.
+* Can rewrite history, leading to potential issues when working on shared branches.
+
+Example Commands
+----------------
+
+Let's consider a common scenario from which conflicts can arise:
+updating a feature branch with the latest changes from the branch it was created.
+Both ``merge`` and ``rebase`` can be used to update the feature branch.
+However, the ``rebase`` option is highly recommended to keep a more linear history.
+
+Merge
+~~~~~
+
+Suppose you have two branches, ``enh/feature`` that was branched off ``develop``.
+It is likely that ``develop`` has been updated since you branched off ``enh/feature``, \
+therefore before merging ``enh/feature`` into ``develop``, you should update ``enh/feature`` \
+with the latest changes from ``develop``.
+
+One way to do this is by merging ``develop`` into ``enh/feature`` as follows:
+
+.. code-block:: console
+
+    git checkout develop
+    git pull
+    git checkout enh/feature
+    git merge develop
+
+If there are conflicts, Git will pause the operation and mark the conflicting files. \
+VS Code provides a visual interface to resolve these conflicts in the **Merge Editor**.
+If you want to abort the merge, you can use ``git merge --abort``.
+
+Rebase
+~~~~~~
+
+Similarly, another way to update ``enh/feature`` with the latest changes from ``develop`` \
+is by rebasing ``enh/feature`` onto ``develop`` as follows:
+
+.. code-block:: console
+
+    git checkout develop
+    git pull
+    git checkout enh/feature
+    git rebase develop
+
+Differently from merge, if there are conflicts, they must be resolved commit by commit. \
+After resolving each step conflicts, you can continue the rebase with ``git rebase --continue``. \
+If you want to abort the rebase, you can use ``git rebase --abort``.
+
+When to Use Merge or Rebase
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Generally, the maintainers will inform you which operation to use when merging your PR. \
+Notice that there is no wrong way to merge branches, but ``rebase`` is usually preferred \
+to keep a more linear history.
+
+Furthermore, it is important to avoid letting conflicts accumulate, since they can become \
+harder to resolve. It is recommended to update your feature branch frequently with the latest \
+changes from the branch it was branched off.
+
+Solving Conflicts
+-----------------
+
+When conflicts arise, Git marks the conflicting files. The file will contain markers like:
+
+.. code-block:: console
+
+    <<<<<<< HEAD
+    Current branch changes
+    =======
+    Incoming branch changes
+    >>>>>>> branch-name
+
+The ``HEAD`` section contains the changes from the current branch, while the ``branch-name`` section \
+contains the changes from the incoming branch.
+The ``=======`` line separates the two sections.
+One can manually edit the file to resolve the conflict, removing the markers and keeping the desired changes, however \
+for convenience it is recommended to use a visual tool like the *Merge Editor* in VS Code.
+
+Resolving Conflicts in VS Code
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When a conflict occurs, VS Code will open the *Merge Editor* to help you resolve it.\
+
+1. Open the conflicting file (marked with a ``!``).
+2. The *Merge Editor* will show the conflicting sections side by side.
+3. Click on the ``Accept Current Change`` or ``Accept Incoming Change`` buttons to keep the desired changes, sometimes both changes will be kept or even a manual edit will be necessary.
+
+More details on VS Code interface and conflict solver can be found in `VS Code Docs <https://code.visualstudio.com/docs/sourcecontrol/overview#_3way-merge-editor>`_.
+After resolving the conflicts, save the files, make sure all conflicts are resolved, and then \
+commit the changes.
+