👰🏽 🌏 ♎️ ヒナギクの惑星のモデリング 🚍 🚵🏻 👨🏾‍🎤

ヒナギクの惑星のモデリング

歌詞
インターフェースの説明
分解
モデル
ロジック

1.歌詞

むかしむかし、どこか覚えていません。1つの驚くべき実験について学びました。説明の始まりは次のとおりでした。地球のような惑星を想像してください。地球上には生命が存在しますが、それほど多様ではありません-ヒナギクは黒と白の2種類しかありません。提示？なんてコール！作者はハンサムで、ほとんどex辱的です。

実験についてさらに説明しました。開始点では、ヒナギクは種の形でしかなく、惑星は非常に寒いので、赤道では温度が生存の危機にonしています。それにもかかわらず、いくつかの黒と白のヒナギクが発生し、それらは咲き始めます。白いデイジーは、反射率が高いため、緑の葉や茶色の土よりも多くの光を反射します。この場所では局所的に寒くなり、凍結します。反対に、黒いデイジーの周りには、星からより多くのエネルギーを吸収するため、小さなウォームアップゾーンが表示されます。デイジーは気分が良くなり始め、咲き、そして暖かい地面に種を投げます。いくつかの黒いヒナギクがこれらの種子から発芽します（親が黒いため）、これらのヒナギクの開花は、より多くのヒナギクが成長できるさらに広い領域を温めます。

このように、黒いヒナギクの開花によって引き起こされる温暖化は、黒いヒナギクのさらに大きな広がりを引き起こし、そのヒナギクは、周囲の領域よりもさらに暖まります。このように、黒いヒナギクは赤道地域をキャプチャしますが、それ以上広がることはできません-それはそこであまりにも寒いです。

しかし、このような黒いヒナギクの急速な開花は、惑星全体（アルベド）の反射率を低下させ、これは惑星規模での吸収/反射エネルギーのバランスに影響し、惑星の有効温度の上昇につながります。つまり、惑星全体で暖かくなります。その後、黒いヒナギクは南北に少し領土を広げ、さらに地球温暖化につながります。したがって、黒いヒナギクは極点に向かって進み、惑星は暖まります。

しかし、忘れないでください-地球は暖かくなりました、そして今、成長と白いヒナギクのためのすべての条件もあります。さらに、暖かくなると赤道で熱くなり、黒いヒナギクは周囲の地球をさらに暖め、この地域ではますます不快になります。それは白いヒナギクのようではありません。白いヒナギクはより多くのエネルギーを反映し、それらの周りに彼らがよく成長し、そこで種を捨てる快適な涼しいゾーンを作ります。さて、あなたはアイデアを得る-白は赤道から黒を絞っている。しかし、ここで驚きです-惑星のアルベドは白いヒナギクの広い領域のために再び増加しています、惑星はより寒くなって、最終的にいくらかのバランスがあります。

さらに、著者はヒナギクのためにこの退屈で快適な状態に惑星を残すつもりはありません。これが起こることです-彼らが通常行うように、星はより明るく輝き始め、より多くのエネルギーが惑星に落ちています。惑星の反応は、白いヒナギクの分布面積の増加、アルベドの増加、有効温度の減少、および新しい平衡状態への移行です。星の光度が低下しても、ほぼ同じことが起こり、黒いヒナギクだけが現れます。

著者が描いた結論は、生物圏自体が広い範囲の星の光度で惑星に快適な温度条件を作り出すということです。この素晴らしい実験の著者はジェームス・ラブロックとアンドリュー・ワトソンです。誰がすべての結論とより詳細な説明を気にするのか、Wikipedia- Daisy Worldを参照してください。この長い紹介の意味は、Wikiから記事を再説することではなく、最も興味深いこと、つまり実験を直接行うことです。実験を説明する記事の著者は修辞的な質問をしました：推論は論理的に見えますが、そのような実験を行う方法、適切な条件で星のある惑星をどこで手に入れ、そこにデイジーの種を届けるか？たとえ誰かがこれに火星を使うことを考えても、彼は成功しません。私はテラフォーミングとクールな実験の大ファンだったので、このターンにとても悲しみました。しかし、著者は、私の大きな喜びに、そのような実験はコンピューターシミュレーションを使用して可能であると言いました。

