Skip to content

Feature/propulsion design empirical engine

Implementation of empirical engine approach as low fidelity propulsion design method.

Description

New empirical engine design branch.Implements a new low fidelity method for propulsion design based on empirical methods (Mattingly or Herrmann/Torenbeek). In contrast to the rubber method, where engine decks are scaled from Gasturb or other sources, the engine decks are generated directly in this approach. Since the Gasturb decks are generally too detailed for use in the preliminary design phase, and because not all decks can be easily reproduced using empirical methods, the selection is reduced to five key parameters: fuel flow, core mass flow, total mass flow, and thrust. The TSFC is also provided but serves mainly as a plausibility check, as it is not required by the engine library. Once an engine deck has been generated, the rubber approach should be used for the previously created decks in subsequent iterations. That means: in the first iteration, an engine deck is created; in the second iteration, it is checked whether the engine already exists. If this is the case, the engine stored in the corresponding directory is scaled. The engine efficiency factor can be applied to the empirical engine in the same way as to the conventional Gasturb decks.

Other Changes

  • Important: Use new engine library (branch: feature/remove_all_limits) and also merge the corresponding merge request: libraries!61

Screenshots/Logs

Attach screenshots or log outputs if applicable.

Testing Instructions

  1. Check locally a) Check in first iteration: engine folder with empirical engine name defined in config file is created. Check if report is fully generated and results look plausible. b) Run propulsion_design again and check if rubber approach is used. For this no changes in the config file or any other file have to be made. Check if report is fully generated and results look plausible.
  2. Check in workflow

Developer Checklist

  • Code has been tested locally and/or in pipeline.
  • (if applicable) documentation updated.
  • (if applicable) impact of new dependencies reviewed and included in project.
  • Merge conflicts resolved with the target branch.

Additional Notes

Add any information reviewers should focus on, e.g., specific files, functions, or changes of interest.

Edited by Maren Stolte

Merge request reports

Loading