[FEATURE] Replace the stdin/stdout JSON hand-off between Python and Julia OPF with file-based exchange

オープン
  • 何か問題がありますか？
#698 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
json, julia, python
領域
data

調査の方向性

Start with pm_optimize and Main.jl, where the issue says Python writes input to Julia’s stdin and Julia emits results on stdout; trace how arguments and the existing results directory are handled. Check the subprocess and result conversion paths, then run the relevant optimization tests. Done means input and result are exchanged through files and stdout carries logs only, with results still loaded into the eDisGo object.

索引モデルが issue の本文から書いたものです。

説明

area: opf effort: large enhancement priority: medium

Current state

pm_optimize writes the network as one JSON line to the Julia subprocess's stdin; Main.jl
prints the result JSON to stdout, interleaved with debug logs, printlns and Gurobi
banners. Python identifies the result line by out.rstrip().startswith('{"name"').

Why this is fragile

  1. Result detection depends on unguaranteed JSON key order. JSON.json(::Dict) serializes
    in hash/iteration order — "name" being the first key is coincidence, not contract. If the
    result line ever starts with another key (different Julia/JSON.jl version, changed key set),
    the startswith branch misses it: from_powermodels is never called, no results are
    written to the eDisGo object    , the raw JSON is echoed to stdout, and the run still logs
    "Julia process was successful." — silent loss of results on a successful solve.
  2. Logs and payload share one channel, separated only by prefix heuristics ("Set parameter",
    "Academic").
  3. The input contract ("exactly one JSON line on stdin", read via readline) is implicit and
    unenforced; large inputs are written in full before stdout is drained (OS pipe-buffer
    deadlock risk for very large networks).

Proposal

Exchange input and result as files (paths passed as arguments, e.g. into the existing
results directory or a temp dir): Python writes <run>_input.json, Julia writes
<run>_result.json; stdout remains purely a log channel. This removes the key-order trap, the
log/payload mixing and the pipe-buffer risk in one step.

Interim hardening (if stdout must stay temporarily): wrap the result in an unambiguous sentinel
(e.g. ###RESULT###{…}) instead of keying on {"name".

主要言語
Python
スター
48
フォーク
22
平均マージ
1日 7時間
マージ済み PR（30日）
38

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

openego/eDisGo のほかの issue

openego/eDisGo の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。