もちろん！この実験は、実際にはコンピューターモデリングのために発明されたものであり、その目標を達成しました（つまり、そこにいる2人の賢者を恥じました、wikiを参照）。この実験の物語の中で、私は息を切らしました。なぜなら、この説明を見て、アイデアを視覚的で、リアルタイムで見るためにアクセスできる何かに変える幸運な人のことを考えたからです。手。」さらに、モデリングプロセス自体と実験の両方が興味深いものでした。実験を読んで結論に驚くことは一つのことですが、この惑星で「遊ぶ」こと、異なる条件で実験することは別です。しかし、それでも私はまだプログラムできませんでした:(しかし、幸いなことに時が来たので、長く退屈な歌詞からコンテンツ部分に移動することを提案します。惑星で遊んでみたい人は、インターフェースを説明し、その部分に興味がある人分解と呼ばれます。

2.インターフェースの説明

左の部分には2つのPopulatorブロックとUpdaterブロックがあり、中央の部分には惑星といくつかのパラメーターの視覚的な表示があり、有効な温度と星定数の変化のグラフの右の部分にあります。

管理は、PopulatorブロックとUpdaterブロックで実行されます。

Populatorブロックでは、白いヒナギク、黒いヒナギク、空のセルの比率を設定できます。[Populate]ボタンをクリックすると、それに応じて惑星にデータが入力されます。惑星は、実験の開始時と必要に応じていつでも投入できます。

Updaterブロックは、惑星モデルの更新を担当します。このモデルでは、一度に更新の数と値（負の許容値）および恒星定数をインクリメントする頻度を設定できます（たとえば、2回の反復ごとに恒星定数を1ずつ増やしながら100回更新します）。

惑星の視覚的表示：

白い円は白いヒナギクのある領域で、黒い円は黒い、オリーブは空のセルです。

左上隅には、ケルビン、恒星定数、アルベド、反復回数による有効温度の現在の値があります。

惑星の右側には2つのカラースケールがあります。左は黒のヒナギク、右は白です。スケール上の各ポイントは、ベルトの反対側の惑星の温度に対応しています。伝説は次のとおりです。青は生きるには寒すぎ、黄色は生きることができ、緑は生きることができるだけでなく快適で、赤は生きるには暑すぎます。

3.分解

アプリケーションはMVCパターンを使用しましたが、JavaFXでは、ご存知のとおり、ビューとコントローラーは少しくっつきましたが、モデルの境界は非常に明確に輪郭が描かれています。

モデルは、いわば、最高の伝統において、国家に責任を負う部分と、行動に責任を負う部分に分けられます。データベースに結果を保存する部分がまだありますが、うまくいくように見えますが、インターフェースや設定から不要なものとして除外していません。永続性のタイプとレイヤーについては説明しません。以下は、モデルと動作についてのすべてです。

4.モデル

モデルは、Planet、Starr、Zone、Conditions、BlackDaizy、WhiteDaizy、NoDaizy、抽象Daizy、および列挙型の6つの通常クラスで表されます。少人数のクラスでも可能ですが、星はとても大きくて重要なので、クラスなしで放置するとbeいものになると思いました。また、ヒナギクについては、「ヒナギクの惑星」と呼ばれるプログラムで、クラスの全体的な小さな階層が構築され、さらにはリストが導入されました。したがって、状態を定義する主なクラスは、Planet、Conditions、およびZoneです。

Planet-メインの集約クラスです。アプリケーション内のこのクラスのインスタンスはモデルの役割を果たします。コントローラーはビューの状態を取得し、動作を担当するクラスはPlanetインスタンスへの参照を取得して状態を変更します。

Planetクラスには、惑星の状態を特徴付けるフィールドが含まれています：this

/**  ,      */ private double albedo = 0;

  /**  :    , *         -*/ private double temperature = 0;

  /**    */ private double radius = Conditions.getInstance().radius;

 /**       ,      ,      —  */ private int halfZonation = Conditions.getInstance().halfZonation;

  /**  :     ,    -   ,    ,   ,        , *  - */ private long daiziesPerZone = Conditions.getInstance().daiziesPerZone;

 /**   -            ,     */ private double effectiveArea; /**  .    area -  S = 2πrh, r –  , h –   . */ private double zoneArea; /**    ,  */ private double daisyArea;

さらに、Planetクラスには、Starrスターへのリンク、Zoneクラスインスタンスの配列、各要素が個別のベルト、更新カウンター、居住標識、つまり惑星が居住しているかどうかを特徴付ける配列が含まれています。また、動作を担当するクラスへのリンク

  PopulatorImpl populator = new PopulatorImpl(); AlbedoCalculator albedoCalculator = new AlbedoCalculatorImpl();

以下で説明します。

2番目の重要なクラスは条件であり、すべての定数が含まれています。ここにいくつかあります

 public double Kelvin = -273.15; // Planet constants public double radius = 1000.0; public int halfZonation = 90; public long daiziesPerZone = 100; /**  :       ,             ,          ,    ,  ..           - ,    ,  -  , , ,    */ public double planetDeltaTemper = 70.0; /*     */ public double blackDaisyAlbedo = 0.1; public double whiteDaisyAlbedo = 0.9; public double noDaisyAlbedo = 0.5; /*       ,       , */ public double blackComfortableTemper = 18 + (-Kelvin); public double whiteComfortableTemper = 22 + (-Kelvin); /**  -    ,    , *   ,        *      1367 /²*/ public double StarConstant = 1367.0; /**   - * */ public double StephanBoltsmanConst = 5.67e-8;   ,      Zone: /**      */ private double latitude; /**   -      , *     */ private double effectiveArea; /**   */ private double height; /**      zone*/ private double localTemperature; //   private long numBlackDaisies; private long numWhiteDaisies; private long numEmptyCells;

ローカル温度の設定方法に注意し、上記のように温度を計算します。

 public void setLocalTemperature(double globalTemperature) { this.localTemperature = globalTemperature + Conditions.getInstance().planetDeltaTemper*Math.cos(latitude); }

状態を計算するメソッドはクラスにありません。すべてのフィールドの値はコンストラクターパラメーターに渡されるか、セッターによって設定されます。

5.ロジック

ほとんどすべての動作はロジックパックに収集され、次のクラスで表されます。

ZoneMaker-クラスは、異なる惑星が異なるフラグメンテーション（ゾーンの数）を持ち、各ゾーンが配列のインデックスに対応する独自の緯度を持っているという事実を考慮して、惑星ゾーンの配列全体を作成するために使用されます

AlbedoCalculator-インターフェース、唯一の方法

  double calcAlbedo(Zone[] zones);

その実装は、黒と白のヒナギクと空いているスペースの比率、およびそれらの位置に応じて、惑星全体のアルベドを計算するために使用されます-異なる緯度で成長するヒナギクは、アルベド全体に異なる貢献をするためです。

StephanBoltsman-惑星の有効温度を計算するためのクラス。

Populator-惑星にヒナギクを住まわせるインターフェイス。

方法

 void populate(Zone zone, int whiteExpectance, int blackExpectance, int noneExpectance);

パラメータ、ゾーン、パラメータで転送されたものを埋めるためのものです

 int whiteExpectance, int blackExpectance, int noneExpectance

数学的な期待のようなもので、比率に応じて、白と黒のヒナギクがゾーンの周囲にランダムに植えられるか、パスが作成されますが、ゾーン内のヒナギクのセルの総数は常に一定であり、初期設定に依存します（ 条件が設定されますdaiziesPerZone ）。

この方法は、地球上のすべてのゾーンを既に埋めている他の2つの方法で使用されます。

 void populateInitial(Zone[] zones, int whiteExpectance, int blackExpectance, int noneExpectance);

すべてのゾーンを同じ比率で塗りつぶします。惑星のコンストラクターにはパラメーター0,0,1があります。つまり、惑星は無人で作成されます。

方法

 void rePopulate(Planet planet);

ヒナギクをヒナギクで押しつぶし、空きスペースを埋めるメカニズムの実装です。これは、惑星の一般的な条件に応じて、惑星にヒナギクを再配布するために使用されます。このメソッドはおおよそ次のように機能します。3つの変数を定義します。まず、次のゾーンの白、黒のヒナギク、および空のセルの数の値を設定します。

さらに、いずれかのタイプのデイジーの温度が生活条件を満たさない場合、対応するパラメーターがリセットされます。生活条件を満たしている場合、値は変更されません。温度が快適な範囲内にある場合、値は2倍になります。温度が最初にあらゆる種類のヒナギクの生活に適したものになった場合、対応するパラメーターは、隣接するゾーンからの対応するヒナギクの数の算術平均に設定されます。

最後に、Planetクラスのupdate（）メソッドを記述する必要があります。これは、各反復のライフサイクルを担当します。

 public void update() { albedo = albedoCalculator.calcAlbedo(zones); temperature = StephanBoltsman.countTemperature(albedo,star.getStarConstant()); updateLocalTempers(); populator.rePopulate(this); iterationId++; }

まず、惑星のアルベドはヒナギクの数と位置に基づいて計算されます。次に、発見されたアルベドと恒星定数（値も変更可能）を使用して、惑星の有効温度が計算されます。次に、検出された有効温度に基づいて、ゾーン内のローカル温度の値が更新されます。そして最後に、新しいローカル温度データを使用して、ヒナギクの再配布が実行されます。

gitへのリンク。アセンブリ：gradlew build

ヒナギクの惑星のモデリング