Hello, dear friend, you can consult us at any timeif you have any questions, add WeChat: daixieit

EGS Individual Coursework

March 11, 2026

Abstract

This coursework asks you to build and justify an energy system model, translate it into a computational pipeline, and produce defensible results supported by verification and visualisation. You may implement using self programming or AI-assisted “vibe coding”. The assessed outcome is not the programming language or the amount of code, or even your simulation results are correct or not. The assessed outcome is your modelling clarity (formulation to coding), explainability, verification evidence, and your analysis and insights. If you use any AI assistance, you must include an AI usage statement (Section 6); missing this statement triggers a mark cap.

1 Coursework Overview

You will choose one case study from Section 4 and develop a working model based on the provided datasets. The primary focus of this coursework is on formalising the problem into a mathematical model, writing verifiable code, and building engineering insights.

For your chosen case, your workflow must include:

• Model formulation: Define the system mathematically (variables, equations, constraints, and objective or control policy).

• Code implementation: Translate your mathematical model into a robust computational pipeline (data in, model run, results out).

• Verification: Construct explicit, mathematical checks proving your code adheres to physical laws (e.g., energy balance, bounds, unit consistency).

• Insight generation: Analyse your results to build engineering insights with clear visualisations and interpretation.

Compulsory AI usage statement (mark cap). If you use any AI tool at any stage (code, writing, debugging, or analysis), you must include the AI usage statement in Section 6. If it is missing or materially incomplete, your coursework mark will be capped at 40%.

Base marks and extension marks. The coursework is designed with a set of base requirements i.e., base case, up to 90% of the marks. You then choose one or more extensions to earn the remaining 10% of the marks, giving a maximum total of 100%.

Programming language and tools. Any language is allowed (MATLAB, Python, etc.). Any libraries are allowed if you justify them and your results remain reproducible. AI assistance is allowed if you document it (Section 6).

2 Learning Outcomes

By the end of this coursework you should be able to:

• formulate an energy system problem as a model with variables, constraints, and objectives,

• build a simulation and optimisation pipeline from dataset to verified outputs,

• perform verification checks that catch silent mistakes (energy balance, bounds, unit consistency) and ensure alignment with the modelling objectives,

• communicate results using figures and concise engineering interpretation,

• use AI assistance responsibly, if you choose, without sacrificing verification or understanding.

3 Datasets Provided (Download Pack)

A dataset pack is provided as a ZIP file containing several CSV files. All datasets are synthetic time series designed for coursework.

3.1 Files in the dataset pack

Table 1 summarises what you have available. You will normally use the files associated with your chosen case study.

File name	What it contains
caseA_smart_home_30min_summer.csv	30 days at 30 minute resolution: PV (kW), base load (kW), import tariff (GBP/kWh), export price (GBP/kWh), ambient temperature (C). caseA_ev_events.csv One EV charging requirement per day: arrival time, departure time, required energy (kWh), max charge power (kW). Used only if you choose the EV extension.
caseA_smart_home_30min_winter_optional.csv	14 days at 30 minute resolution with an extra column: space heating demand proxy (kW thermal). Used only if you choose a heating extension.
caseB_grid_battery_market_hourly.csv	60 days at hourly resolution: day ahead price (GBP/MWh), imbalance price (GBP/MWh), ancil lary availability payment (GBP/MW/h), optional carbon intensity (kg/kWh).
caseC_community_microgrid_hourly.csv	14 days at hourly resolution: PV (kW), three loads (kW), import tariff (GBP/kWh), export price (GBP/kWh).
caseD_moon_base_hourly.csv	1418 hours at hourly resolution over 2 lunar synodic cycles: solar irradiance (W/m2 ), PV profile per kWp, subsystem demands (life support, thermal, comms, lighting, science, galley), total demand (kW), surface temperature (C).

Table 1: Dataset files provided in the coursework pack. See the included README.txt for full details and unit notes.

4 Choose One Case Study

Pick one case study below. Your report must clearly state which case you chose and which dataset files you used.

In each case study, it will likely require some exploration of the case to build your understanding and explore any missing assumptions required to solve the problem. The way to solve it is open ended, and we assess the formulation, explainability, evidence-based verification, and engineering insights.

4.1 Case A: Smart Home Energy Management (PV + Battery)

The Problem. Using caseA_smart_home_30min_summer.csv, build a model that manages energy flows between PV generation, household electrical load, battery storage, and grid import/export under time-varying tariffs. You must implement and compare at least two dispatch policies (e.g., a simple self-consumption rule vs. a tariff-aware logic or full cost optimisation). Your report must:

• Compute and report the energy breakdown (kWh), cost breakdown (£), and SOC time series.

