<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Papaer Summary on Ingenboy.inc</title>
    <link>https://blog.ingenboy.com/categories/papaer-summary/</link>
    <description>Recent content in Papaer Summary on Ingenboy.inc</description>
    <image>
      <title>Ingenboy.inc</title>
      <url>https://blog.ingenboy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</url>
      <link>https://blog.ingenboy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</link>
    </image>
    <generator>Hugo -- 0.152.2</generator>
    <language>en</language>
    <lastBuildDate>Fri, 30 Jun 2023 16:09:15 +0900</lastBuildDate>
    <atom:link href="https://blog.ingenboy.com/categories/papaer-summary/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Error_controlled_progressive_and_adaptable_retrieval_of_scientific_data_with_multilevel_decomposition</title>
      <link>https://blog.ingenboy.com/post/error_controlled_progressive_and_adaptable_retrieval_of_scientific_data_with_multilevel_decomposition/</link>
      <pubDate>Fri, 30 Jun 2023 16:09:15 +0900</pubDate>
      <guid>https://blog.ingenboy.com/post/error_controlled_progressive_and_adaptable_retrieval_of_scientific_data_with_multilevel_decomposition/</guid>
      <description>&lt;h2 id=&#34;abstruction&#34;&gt;Abstruction&lt;/h2&gt;
