Skip to content

简体中文

Python, Jupyter, and Engineering Computation

A computing environment should connect equations, data, plots, and conclusions in one executable chain. Python and Jupyter are common open choices, but the principles here—arrays, units, tests, locked environments, and stateless reruns—transfer to other numerical platforms.

Purpose and learning outcomes

  • Turn hand-derived equations into testable functions.
  • Separate raw data, cleaned data, derived results, and presentation figures.
  • Rerun a notebook from a clean kernel in a fixed order.
  • Preserve units, sampling conditions, and uncertainty in data and plots.
  • Export scripted results so conclusions do not exist only in interactive cells.

Minimal environment

  • A supported Python interpreter or equivalent numerical environment.
  • Package isolation and a textual dependency manifest.
  • A terminal that can execute scripts.
  • An optional Jupyter front end.
  • A small CSV measurement sample with time, voltage, and unit metadata.

Do not claim a tool is “the latest.” Record the interpreter, package, and operating-system versions you actually ran, and retain a machine-readable environment file.

Learning sequence

  1. Scalars to arrays: implement Ohm’s law and an RC response; inspect types, shapes, and units.
  2. Functions and tests: place computations in side-effect-free functions and assert known boundary values.
  3. Data entry: validate column names, missing values, monotonic time, and sampling intervals when reading raw files.
  4. Visualization: label axes with units and conditions; combine line style or markers with color.
  5. Notebook discipline: restart and run all; remove cells that depend on hidden state.
  6. Scripted exit: generate the result table, plot, and summary from raw input with one command.

Computation must not silently guess units. Use explicit variable names, metadata, or a units library, but normalize dimensions before entering an algorithm.

Verification task: estimate a time constant

Prepare a synthetic or safely measured RC step response:

  1. Generate synthetic data with a known time constant and fixed random seed.
  2. Write a reader that validates the time axis, units, and finite values.
  3. Estimate the time constant with two methods, such as a threshold and a fit.
  4. Report estimates, error, sample rate, and method assumptions.
  5. Plot data, fitted curve, and residuals with units on every axis.
  6. Clear outputs and run from the beginning; confirm stable summaries and file checksums.

Acceptance should include a numerical tolerance. For example, the estimate must remain within a declared error bound, and deliberately breaking a column name must make a test fail.

Common failures and diagnosis

  • The notebook works only out of order: restart and run all; move shared logic into a module.
  • Array shapes broadcast silently: assert dimensions at function boundaries and compare a small case by hand.
  • The plot looks plausible but units are wrong: trace every scale factor and normalize SI prefixes before computing.
  • A fit converges to a nonphysical result: inspect initial values, bounds, residuals, and parameter identifiability.
  • Results change across machines: lock dependencies, random seeds, locale, and input files.
  • Large files exhaust memory: read in chunks, profile the data first, and avoid copying full arrays.

Reproducible evidence

  • Environment manifest and observed version snapshot.
  • Read-only raw data with provenance and checksum.
  • A tested computation module.
  • A notebook or script that runs from the beginning.
  • A generated-artifact directory and one rebuild command.
  • Decisions about outliers, missing values, filtering, and fitting.
  • Numerical tolerances, random seeds, and platform-difference notes.

Cost, licensing, and accessibility

The exercise can be completed locally with free software. Record package licenses, and do not bundle restricted data or paid course material into an environment. A low-memory device may use fewer samples while preserving the algorithm and acceptance criteria.

Give notebooks a clear heading hierarchy and textual conclusions. Do not make output depend only on color or hover interactions. Provide a script entry point and static export so screen-reader users, low-bandwidth learners, and reviewers without the front end can understand the result.

Safety boundaries

  • Unknown notebooks and dependencies can execute arbitrary code; inspect them in an isolated environment.
  • Do not expose device secrets, patient information, or identifiable measurements in cell output.
  • Automated acquisition scripts need timeouts, ranges, and stop conditions.
  • Software results do not replace rating and facility review for higher-energy hardware.
  • A numerical fit is not a safety conclusion; clearly label extrapolation beyond observed data.

Completion checklist

  • A clean environment can install and run the project.
  • Every core equation lives in a testable function.
  • Raw data, derived data, and plots are separated.
  • Every field and plot axis has a unit.
  • The notebook runs sequentially from a clean kernel.
  • A deliberate error triggers an explicit failure.
  • One command rebuilds the summary, result table, and plots.
  • Licenses, data provenance, random seeds, and limits are recorded.

Next, use Data and Laboratory Records to design acquisition metadata, or Reproducible Engineering to add the computation to automated checks.