Grid Designerは無料のシミュレーターで、英国向けのゼロ カーボン グリッドを設計およびテストし、実際の需要と気象データを使用してテストできます。この記事では、モデルがどのように機能するか、およびエネルギーの選択についてモデルが何を教えてくれるかについて説明します。
グリーンエネルギーへの移行がどれほど難しいか考えたことはありますか? 🌍
エネルギーと気候がニュース サイクルから外れることはめったにないため、私はこれらの質問を自問し始めました。より多くのことを学ぶにつれて、エネルギーシステムと選択をソフトウェアでモデル化する方法について考え始めました。
この探索の結果が Grid Designer です。これは、理想的なグリーン エネルギー グリッドを設計し、実際の英国のエネルギー需要と気象データを使用してテストできるシンプルなゲームです。これはモバイルで最適に機能し、ここで試すことができます。
問題を解決するためのソフトウェアを作成することの楽しい点は、問題をコードで記述するのに十分なほど深く理解する必要があることです。この記事では、シミュレーションがどのように構築されたか、エネルギー源についてより明確に考える方法 (利点、トレードオフ、コスト) について説明します。
気候に関する目標を達成するには、電力システムをゼロ カーボンにする必要があります。ほとんどが greenではなく、ほぼ 0 – 0ではありません。
したがって、このモデルは、スケーラブルなゼロ炭素エネルギー源のみに焦点を当てています。
ソーラー☀️(太陽光発電)
風💨 (オンショア & オフショア),
核⚛️(核分裂)
バッテリー/ストレージ🔋
水力発電や地熱発電などの他の電源は、非常に限られた場所にしか導入できないため、除外されています。核融合のような理論的技術にも同じことが当てはまります。刺激的かもしれませんが、私は気候危機に対する最も妥当な解決策に焦点を当てています。
また、グリッドからの 100% のアップタイムも必要です。文明は、生活水準の後退を容認すべきではなく、容認することもありません。私たちのグリーン エネルギー システムが需要を満たすことができない場合、化石燃料へのフォールバックと CO2 ゼロへの失敗を予期しなければなりません。コミュニティは、停電や配給を容認しません。豊かさを最適化する必要があります。
需要の急速な変動と一部の再生可能エネルギー源の断続性を考慮して、システムを高解像度でモデル化したいと考えました。これは、1 年間の 1 時間ごとを意味します。
シミュレーターは英国に焦点を当てていますが、ソフトウェアは任意の国または国のグループ (国の輸出入力) に適用できます。
シムには、4,000億ポンドの架空の予算が含まれています。この数値は非常に恣意的であり、その目的はプレイヤーが資本の制約を考慮できるようにすることです。英国はグリッドに 1 兆ドルを費やすことはできません!償却、ユニットの寿命、リサイクル コストなどの複雑な財務トピックは、その範囲を超えています。
可能な限り、私は楽観主義に傾倒してきました-そのコストであろうとエネルギー出力であろうと。このシムは電力の生産と消費のみに焦点を当てているため、効率的な送電などの高度なトピックは含まれていません。
目標は、超高忠実度のモデルを作成することではなく、考えさせられ、有益なほど正確なものを作成することです!
さぁ、始めよう…。 ⚡️
どれだけの力が必要ですか? 5m 間隔で記録された 10 年分の全国グリッド データを含む csv ファイルを取得できました。ファイルが Excel には大きすぎる (100 万行以上) ため、Python を使用して 2021 年を分離し、1 時間ごとの平均需要を計算しました。 JS に変換すると、次のようになります。
export const uk_grid_demand_2021 = [ // Jan 1st - each value is avg demand by hour, starting at 00:00. (MWs) [28956, 28183, 27092, 26254, 25416, 25050, 25632, 25740, 26609, 28927, 31482, 33423, 34821, 35424, 35540, 36051, 38430, 40352, 39044, 36578, 34266, 32093, 29887, 27168], // Jan 2... etc ]
需要は 1 年を通して、また 1 日を通して変化します。
次に、太陽光、風力、原子力、貯蔵、化石燃料など、個々のエネルギー源をモデル化する方法を見ていきます。
solar: { name: 'Solar', unit: 'hectares', unitToMw: 1.2, // 1.2 hectares = 1 MWp capex_per_mw: 0.92, // Million USD per MWp opex_per_mw: 0.017, }
面積は、太陽光発電をスケーリングする際に考慮すべき重要な単位です。グリッドを設計するときに、必要なソーラー パネルの量をヘクタールで定義します。
ソーラー パネルには、 Megawatt peak (MWp)
という単位で定義される「定格容量」があります。定格 1 MWp のソーラー アレイは、理想的な条件で1 MW の電力を生成できます。実際の出力は、緯度、向き、天候などの要因によって異なります。これらのうち、緯度はグリッドを設計する際に最も重要です。南フランスに配置されたパネルは、スコットランドに配置された同じパネルよりも「定格」性能にはるかに近くなります.
Grid Designer では、太陽エネルギーが最も多く利用できるイングランド南部だけにソーラー パネルを配置すると仮定しました。政府の数値に基づいて、1 MWp のパネルごとに 1.2 ヘクタールの土地が必要であると想定しています。
Solar Rated Capacity (MW) = Area in Hectares * 1.2
1 時間ごとの発電量を計算するために、グローバル ソーラー アトラスのデータを使用します。
電力出力が 1 日および 1 年を通してどのように変化するかに気付くでしょう。 12 月の短い日には、ソーラー ファームは夏に提供するエネルギーのわずか 10 分の 1 しか生産できません。真夏の正午には、当社のソーラー パネルは定格容量の約半分を生成します。
注: 当社のソーラー参照データは、実際の日ではなく月ごとにグループ化されています。これは、太陽モデルが他のソースよりも粒度が低いことを意味します。1 月の毎日は同じと見なされ、2 月には変化します。また、天候を無視し、常に理想的な条件を寛大に想定しています。
シミュレーターは上記のデータを使用して、1 年の各日の時間別出力を計算します。 Output = solarOutput[month][hour] * MWp
注:シェフィールド大学のソーラー Web サイトで、リアルタイムの英国のソーラー出力を表示できます。
PV ソーラー パネルのコストは過去 20 年間で急激に低下し、太陽光発電はランニング コストが非常に低いことで有名です。設備投資と運用コストの数値は、National Renewable Energy Lab の2025 年の予測に基づいています。
大規模な太陽光発電設備のみが実行可能と見なされることに注意してください。屋上太陽光発電は、実用規模の太陽光発電所の MWp あたり少なくとも 2 倍の費用がかかり、全国規模での需要を満たすのに十分な適切な屋根スペースがありません。同様に、高緯度に配置されたパネルは、南に配置されたパネルよりもはるかに費用対効果が低くなります。
最後に、ソーラーの財務見積もりには土地代が含まれていません。これは、ケントやコーンウォールのような場所で必要な面積を考えるとかなりの額になります。このモデルはまた、パネル用に農地や生け垣を転用することによる生態学的および生物多様性のコストについても考慮していません。
wind_l: { name: 'Onshore Wind', unit: 'Turbines', unitToMw: 4, // ie 4MW Turbines capex: 1.7, // Million USD per MW opex: 0.02, } wind_os: { name: 'Offshore Wind', unit: 'Turbines', unitToMw: 15, // ie 15 MW Turbines capex_per_mw: 6.04, // Million USD per MW opex_per_mw: 0.12, }
風をモデル化するために、構築したい陸上風力タービンと洋上風力タービンの数を設定します。シミュレーターはこれらを英国中の既存のサイトに配布し、過去の気象データを使用してエネルギー出力をモデル化します。これは、1 年間、1 時間ごとに行われます。
当社のオンショアおよびオフショア タービンは、National Renewable Energy Laboratory からのオープンソース情報に基づいてモデル化されています。
過去の毎時風速データは、Visual Crossing の weather API を使用して収集されています。これらのデータは Python で処理され、別の JSON ファイルでシムが利用できるようになります。
気象データは、高さ 10m で記録された風速を示します。ただし、風速は地上からの距離とともに増加し、風力タービンの高度では高くなります。これが、タービン (および帆船) のマストが非常に高い理由です。マストが高いほど、より多くのエネルギーを利用できます。風速の増加は、「粗さ」と呼ばれる周囲の表面の摩擦に依存します ( 説明については、こちらを参照してください)。
陸上のタービン サイトでは、粗さを 0.055m と想定し、風速をタービン ハブの高さ 110m に合わせて調整しました。オフショアの場合、ラフネスを 0.0002m と想定し、ハブの高さ 150m で風速を調整します。すべての値は m/s に変換されました。
風力タービンの動作性能は、その出力曲線によって表されます。
cut-in
風速以下では、ブレードは回転できず、発電しません。このしきい値を超えると、出力はタービンの最大出力まで曲線をたどります。タービンが最大出力に達する値がrated wind speed
です。タービンは、 cut-out
速度に達するまで最大出力近くで動作し続けます。カットアウト速度とは、ローターが損傷を避けるためにブレーキをかけなければならない風速です。
シミュレーターを作成するために、電力曲線の曲線を直線に単純化しました。
cut-in
値を超える風速については、直線の式y = mx + c
を使用して電力出力を計算します。ここで、 y
は MW 単位の出力、 m
は勾配、 x
は風速、 c
は y です。 -インターセプト。
シミュレートされたオンショアおよびオフショア タービンの電力曲線データは、 NREL の GitHubから取得されました。値は次のようにコードで定義されます。
// Onshore Turbine 4MW, 110m const wl_power_curve = { cut_in: 3.25, // m/s rated: 9.75, cut_out: 25, } // Off-Shore Turbine 15MW, 150m const ws_power_curve = { cut_in: 4, rated: 11, cut_out: 25, }
突風とは、風速が上昇する短い期間のことです。 API ソース データには、少なくとも 25 秒間続いた突風の値が含まれており、多くの場合、これらはタービンcut-out
風速よりも大きくなっています。ただし、タービンが突風に正確にどのように反応するかについて、メーカーから一貫したデータを見つけることができなかったため、モデルから除外しました。タービンのメンテナンスのダウンタイムは短く (年間約 24 時間)、除外されています。
現代のタービンは、あらゆる方向の風に向き合うように回転することができるため、これを即座かつ完全に行うと想定しています。空気がブレードの表面を通過すると、乱流または後流が発生し、下流のタービンで利用できるエネルギーが減少します。ウィンド ファームは、一般的な (最も一般的な) 風向に合わせてタービンを配置することで、これを最小限に抑えるように設計されています。したがって、これらの影響は通常小さく、モデルには含めていません。
この作業の過程で、風速の値が平均値ではないことを知って驚きました。代わりに、それらはその期間における最大の持続風速です。したがって、火曜日の風速が 15 m/s であると API が示している場合、このしきい値が 1 日に 1 回だけ記録されたことを確認できます。平均風速はずっと低かったかもしれません。
毎日の風速値を使用すると、出力が大幅に過大評価されるため、これはあらゆるモデリングに重要な意味を持ちます。次の実際の例を考えてみましょう。
赤い線では、 「毎日」の風速が 5.3 m/s であることがわかります。 1 日 1 時間使用すると、タービンは定格出力の 30% で動作します (赤い網掛け部分)。しかし、同じ日の 1 時間ごとのデータを青で見ると、ほとんどの時間で、記録された最大風速がタービンのカットインしきい値を満たせず、生成された総エネルギーがはるかに少ないことがわかります (青の網掛け部分)。 )。
風は断続的であるため、タービンのパフォーマンスを理解するには、きめ細かい解像度が不可欠です。
1 時間ごとに、各サイトの風力出力を次のように計算します。
// installed_mw = number of turbines * MW rating of turbine. const m = 1 / (power_curve.rated - power_curve.cut_in) const c = -1 * m * power_curve.cut_in let output; if (windData[d][h] < power_curve.cut_in) { output = 0 } else if (windData[d][h] > power_curve.cut_out) { output = 0 } else if (windData[d][h] >= power_curve.rated) { output = installed_mw } else { // y = mx + c; x=wind speed, y=power output, c = y-intercept let y = m * windData[d][h] + c // Fraction of rated output output = y * installed_mw } return output
このコードは、単純化された電力曲線の勾配 ( m ) と y 切片 ( c ) を見つけます。風速がカットインしきい値を上回り、定格しきい値を下回っている場合、風速に基づいて最大出力の割合 ( y ) を計算し、これを使用して出力を MW で返します。
現在、シミュレーターは陸上風力発電所 1 つと洋上風力発電所 1 つ ( Scout Moor & Hornsea ) のデータのみを提供しており、これは確かに制限です!サイトを追加することで、シミュレートされたグリッドで風が弱い日のリスクを軽減できます。ホーンシーで風が吹いていない場合は、ケントまたはアバディーンシャーの海岸から吹いている可能性があります。この戦略は有効ですが、他のサイトを補うために各サイトで「過剰構築」する必要があり、コストが増加し、多数のサイトで風速が低い日には役に立ちません.
コストの仮定は、米国エネルギー情報局から取得されます。
オンショアとオフショアに建設したいタービンの数を設定します。
英国全土の既存の風力発電所にタービンを配置し、2022 年の実際の気象データを使用して出力を計算します。
現在、シミュレーションに使用できるのは 2 つのサイトのみです。
風速は、各タービンの高さと周囲の土地/海の「粗さ」に合わせて調整されます。
簡略化された出力曲線を使用して、タービンの性能を計算します。
出力は、1 年 365 日、1 時間ごとにモデル化されます。
突風とタービンの後流の影響は無視されます。
nuclear: { capacity_factor: 0.9, capex_per_mw: 7.0, opex_per_mw: 0.13, }
原子力は意見の分かれるトピックであり、悲しいことに、それに対する批判のすべてが証拠によって裏付けられているわけではありません。詳細については別の投稿で説明しますが、テクノロジーの公正な要約は次のことを観察することになると思います。
原子力は一般に、他のソースに比べて構築に費用と時間がかかります。ただし、MW あたりの限界費用を低く抑えながら、非常に高いアップタイムで膨大な量のゼロ カーボン エネルギーを生成します。
Grid Designer は、最近委託されたSizewell Cを参照として使用して、「発電所」の観点から原子力をモデル化します。十分に確立された PWR 設計を使用して、その 2 つの原子炉は、60 年の寿命にわたって合計 3200MW のエネルギーを提供します。
異なるコストと出力プロファイルを持つ他の原子炉設計があります。これらには、小型モジュラー原子炉 (SMR) と溶融塩原子炉 (MSR) が含まれますが、PWR ほど確立されたものはないため、シミュレーターのオプションとして含まれていません。
原子力は非常に高い設備利用率を持っています。原子炉がエネルギーを生成しないのは、予定されたメンテナンスや燃料補給のために停止するときだけです。これらのシャットダウンが計画的なイベントであることを考えると、それをモデル化する方法については単純化したアプローチを採用します: 設備利用率を 90% と仮定し、この割引を年間の出力に適用します。
Hourly output = 3200 * Number of Stations * 0.9
原子力発電所は、予測可能なベースライン エネルギーを提供します。
英国の実際のグリッド データでも、同様の安定したパターンが見られます。
原子力発電所の建設と運営のコストは、悪名高いプロジェクトのオーバーランで、熱く議論されています。批判者は、これはこの技術が実現不可能であることを証明していると主張し、擁護者は一貫した投資の重要性を指摘しています。韓国は、核兵器群の構築速度を上げてコストを削減した国の例としてよく引き合いに出されます。 Grid Designer のコスト見積もりは、再び米国エネルギー情報局から取得したものであり、運用コストには燃料と廃棄物の安全な処分が含まれることを理解する必要があります。
3200*0.9
で計算される小さな設備利用率割引で一貫した電力を提供します。
storage: { name: 'Battery Storage (Li-Ion)', unit: 'MWh', capex_per_mw: 0.2, // Million USD per MWh opex_per_mw: 0.025 }
電力貯蔵は、再生可能エネルギーに依存するグリッドにとって不可欠です。停電は受け入れられないため、風力と太陽の断続性による不足分を補うためにバッテリーが必要です。
バッテリ システムには定格出力があります。これは、一度に供給できる最大電力量 (メガワット) と、個別の容量値(メガワット時) です。したがって、完全に充電された 60MW/240MWH のバッテリー システムは、60MW を 4 時間、または 30MW を 8 時間といった具合に供給できます。
簡単にするために、定格出力を無視して容量だけに注目することにしました。これは、バッテリーが常に出力需要を満たすことができ、容量 (MHW) によってのみ制限されると想定していることを意味します。また、サイクル タイムや過熱などの要因も無視しています。
私たちのグリッドは毎時約 30GW のエネルギーを必要とするため、これは、ストレージだけで 1 時間の需要を満たすには 30,000MWH の設備が必要であることを意味します。これは大量です!
私たちのバッテリーは、その時間に利用できるエネルギーが不足しているか過剰であるかに応じて、充電または放電されます。 1 時間ごとのシミュレータ コードは次のようになります。
let d = demand[day][hour]; let s = solar_output + wind_l_output + wind_os_output + nuclear_output; let balance; //demand exceeds supply if (d >= s) { const deficit = ds // ...code to drain batteries } //supply exceeds demand else if (d < s) { const surplus = s - d // ...code to charge batteries with the surplus } return balance
バッテリーのコストとその予測される将来のコストが議論されています。このモデルは、国立再生可能エネルギー研究所の予測を使用しており、リチウム イオンについて非常に楽観的な1 KWH あたり 200 ドルを想定しています。現実には、グリッド規模でバッテリーを購入して展開する場合、そのような価格が維持されるかどうかは疑わしい.たとえば、英国にわずか 12 時間 (現在の需要レベルで) 電力を供給するには、約 420 GWH の蓄電ソリューションが必要です。これは、リチウム イオン電池の年間世界生産量を超えています!最後に、このようなバッテリーは 5 年ごとに交換する必要があることにも注意してください。
バナジウム レドックス フロー電池 (VRBF) のような代替のグリッド スケール ストレージ技術は、同様の予測価格タグを持っており、私たちのモデルは十分に単純なので、これらは交換可能と考えることができます。鉄空気電池は大幅に安価になると予測されている技術ですが、まだ大規模生産には至っていません。
ストレージに費やされたすべてのペニーは、エネルギー生産に費やされた可能性があるペニーであることを覚えておく価値があります.
fossil_co2_mwh = 233 // Kg CO2
私たちのグリーン エネルギー グリッドが需要を満たすことができないときはいつでも、私たちは化石燃料に頼ります。天然ガスを使用することにより、楽観的な化石燃料電力 MWH あたり 233kg の CO2 を想定しています ( 出典)。注: 現在の英国の平均は 500kg を超えています。
Grid Designer は、CO2 の放出を失敗と見なします。つまり、英国の化石燃料インフラを完全に廃止したいと考えています。包括的なミッションは正味ゼロですが、大気から CO2 を除去するコストは、一度排出されると非常に高く (1 トンあたり 1 億ドルから 3 億ドル)、最初から燃やさないほうがよいでしょう。
シミュレーターは「グリーン アップタイム」チャートを出力します (github に触発されました!)。これは 1 年中毎日表示され、グリッドが無炭素エネルギーで稼働した時間数を視覚的に示しています。
シムは、毎日の分析のオプションを含む、グリッドのパフォーマンスの概要も提供します。
パフォーマンスを評価するとき、シムは有効なエネルギー出力を評価しています。
これは、シミュレーターの背後にある技術的な考え方を深く掘り下げたものです。ポリシーの結論は別の投稿に譲ります。今のところ、トピックをある程度調査したので、次のことを簡単に確認します。
フィードバック、意見、反論、訂正、反論はコメントで歓迎します!