• Address and justify the end-of-horizon SOC (e.g., enforcing SOCend ≥ SOCinit).

Focus on formulating the policies mathematically, translating them into code, and providing explicit evidence of verification.

Parameter	Default value
Usable capacity	5 kWh
Max charge power	2.5 kW
Max discharge power	2.5 kW
Round-trip efficiency	90% (ηch = ηdis = 0.95)
Initial SOC	50% of capacity
Grid charging	Allowed

Figure 1: Case A topology: single bus with PV, battery, grid, and load.

Choose one or more extensions: You can choose one of the following:

• EV integration: use caseA_ev_events.csv and add an EV charging requirement that must be met by the departure time. State discretisation rule for arrival/departure times; ensure energy requirement is met by departure.

• Heating integration: use caseA_smart_home_30min_winter_optional.csv and add heating de mand with a heat pump model and comfort or temperature constraints (keep it simple). Convert thermal demand to electrical via a stated COP.

• Forecasting: build a simple PV forecast (persistence or moving average) and apply a receding horizon policy. Analyse forecast error impact on system performance and cost.

• Battery degradation: add a simple throughput-based degradation cost and show how it changes the optimal/heuristic dispatch decisions.

4.2 Case B: Grid Scale Battery in Electricity Markets

The Problem. Using caseB_grid_battery_market_hourly.csv (∆t = 1 h), build a battery dispatch model that conducts energy arbitrage (buying when the price is low and selling when the price is high). Your objective is to maximise profit based on day-ahead prices. Your report must:

• State all battery parameters (capacity, power limits, efficiency, initial SOC).

• Perform explicit unit conversions (e.g., GBP/MWh → GBP/kWh) with at least one shown unit check.

• Implement arbitrage on day-ahead price: buy low, sell high.

• Compute and report total profit, energy throughput, and SOC time series.

• Address end-of-horizon SOC (enforce or report and justify).

Focus on formulating the trading rules mathematically, translating them into code, optimisation of the trading, and verifying that battery operational bounds are strictly respected.

Parameter Default value

Energy capacity 2 MWh (2000 kWh)

Max charge power 1 MW

Max discharge power 1 MW

Round-trip efficiency 88% (ηch = ηdis = 0.938)

Initial SOC 50% of capacity

Market Bus

Battery

Wholesale

Market

Storage

Market

↔ bidirectional

Figure 2: Case B topology: battery connected to wholesale electricity market.

Choose one or more extensions: You can choose one of the following:

• Market stacking: include the ancillary availability payment (review and build an ancillary market model first). Represent the tradeoff between reserving capacity for ancillary services vs. pure arbitrage.

• Degradation: include a cycling penalty or throughput-based cost and show how the profit optimal dispatch changes as a result.

• Carbon-aware dispatch: treat the carbon intensity column as an additional objective or constraint and analyse the tradeoffs between profit and emissions.

4.3 Case C: Community Microgrid (PV + Shared Battery)

The Problem. Using caseC_community_microgrid_hourly.csv (∆t = 1 h), model PV and three distinct electrical loads connected to a shared community battery and the grid. Define and implement a control policy or optimisation framework that reduces the total cost for the community as a whole.

Your report must:

• State all shared battery parameters (capacity, power limits, efficiency, initial SOC, grid charging yes/no).

• State your metering assumptions (e.g., single community meter at grid connection).

• Define a community-level objective or policy (e.g., minimise total cost).

• Compute and report energy breakdown (kWh), cost breakdown (£)

• Address end-of-horizon SOC (enforce or report and justify).

Focus on the mathematical formulation of the sharing logic, translating it into a computational pipeline, and verifying the system-level flows and key performance indicators.

Parameter Default value

Usable capacity 10 kWh

Max charge/discharge power 5 kW

Round-trip efficiency 90%

Initial SOC 50% of capacity

Grid charging Allowed

Community Bus

Battery

Grid

Load 1

Load 2

Load 3

Source

Storage

Grid

Load

→ one-way

↔ bidirectional

Figure 3: Case C topology: shared PV and battery serving three loads with grid connection.

Choose one or more extensions: You can choose one of the following:

• Fairness and allocation: allocate total community cost savings between individual households using a stated rule (e.g., Shapley value or proportional) and discuss fairness implications.

• Network constraints: introduce a feeder import limit (a limited transformer capacity) and show when it binds and how it changes the community’s operation.

• Peer-to-peer (P2P) trading: define a trading rule and priority order for energy sharing between households before using the grid; compare outcomes with and without P2P trading.

4.4 Case D: Lunar Base Energy System (PV + Battery, Off-Grid)

