<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
    <channel>
      <title>icon4py Knowledge Base</title>
      <link>https://c2sm.github.io/icon4py-knowledge</link>
      <description>Last 10 notes on icon4py Knowledge Base</description>
      <generator>Quartz -- quartz.jzhao.xyz</generator>
      <item>
    <title>icon4py Knowledge Base</title>
    <link>https://c2sm.github.io/icon4py-knowledge/</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/</guid>
    <description><![CDATA[ Design ideas and proposals for icon4py. Drop an idea, cross-check it against what already exists, and surface conflicts early. ]]></description>
    <pubDate>Fri, 17 Jul 2026 15:19:58 GMT</pubDate>
  </item><item>
    <title>Verify that the domains of all the GT4Py programs are as minimal as possible using an LLM</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/iomaganaris/domain-minimalization</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/iomaganaris/domain-minimalization</guid>
    <description><![CDATA[  TL;DR Let an LLM check the whole icon4py frontend code to figure out if there are opportunities to restrict the domain of GT4Py field operators/programs Problem / motivation In icon4py PR#1378 Jacopo figured out that by restricting the domain computation of field it fixed not only the correctness b... ]]></description>
    <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Systematic stencil-domain over-computation audit (dycore, diffusion, advection)</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/jcanton/stencil-domain-audit</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/jcanton/stencil-domain-audit</guid>
    <description><![CDATA[  TL;DR Execute a full, evidence-based audit of every stencil invocation in dycore + diffusion + tracer advection to find PR#1378-class defects: computing where results are never consumed, and reading skip-valued (-1) connectivities or uninitialized inputs outside the meaningful domain. ]]></description>
    <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Optimize the standalone-driver startup time on GPU</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/iomaganaris/standalone-driver-startup-opt/standalone-driver-startup-opt</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/iomaganaris/standalone-driver-startup-opt/standalone-driver-startup-opt</guid>
    <description><![CDATA[  TL;DR I have noticed that there are lot of small (4 byte) DtoD, HtoD and DtoH memory copies in the beginning of the standalone driver. ]]></description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Cleanup the &quot;decomposition&quot; directory</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/msimberg/cleanup-distributed-computation</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/msimberg/cleanup-distributed-computation</guid>
    <description><![CDATA[  TL;DR The icon4py.model.common.decomposition package has outgrown its name: it mixes grid decomposition, MPI runtime, halo exchanges, global reductions, and single-node fallbacks. ]]></description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Revive components — spec reference</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/msimberg/revive-components/revive-components_spec</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/msimberg/revive-components/revive-components_spec</guid>
    <description><![CDATA[  Status: unreviewed reference material. ]]></description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Revive components</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/msimberg/revive-components/revive-components</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/msimberg/revive-components/revive-components</guid>
    <description><![CDATA[  TL;DR Revive and flesh out the Component Protocol from model/common/src/icon4py/model/common/components/components.py into a usable, well-documented interface for model building blocks. ]]></description>
    <pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Declarative testing harness</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/havogt/declarative-testing-harness/declarative-testing-harness</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/havogt/declarative-testing-harness/declarative-testing-harness</guid>
    <description><![CDATA[  TL;DR Stencil tests and serialbox data tests are the same test shape with different input and oracle sources; give them one declarative core — fields declared by name with per-field tolerances, verified as pytest subtests — plus two thin presets, and stop hand-writing the savepoint→state boilerplat... ]]></description>
    <pubDate>Wed, 10 Jun 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Declarative testing harness — prior art and research</title>
    <link>https://c2sm.github.io/icon4py-knowledge/personal/havogt/declarative-testing-harness/declarative-testing-harness_research</link>
    <guid>https://c2sm.github.io/icon4py-knowledge/personal/havogt/declarative-testing-harness/declarative-testing-harness_research</guid>
    <description><![CDATA[ Background for Declarative testing harness. Survey done June 2026. Facts and verbatim snippets; conclusions live in the proposal. 1. ]]></description>
    <pubDate>Wed, 10 Jun 2026 00:00:00 GMT</pubDate>
  </item>
    </channel>
  </rss>