142 lines
7.6 KiB
Markdown
142 lines
7.6 KiB
Markdown
TASK: Perform a *surgical*, additive refinement of an existing academic paper on battery simulation to close three specific gaps:
|
||
(1) Missing GPS power
|
||
(2) Missing uncertainty quantification (Monte Carlo)
|
||
(3) Static aging TTE that fails to reflect dynamic degradation
|
||
|
||
CRITICAL REQUIREMENT (NON-NEGOTIABLE): PRESERVE EXISTING CONTENT INTEGRITY
|
||
- You MUST NOT do broad edits, major rewrites, rephrasings, or restructuring of any previously generated sections.
|
||
- You MUST NOT renumber existing sections or reorder headings.
|
||
- You MUST NOT change the existing narrative flow; only add narrowly targeted content and minimal equation patches.
|
||
- You MUST output only (a) minimal patches and (b) insert-ready new text blocks.
|
||
- If you cannot anchor an insertion to an exact existing heading string from the provided paper, output ERROR with the missing heading(s) and STOP.
|
||
|
||
INPUT DATA (use only the uploaded files):
|
||
1) The official MCM Problem A PDF (for requirements language: GPS, uncertainty, aging).
|
||
2) The current paper markdown (contains the existing model and structure).
|
||
3) The flowchart markdown (contains intended technical pipeline elements, e.g., UQ).
|
||
|
||
MODEL CONTEXT YOU MUST RESPECT (do NOT rewrite these; only refer to them):
|
||
- Existing input vector u(t) = [L(t), C(t), N(t), Ψ(t), T_a(t)] and state x(t) = [z, v_p, T_b, S, w].
|
||
- Existing power mapping: P_tot = P_bg + P_scr(L) + P_cpu(C) + P_net(N,Ψ,w).
|
||
- Existing CPL closure and event-based TTE logic.
|
||
- Existing SOH concept S(t) and its coupling to R0 and Q_eff (if present).
|
||
- Existing section numbering and headings.
|
||
|
||
YOUR OBJECTIVES:
|
||
A) CLASSIFY each gap by whether it requires changes to the base Model Construction:
|
||
- “Base Model Construction” includes: core equations, constitutive relations, or simulation logic required to run the model.
|
||
B) For gaps NOT requiring base model changes, generate insert-ready academic text immediately (no rewrites).
|
||
C) For gaps requiring base model changes, produce:
|
||
- A minimal patch (equations/logic) expressed as a precise replace/insert instruction.
|
||
- A small, insert-ready text addendum describing the change (ONLY the new material; do not rewrite existing paragraphs).
|
||
|
||
METHODOLOGY (must be followed in order, no deviations):
|
||
|
||
STEP 1 — Locate anchors in the existing paper
|
||
1. Read the current paper markdown.
|
||
2. Extract the exact heading strings (verbatim) for:
|
||
- The power mapping section (where P_tot is defined).
|
||
- The numerical solution / simulation section (where MC/UQ would be placed).
|
||
- The aging/SOH discussion section (or closest related section).
|
||
3. Store these verbatim headings as ANCHORS. You will reference them in patch instructions.
|
||
|
||
STEP 2 — Gap classification (deterministic)
|
||
For each gap in {GPS, UQ, Aging-TTE} output:
|
||
- requires_equation_change: true/false
|
||
- requires_simulation_logic_change: true/false
|
||
- text_only_addition: true/false
|
||
Rules:
|
||
- If adding a new term inside P_tot changes an equation, requires_equation_change=true.
|
||
- If adding an outer-loop procedure for multi-cycle degradation is needed, requires_simulation_logic_change=true.
|
||
- If content is purely reporting/analysis based on existing outputs (e.g., Monte Carlo over parameters/inputs using the same ODEs), then text_only_addition=true and both “requires_*” flags must be false.
|
||
|
||
STEP 3 — Minimal patch design (ONLY if required)
|
||
You must keep changes minimal and local:
|
||
3.1 GPS Power gap:
|
||
- Add exactly ONE GPS term into the existing P_tot equation.
|
||
- Preferred minimal strategy: do NOT change the declared input vector; define a derived duty variable G(t) inside the new GPS subsection:
|
||
G(t) ∈ [0,1] derived from existing usage signals (e.g., navigation segment proxy) without redefining u(t).
|
||
- Define:
|
||
P_gps(G) = P_gps,0 + k_gps * G(t)
|
||
and update:
|
||
P_tot ← P_tot + P_gps(G)
|
||
- Do not edit any other power terms.
|
||
3.2 Dynamic aging TTE gap:
|
||
- Do NOT rewrite the base ODEs unless absolutely necessary.
|
||
- Add an outer-loop “multi-cycle / multi-day” procedure that updates S(t) (or the aging proxy) across cycles and recomputes TTE each cycle:
|
||
Example logic: for cycle j, run discharge simulation → accumulate throughput/aging integral → update S_{j+1} → update R0 and Q_eff via existing formulas → recompute TTE_{j+1}.
|
||
- Keep the inner single-discharge model unchanged; only add the outer-loop logic and clearly state time-scale separation.
|
||
|
||
STEP 4 — Insert-ready academic text blocks (additive only)
|
||
Generate concise academic prose that matches the paper’s existing style (math-forward, mechanistic rationale).
|
||
Rules:
|
||
- Each text block MUST be insertable without editing other sections.
|
||
- Each text block MUST define any new symbol it uses (e.g., G(t), P_gps,0, k_gps).
|
||
- Each text block MUST explicitly reference existing variables (L,C,N,Ψ,T_a,z,v_p,T_b,S,w,P_tot) without renaming.
|
||
- Citations: use placeholder citations like [REF-GPS-POWER], [REF-MONTE-CARLO], [REF-LIION-AGING] (do not browse the web).
|
||
|
||
You must produce 3 blocks:
|
||
BLOCK A (GPS): a new subsection placed immediately after the existing network power subsection (anchor it precisely).
|
||
BLOCK B (UQ): a new subsection placed in the numerical methods/results pipeline area describing Monte Carlo uncertainty quantification:
|
||
- Define what is random (choose ONE: stochastic parameter draws OR stochastic usage paths OR both).
|
||
- Specify sample size M (fixed integer), fixed seed, and outputs: mean TTE, quantiles, survival curve P(TTE>t).
|
||
- Emphasize: model equations unchanged; uncertainty comes from inputs/parameters.
|
||
BLOCK C (Dynamic aging TTE): a new subsection explaining aging-aware TTE as a function of cycle index/time:
|
||
- Define TTE_j sequence across cycles.
|
||
- Define which parameters drift with S (e.g., Q_eff decreases, R0 increases).
|
||
- Provide a short algorithm listing (numbered) but no code.
|
||
|
||
STEP 5 — Output packaging in strict schemas (no extra commentary)
|
||
|
||
DELIVERABLES (must be EXACTLY in this order):
|
||
|
||
1) GAP_CLASSIFICATION_v1 (JSON only)
|
||
Schema:
|
||
{
|
||
"GPS_power": {
|
||
"requires_equation_change": <bool>,
|
||
"requires_simulation_logic_change": <bool>,
|
||
"text_only_addition": <bool>,
|
||
"one_sentence_rationale": "<...>"
|
||
},
|
||
"UQ_monte_carlo": { ...same keys... },
|
||
"Aging_dynamic_TTE": { ...same keys... }
|
||
}
|
||
|
||
2) PATCH_SET_v1 (YAML only)
|
||
- Provide a list of patches. Each patch must be one of:
|
||
- INSERT_AFTER_HEADING
|
||
- REPLACE_EQUATION_LINE
|
||
Each patch item schema:
|
||
- patch_id: "P10-..."
|
||
- patch_type: "INSERT_AFTER_HEADING" or "REPLACE_EQUATION_LINE"
|
||
- anchor_heading_verbatim: "<exact heading text from the paper>"
|
||
- target_snippet_verbatim: "<exact single line to replace>" (only for REPLACE_EQUATION_LINE)
|
||
- replacement_snippet: "<new single line>" (only for REPLACE_EQUATION_LINE)
|
||
- insertion_block_id: "BLOCK_A" / "BLOCK_B" / "BLOCK_C" (only for INSERT_AFTER_HEADING)
|
||
|
||
3) INSERT_TEXT_BLOCKS_v1 (Markdown only)
|
||
Provide exactly three blocks, each wrapped exactly as:
|
||
-----BEGIN BLOCK_A-----
|
||
<markdown text to insert>
|
||
-----END BLOCK_A-----
|
||
(and similarly BLOCK_B, BLOCK_C)
|
||
|
||
4) MODIFICATION_AUDIT_v1 (JSON only)
|
||
Schema:
|
||
{
|
||
"edited_existing_text": false,
|
||
"changed_headings_or_numbering": false,
|
||
"patch_ids_emitted": ["..."],
|
||
"notes": "Only additive blocks + minimal equation line replace (if any)."
|
||
}
|
||
|
||
VALIDATION (hard fail rules):
|
||
- If you modify any existing paragraph (beyond the exact single-line equation replacement explicitly listed), output FAIL.
|
||
- If you renumber headings or propose reorganization, output FAIL.
|
||
- If any new symbol is introduced without definition inside its block, output FAIL.
|
||
- If any anchor_heading_verbatim does not exactly match a heading in the paper, output ERROR and STOP.
|
||
|
||
OUTPUT FORMAT:
|
||
Return exactly the 4 deliverables above (JSON, YAML, Markdown, JSON) and nothing else.
|