The Problem. Using caseD_moon_base_hourly.csv (∆t = 1 h, 1418 hours over 2 lunar cycles), build a sizing and dispatch model for a completely off-grid lunar base. The system experiences roughly 355 hours of sunlight followed by 355 hours of darkness, requiring extensive battery storage. You must size both the PV array (xPV in kWp) and battery (kWh) to guarantee zero load shedding over 2 full lunar cycles. Your report must:

• State all battery parameters (capacity, power limits, efficiency, initial SOC). Note: required capacity is on the order of 15,000–20,000 kWh.

• PV generation and battery capacity.

• Implement at least one approach for sizing (e.g., rule-based sizing or optimisation).

• Report any load shedding explicitly (though the design goal is zero).

• Address end-of-horizon SOC (enforce or report and justify).

Focus on the mathematical formulation of the energy balance, implementing the sizing/dispatch rules, and verifying that demand is fully satisfied. Note: No grid connection — feasibility depends entirely

on PV and battery.

Parameter Default value

PV panel efficiency 20% (included in pv_profile_per_kwp)

PV specific mass 5 kg/kWp

Battery specific mass 10 kg/kWh

Battery round-trip efficiency 90% (ηch = ηdis = 0.95)

Max charge/discharge C-rate 0.5C (power = 0.5 × capacity)

Initial SOC 50% of capacity

Load shedding penalty Very high (design goal: zero shedding)

Electricity Bus

Array

Battery

Life Supp.

Thermal

Comms+Light.

+Sci.+Galley

No grid

Source

Storage

Load

→ one-way

↔ bidirectional

Figure 4: Case D topology: off-grid lunar base with PV, battery, and subsystem loads.

Choose one or more extensions: You can choose one of the following:

• Mass-minimised capacity expansion: formulate a capacity expansion problem that minimises total launched mass (PV at 5 kg/kWp + battery at 10 kg/kWh) subject to zero load shedding. Compare the optimal design with a heuristic sizing.

• Redundancy analysis: design the system to survive with only 80% of PV capacity (simulating panel failure or dust coverage). Show how the required battery size changes.

• Thermal coupling: use a simple lumped thermal model of the habitat (thermal mass, insulation, surface temperature as boundary condition) to make heating demand endogenous rather thanexogenous. Show how thermal storage in the habitat structure reduces battery requirements.

5 Submission Requirements

This section defines what you must deliver for the base case. The base case is designed to be achievable with a clean simulator and strong verification. Check Table 2 for the marking rubrics of the report.

Your chosen extension should follow the same structure as the base case, but add a realistic extra feature and the verification to match: What you added involves defining the new component, constraint, or objective alongside any new parameters or data columns; this leads to what changed in the model, specifically the new equations or logic and their interaction with the existing system. How you verify and new insight are also needed for any extensions.

You must clearly indicate your chosen extension to receive the remaining 10% of the marks.

• Report PDF submission (up to 6 pages, excluding appendices. for example you can add more plots in the appendix), by 9th April 2026. You do not need to paste the codes in appendix. It is recommended to put the codes in a github repo and share the link in the report. Appendix is about adding more plots to better communicate your analysi and findings.

6 Compulsory AI Usage Statement (required even if you do not use AI at all)

You can use AI at different stages to complete this coursework and report, but you must use it responsibly and transparently. Your report must include a compulsory AI statement, even if you did not use AI at all (in which case you may state: “I have not used AI in completing this coursework”).

While this statement is not graded, please note: if it is missing, a 40% mark cap will be applied.

Your statement must be short but specific:

• Tools used: list the tool(s) and version/tier if relevant (e.g., ChatGPT, Copilot, Claude).

• Purposes: what each tool was used for (e.g., brainstorming, coding, proofreading, visualisation, etc).

• Any other aspects you want to clarify.

7 Marking Rubric (90 base + 10 extension = 100 max)

We will mark your submission based on your formulation, explainability, evidence-based verification, and engineering insights. We are marking the quality of your engineering report and your modelling approach, rather than just the final simulation results. Table 2 shows the marking breakdown.

Criterion	Marks
Model Formulation: Mathematical definition of the system, variables, constraints, and objectives; clarity of assumptions and unit consistency.	20
Implementation and Explainability: Quality and transparency of the computational pipeline; readability of code logic and clarity in explaining the modelling decisions.	20
Evidence-based Verification: Systematic checks (e.g., energy balance, boundary con ditions, unit tracking) proving that the code adheres to model physics and constraints and project alignments to ensure the designed deliverables are met.	25
Engineering Insights: Result interpretation, trade-off analysis, and meaningful visu alisations that build engineering understanding.	25
One extension (adds realistic complexity plus appropriate new checks and analysis)	10