...the data schema for the carculator (compare the carculator/data/default_parameters.json) is:

unique_id
  name
  year
  powertrain
  sizes
  (data)
  (metadata)

This is already reasonably abstract. For aircraft, we could simply change some of the field names:

The way I understand, the powertrain field already allows to "combine" powertrains (eg. hybrid-electric), by listing them as separate categories.

In aircraft, Hydrogen could be used by:

1. directly burning it in the turbine
2. convert it to electricity in a fuel cell

We could use the carculator powertrain logic to describe these cases as:

"propulsion" = "hydrogen-fuelcell"
"propulsion" = "hydrogen-gasturbine"
"propulsion" = "liquidfuel"
"propulsion" = "liquidfuel-hybrid-batteryelectric"

It might make sense to merge the design-concept into this descriptor also:

"propulsion-design" = "liquidfuel-hybrid-batteryelectric-blendedwingbody"

@romainsacchi, is this a good way to describe aircraft typologies?

The "data ingestion pipeline" should be built to perform these tasks:

1. Ingest a JSON file, containing parameters (according to the schema defined in #7)
2. Output a 4-dimensional xarray, containing the dimensions (pax, propulsion, year, parameters).
3. Output a tuple of data structures, containing the unique values of the 4 dimensions (pax, ...)

In addition, the following utility functionality should be built:

1. Check for input data validity (valid JSON? corresponding to defined schema?)
2. logging outputs in every function, including statistics (eg. file loaded, read 778 unique parameters)

In the process of setting vehicle parameters, the carculator attempts to design optimally sized cars from scratch.
It does so using an iterative approach:

while diff > 0.00001:
  old_driving_mass = self["driving mass"].sum().values
  self.set_vehicle_mass()
  self.set_power_parameters()
  (...)
  diff = (self["driving mass"].sum().values - old_driving_mass) / self[
      "driving mass"
  ].sum()

The iterative approach is required because (highly simplified) vehicle parameters are interdependent:

weight(power) and power(weight)

For each vehicle size class, it assumes a starting value for weight/power is provided. The interdependent vehicle parameters are then solved for iteratively.

In contrast, "sizing" aircraft from scratch is unlikely to be a viable approach. Sizing aircraft is a complex undertaking that needs to account for many business parameters that we could not hope to capture. For instance, while an Airbus A380 in all-economy seating configuration would have excellent fuel efficiency/pax, industry now considers the very concept a failure.

It would therefore be prudent to use aircraft parameters from existing proposals (such as the MIT D8 Concept), where all these considerations have already been considered.

@julienmctighe found similar approaches in literature (email from 19.01.2024):

After a quick review of studies with sensitivity analysis, I agree it may be difficult to size aircraft up or down in seating capacity. Most treat seating capacity as fixed and report sensitivity to technology assumptions (LH2 tank efficiency, FC energy density) or design decisions (tank location, material, vent pressure). I have included two examples below.

Onorato 2022 - https://doi.org/10.1007/s13272-022-00601-6
Design decisions (see Section 4 Results)

Karpuk 2023 - https://doi.org/10.3390/aerospace10060566
Technology sensitivity (see Section 4.2.3. Technology Sensitivity of Hydrogen BWB Aircraft)

It therefore seems that we need to have not a "sizing" function, but a "weight and balance"
calculation function. This function would compute the fuel required per trip:

def calculate_fuel(distance: int, payload: int, mtow: int, maxfuelweight: int) -> float:
   (...)
   return fuel_weight

The data ingestion pipeline must be documented (in the EcoPylot Sphinx documentation pages) before we start to implement

• #6

This documentation will then serve as the technical specification of the data ingestion pipeline.

Ideally, this would include:

• sample data (input/output)
• a Mermaid diagram, if applicable
• a short explanation of our choices behind the logic

I would suggest we use Mermaid (in Markdown/Sphinx) to render the diagram. As a first step, a Data Flow Diagram¹² should suffice. Instead of a prose description like:

The main module model.py builds the vehicles and delegates the calculation of motive and auxiliary energy, noise, abrasion and exhaust emissions to satellite modules. Once the vehicles are fully characterized, the set of calculated parameters are passed to inventory.py which derives life cycle inventories and calculates life cycle impact indicators. Eventually, these inventories can be passed to export.py to be exported to various LCA software.

We could have an interactive diagram linking to the different modules. The biggest pain-point in working with (LCA) research software is the input/output data, and much less the internal architecture of the program.

@julienmctighe found this project:

• genericairplanemodel (GitLab)

which might be useful to (at least some sub-part) of our project.

The example Excel sheet and the corresponding Jupyter notebook provided by @romainsacchi in a168525 should be updated and integrated into the documentation.

...with the merge of #15 and #18, the basics of the data ingestions pipeline are in place. All publicfunctions are documented on the readthedocs.org page. Private functions are documented using extensive docstrings.

Please provide a sample Excel sheet (along the lines of the Carculator-derived dev/other/Input data_bus.xlsx.

This will help me write unit/integration test further down the line.

It would be ideal if the file contained enough information to complete a simple calculation for a basic (fossil-fuel-driven?) aircraft.

Try:

4 dimensions (eg. parameter, time, size, prop)
8 dimensions (eg. parameter, time, size, prop1, prop2, prop3, prop4, prop5)

and determine size (in memory) and performance when eg. slicing the array.

See also:

• pydata/xarray#3206
• pydata/xarray#3213
• pydata/xarray#6683

The structure of the Excel model

https://zenodo.org/records/8059751

from

Sacchi, R., Becattini, V., Gabrielli, P., Cox, B., Dirnaichner, A., Bauer, C., & Mazzotti, M. (2023). How to make climate-neutral aviation fly. Nature Communications, 14(1), 3989. https://doi.org/10.1038/s41467-023-39749-y

should be documented in order to investigate the potential of knowledge transfer to EcoPylot.

...as soon as we have some code 😎

...using the great work @michaelweinold has already put into brightway-lca/brightway-documentation.