&lt;p&gt;近年の大規模な数値シミュレーションは、シミュレーション時のデータ書き込みのみならず、何度も読み出しが実行されるポスト処理においてもストレージがボトルネックになることが多い。
ポスト処理の内容は多岐にわたるが、様々なポスト処理に対応するための条件として、不必要なデータのi/oを極力減らすことがあげられる。本論文では、シミュレーションデータのrefactoring, compressing, retrievalのフレームワークを紹介する。refactoringにより粒度の細かい精度でデータを分解でき、要求した精度でデータを取得することが可能になる。本研究で紹介するフレームワークを使うことで、state-of-the-artの手法を使った時と比べ、複数の精度でデータを要求したときに大幅に取得するデータを減らすことができた。さらに粗い精度でのデータ要求があったときに、分析時間の短縮につながった。
具体的には、本フレームワークを使うことでほかのフレームワークを使った時と比べ、ある精度でのデータ要求があったときに64％のデータ削減を達成した。さらに、1024コアを使って600GBのデータの書き込みと読み込みを実行した際、従来の手法と比較した際、それぞれ1.36倍、2.52倍の性能向上を示せた。&lt;/p&gt;
&lt;h2 id=&#34;introduction&#34;&gt;introduction&lt;/h2&gt;
&lt;p&gt;大規模な数値シミュレーションから生み出されるデータ量は、ストレージのI/O性能を超えている。
並列ファイルシステムは高価なため、増設することが難しい。
一方、並列ファイルシステムに書き込まれたデータは、PFSの容量が圧迫する目的と、長期保存をする目的ですぐに二次記憶に退避される。
PFSのバンド幅は2-2.5Tb/sであるのに対し、二次記憶のバンド幅は1-2GB/sである。そして、このI/Oバンド幅が低いことが、科学的な発見を遅らせる原因となっている。
これらの問題があるため、多くの科学者は可逆圧縮や非可逆圧縮を使い、データの書き込み量や読み込み量を減らす。しかし、可逆圧縮は圧縮率が低いため、先の問題解決には不十分である。このことから近年、より大幅に圧縮が可能な非可逆圧縮が注目を浴びている。非可逆圧縮は、ユーザが指定した許容誤差を保証する範囲でデータの圧縮をする。
&lt;!-- raw HTML omitted --&gt;
しかし、この手法にも欠点がある。
それは、QoIがわからない、つまり、現象の発見に必要な最低限の許容誤差がわからない点である。
非可逆圧縮によるI/Oの恩恵と、QoIを両立させるためには、あるステップで許容誤差を緩めていき、様々な許容誤差で圧縮されたデータをためておけばいいが、それは本末転倒で、結果的に多くのデータをためることになってしまう。さらに、ある誤差で取得したデータの精度が十分でない場合は、再び誤差が小さいデータを1から取得する必要があり、結果的にI/Oを圧迫してしまう。
&lt;!-- raw HTML omitted --&gt;&lt;/p&gt;
&lt;p&gt;この問題に対処するのがProgressive compressionである。Progressive compressonとtransmitonは、まずデータを複数の精度に階層的に分解する。そして、ユーザがより高精度のデータを要求するときには、階層構造になったデータのより精度が高い一部分のみをユーザは新たに取得し、それを今までに取得したデータに重ね合わせる。これによりより高精度のデータを得られる。
本研究では、I/Oにボトルネックが生じるという課題を、このProgressive retrievalを用いて解決する。
&lt;!-- raw HTML omitted --&gt;
MGARDというフレームワークを用いることではこれを実現することが可能である。しかし、MGARDはresolution incremental re-compositionをサポートしているのみで、各階層ごとに隣接している精度が粗いという課題がある (これが多分bit-plainを考慮していないっていう話につながるんだと思う) 。本論文ではこれを解決するフレームワークをMGARDを用いて新たに作る。
&lt;!-- raw HTML omitted --&gt;
本研究のcontributionは下記のとおりである。
&lt;!-- raw HTML omitted --&gt;&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;データリファクタリングアルゴリズムと理論の紹介。本アルゴリズムは、MGARDとbit-plane encodingを組み合わせである。このアルゴリズムは、データを複数の階層の解像度と精度に分解することを可能にする。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;データを段階的に取得および再構成できるフレームワークの実装。この段階的な取得により、以下の2つの利点がある：1）データの取得/ストリーミング、再構成、および解析を非同期で実行でき、いつでも既知のエラー範囲内で行えます。2）次の精度レベルに至るデータの部分だけをストリーミングして解析結果が収束するまで、I/Oの負荷を減少。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;私たちは貪欲アルゴリズムを一般化して、複数のエラーメトリクスに対してデータの取得効率を改善します。このアルゴリズムは多様な事後解析に適応でき、解析に基づいて再構成されたデータの取得順序を変更することで取得サイズをさらに削減したり、粗い粒度の表現を提供することで解析のパフォーマンスを向上させることができます。また、私たちはフレームワークを最適化します。&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id=&#34;chapter2-問題と関連研究&#34;&gt;chapter2 問題と関連研究&lt;/h2&gt;
&lt;p&gt;イントロのようやく&lt;/p&gt;
&lt;p&gt;・過去10年間におけるデータとストレージ容量の不均衡な成長は深刻な問題である。
・exascaleコンピューティング時代ではさらに深刻化し、科学的な発見を妨げる要因となっている。
・ストレージとI/Oの制約に対処する有望な候補として、非可逆圧縮があげられている
・しかし、文献には広範な圧縮技術が存在するにもかかわらず、科学アプリケーションのコミュニティにおけるこれらの受け入れは低い
その理由は
1）データの削減プロセスがデータを生成した本来の現象に影響を及ぼす可能性があること。
2）単一のエラー制約の下で削減されたデータが、異なる解析のさまざまなニーズに適合しない可能性があること&lt;/p&gt;
&lt;p&gt;また、シミュレーションデータはPFSから二次記憶に移される、が二次記憶はバンド幅が小さいためデータの取得が遅くなる。データの生成（例：大規模な実験、シミュレーション）は時折行われるのに対し、生成されたデータはさまざまな研究によって取得される。よって、セカンダリストレージ層の低い帯域幅が不適切な/過剰なデータの取得コストを高める。私たちは、解析に必要な精度にちょうど適合する量のデータをユーザーに提供したいと考えています。&lt;/p&gt;
&lt;h1 id=&#34;背景&#34;&gt;背景&lt;/h1&gt;
&lt;h2 id=&#34;bit-plane-encoding-ビットプレーン符号化&#34;&gt;bit-plane encoding (ビットプレーン符号化)　&lt;/h2&gt;
&lt;p&gt;整数をビットで表したときに、桁が上位なビットほど、精度に与える影響が大きい。これは浮動小数点でも同じで、各桁ごとにデータを保存することで、精度に与える影響を優先度付けすることが可能となる。&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dissecting_self_describing_data_formats_to_enable_advanced_querying_of_file_metadata</title>
      <link>https://blog.ingenboy.com/post/dissecting_self_describing_data_formats_to_enable_advanced_querying_of_file_metadata/</link>
      <pubDate>Mon, 29 May 2023 18:43:01 +0900</pubDate>
      <guid>https://blog.ingenboy.com/post/dissecting_self_describing_data_formats_to_enable_advanced_querying_of_file_metadata/</guid>
      <description>&lt;h1 id=&#34;前日になって論文紹介の準備を始めるやつーはい俺です&#34;&gt;前日になって論文紹介の準備を始めるやつー、はい俺です。&lt;/h1&gt;
&lt;h2 id=&#34;abstraction&#34;&gt;abstraction&lt;/h2&gt;
&lt;p&gt;self-describingなファイルフォーマットのメタデータをうまく抽出して、クエリスピードを爆上げしようって話。
self-describingであるファイルフォーマット、例えば、HDF5ファイルフォーマットとか、adios2のBP5フォーマットとかは、データとそのデータに関するメタデータを含むファイルフォーマットになっている。これだと、そのファイルを読み込んでから出ないとクエリが発行できないため、利便性にかける。
&lt;!-- raw HTML omitted --&gt;
ファイルシステムをjuleaっていうのに置き換えることで、we can use dedicated backends for key-value and object stores, as well as databases.
これの意味が分からないのんだけど。どういうことなんだろう。
というか、SDDFsからメタデータを抽出して何かいいことあるのだろうか？ファイル操作がもっと簡単になるのだろうか？？そういうことなのだろうか？？&lt;/p&gt;
&lt;h2 id=&#34;introduction&#34;&gt;introduction&lt;/h2&gt;
&lt;p&gt;まあデータがますます増えていると。コンピュータの計算速度よりもI/Oがボトルネックになっている。というのは有名な話。まあ、POSIXのI/Oを使ってたらそれは遅くなるよね、、、という話もあり。
&lt;!-- raw HTML omitted --&gt;
で、データを効率よく管理するためにHDF5やAdios2といったライブラリや、特殊なフォーマットを持つファイルが登場してきた。これらのファイルは、データとそのデータに関するメタデータを含む、self-describing data formatsというもの。だから、ファイルを交換するだけですぐに使うことが可能。つまり、ポータビリティにめちゃめちゃ優れる。が、メタデータとデータが一つになっているためにデータにアクセスするにはファイルを全部読み込まないといけない、という問題が生じる。そこで、メタデータとデータを分けて保存することで、データ中の任意の部分へのアクセスが高速化される、ということだね。俺もそうだと思う。&lt;/p&gt;
&lt;h2 id=&#34;この論文の貢献-contirbution&#34;&gt;この論文の貢献 (Contirbution)&lt;/h2&gt;
&lt;p&gt;prior workでは、HDF5のメタデータとデータそのものを分けて保存することがどれくらい有益だったのかを示したわけですね。
本論文では、Adios2においてもこのようなデータの分離が有効であることを示す。ということですね。
&lt;!-- raw HTML omitted --&gt;
summary of contribution&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;BP3/BP4を分ける方法&lt;/li&gt;
&lt;li&gt;ADIOS2を改造する感じで実現した。&lt;/li&gt;
&lt;li&gt;ただのBP3/BP4の読み書きをparallel and distributedな環境で実施した時の評価を持ってきた。 って話だね。&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id=&#34;backgroundかな&#34;&gt;backgroundかな&lt;/h2&gt;
&lt;p&gt;ADIOS2が何なのか。
BP3/BP4でデータを保存するのね。
で、actual writing and reading behavior of adios2 is determinded by the used engine.ってことで、ファイルへの読み書きをする実体？？は、ADIOS側で決められるよーって話だったよね。
これいまだに信じられないんだけど、本当なのか？これはADIOSを実際に使ってみるのがいいと思う。XMLファイルで設定ができるって話だったからね。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
