Sand box on the shoulder

 Anaconda is a very useful environment for implementing Python for scientific calculations. Many people use Anaconda. However, if you keep installing and updating packages to the environment you have created, you may lose track of dependencies, and you may not be able to reproduce the environment on other computers. To prevent this from happening, create and manage your preferences file well so that anyone can reproduce a virtual environment anywhere. In this article, we will show you how to create a virtual environment from an environment settings file using Anacnoda Navigator, a GUI rather than a CUI, so that even beginners can use it. 1. prepare environment setting file (yaml file) The following is an example of an environment configuration file "env.yml". The file name can be arbitrary, but the extension should be "yml". name: test-env channels: - defaults - gurobi dependencies: - python=3.8 - gurobi - spyder - pandas - openpyxl ”name" is the

2023年8月31日、 東京理科大学 山口研究室  において、Gurobi Optimizerを用いた発電機起動停止計画（Unit Commitment: 以下UC）最適化を実施するためのPythonパッケージ 「ucgrb」 がGithub上で公開されました。 https://github.com/YamaLabTUS/ucgrb 本ブロブの管理者が代表社員を務める 合同会社「真鍋ラボ」 が本パッケージの開発・運用に携わっています。そこで、本ブログ上で本パッケージを簡単に紹介させてください。 UCとしての特徴 本パッケージは連系線で接続された複数地域の電力系統を対象として、対象期間（受渡日）のUCが確定するように、前日計画と当日計画を連続で実施することができます。たとえば、日本全国の電力系統を対象として、UCを実施することも可能です。 本パッケージのUCは混合整数線形計画法（Mixed-integer linear programming: MILP）で定式化されています。詳細な定式化内容はGithub上にある readme における「4. 最適化問題の定式化」で確認することができます。主な特徴は以下の通りです。 最適化の目的関数は最適化対象期間の全地域の総コスト最小化である。 決定変数は電力系統の各構成要素の運用計画である。 大規模発電機（火力、原子力、水力） エネルギー貯蔵装置（ESS） 再生可能エネルギー（太陽光、風力） 連系線 主な制約条件は以下の通りである。 電力系統の各構成要素の運用制約 複数地域の需給バランス制約、調整力制約、慣性定数制約 前回の最適化で決定された変数の一部を最適化対象前時間帯に引き継ぐことで、連続した最適化（Rolling Optimization）を実現しています。 シミュレーションツールとしての特徴 MILPのソルバーとして、 Gurobi Optimizer を用いています。大規模な問題を解くためには有償のライセンスが必要となります。Gurobi Optimizerの有償ライセンスがない場合でも、MILPをMPSファイル形式で出力することで、他のソルバーツールでの実施が可能となります。 また、最適化対象となる電力系統の各種パラメータはCSVファイル形式で記述され、特定のディレクトリに配置する必要があります。設定ファイルによっ

パソコンのGPUを取り替えてみたり、外付けGPUを接続してみたら、以下のようなトラブルが発生することがあります。 ディスプレイがフリーズ、または真っ黒になり、操作を受け付けなくなる 電源ボタンを長押しして、強制的にPCを落とさなくてはいけない トラブルを引き起こす特別な操作やソフトウェアは特定できない GPUのメモリ等を観察しても、トラブル発生前に以上な変動は発生しない 各種ドライブのアップデートや再インストール、PC内の掃除や接続の確認をしても治らない時があります。そんな時、試してもらいたい対策があります。 具体的には、 GPUの電源管理モードを「パフォーマンス最大化を優先」 にすれば、上記の症状が無事解消されました。具体的な操作方法を本記事で説明します。 この対策は、下記のURLでの記述内容を参考としました。 https://www.intel.co.jp/content/www/jp/ja/support/articles/000056230/intel-nuc.html ちなみに私のPC構成は以下の通りです。 PC本体: NUC10i5FNH OS: Windows 10 外付けGPUケース: AKiTiO NODE (500W) 2019 GPU: NVIDIA GeForce RTX 2060 SUPER なお、この対策はOSがWindowsであり、NVIDIA製のGPUを用いている環境が対象となっています。他の環境は対象外となっていますので、ご了承ください。 NVIDIAコントロールパネルを開く NVIDIA製のGPUがPCに接続されている場合、NVIDIAコントロールパネルがすでにインストールされているかと思います。下記の手段を用いて、NVIDIAコントロールパネルを起動してください。 画面右下のタスクトレイ内にある「NVIDIA設定」をクリックする（下図赤枠参照） 画面左下の検索領域に「NVIDIA」と入力して「NVIDIAコントロールパネル」を検索しクリックする（下図参照） 「3D設定の管理」画面を開く NVIDIAコントロールパネルを開きましたら、左側に「タスクの選択」が表示されます。この「タスクの選択」から「3D設定」→「3D設定の管理」を選んでクリックしてください。 電源管理モードを「パフォーマンス最大化を優先」にする こうして表示された設

今や、プログラミング開発に欠かせない存在となったGit。上司や同僚から「修正版をブランチ"devlop"にプッシュしたから、それを反映させてね」「安定版はタグ”v1.2”だから、よろしくね」と言われることもあるでしょう。その時に「どうやってブランチやタグって変えたらいいかわからない」「そもそも言われたブランチやタグが見当たらないんだけど…」となったら、とても困ってしまいます。そんなときにどうしたらいいか、本記事では Sourcetree を使用している環境を想定して、おすすめの手順を紹介します。環境によって具体的な操作は異なるものの、手順自体は一緒です。基本的には、 フェッチ(fetch)をしてリモートリポジトリをちゃんと確認 すればよいのです。 1. コミットしていないファイルをなくそう まず、Sourcetreeのコミット一覧に「コミットされていない変更があります」とあるかどうか確認します（下記図赤下線参照）。「コミット」の箇所に青マークでコミットされてないファイル数も表示されます（下記図赤枠参照）。その変更をコミットするか、破棄するかを行い、コミットされていない変更がない、きれいな状態にしましょう。そうしないと、後の作業中にエラー等が発生して進まなくなってしまいます。 2. フェッチしよう フェッチとは、 リモートリポジトリの最新の履歴の取得だけを行う 操作です。これによって、自分から見えていなかったブランチ・タグが見えるようになります。ブランチへのマージが伴うプッシュやプルと異なり、単に履歴を取得するだけなので、意図しないコミットが発生しません。安心して実施しましょう。Sourcetreeでは下記図赤枠部分をクリックすれば、フェッチを行うことができます。 その際出てくるポップアップで「すべてのリモートからフェッチ」「全てのタグを取得」をチェックしてください（下図赤下線参照）。 3. 目的のブランチ・タグを見つけよう 目的のブランチ・タグを見つけるのに便利なのが、Sourcetreeの左側領域にある「ブランチ」「タグ」「リモート」「スタッシュ」です。目的のブランチを探したい場合は「リモート」をクリックして現れる「origin」をさらにクリックしましょう。これでリモート上にあるブランチの一覧を見ることができます。タグの場合は「タグ」をクリック

日本卸売電力取引所（JEPX）が市場取引を開始したのが2005年4月、東日本大震災を契機とした電力システム改革が実施されたのが2015年から2020年にかけてです。このように電力事業の規制緩和が進んでいる中、実際に電力市場の取引量がどれくらい増えたのでしょうか？ 現在の電力市場の状況がわかりやすくまとまっているのが、経産省の 電力・ガス取引監視等委員会 で定期的に開催されている 制度設計専門会合 です。月１程度の頻度で実施されており、３ヶ月に１度「⾃主的取組・競争状態のモニタリング報告」という報告書が公表されています。最新の 令和３年4⽉〜令和３年6⽉期の報告書 に記載されている電⼒需要に対する市場取引量の推移グラフを以下に示します。 図より、 2017年くらいから一気に増えて、2019年位から40％前後を推移 していることがわかります。すでに電力需要の半分近くの量が電力市場を介して取引されているんですね。 それでは、2017年から一気に市場取引が増えた理由はなんでしょうか？それは、2017年4月から実施された 「グロス・ビディング（gross bidding）」 にあります。グロス・ビディングとは、旧一般電気事業者の社内取引分の一部をスポット市場を介して取引するように変更することです。その結果、上記の図のように市場取引量が一気に増加しました。 グロス・ビディングは市場の流動的向上、価格変動の抑制や透明性の向上を期待されて導入されました。 2021年8月の報告書 では市場の流動的向上、価格変動の抑制に関しては一定の効果を得られたが、透明性の向上に関してはまだ不十分であり改善の余地があると報告されています。 参考URL JEPX ( http://www.jepx.org/index.html ) 電力・ガス取引監視等委員会 ( https://www.emsc.meti.go.jp/ ) 第65回 制度設計専⾨会合 事務局提出資料 「⾃主的取組・競争状態のモニタリング報告（令和３年4⽉〜令和３年6⽉期）」( https://www.emsc.meti.go.jp/activity/emsc_system/pdf/065_10_01.pdf ) リム情報開発 「グロスビディング」（ https://www.rim-intelligence.co.jp/glossary

Pythonのコーディングを進めていくと、改行の位置や空白の置き方などに一定のルールに従って記載したくなってくるかと思います。特に多人数で共同で開発を進める場合、それぞれが独自のルールと感性でコーディングをしていきますと、フォーマットがバラバラになってしまいます。この違いは他の人のコードを確認するときのストレスの元になってしまいます。 その問題を解決する方法の一つに 「コーディングルールを決める」 という手段があります。このルールに則っていたら、大丈夫、もう文句は言わない！という決め事をしてしまえば、もうその事で言い合いになる心配はありません。プロジェクトの目的そのものに集中することができます。Pythonには PEP8 という一般的に用いられるコーディング規約があります。多くのコードがこのPEP8に基づいて作成されています。このPEP8に則っているかどうかをチェックして、自動に整形してくれる フォーマッター がPythonのパッケージとしていくつか公開されています。その中で、筆者が一番オススメなのが " black " というパッケージです。 Pythonのコンソール上で、 整理したいファイルのあるディレクトリに移動し、以下のコマンドを実行してみましょう。 black . これで、現在のディレクトリ以下にある全てのPythonファイルを自動で整形してくれます。blackは他のフォーマッターと違って、元となるPEP8よりも厳しいルールを用いており、オプションでもそのルールをほとんど変更することができない、という特徴を持っています。もともとPEP8は結構融通の効くルールなので、どうしても人によって書き方がバラけてしまう、という問題があります。それならば、ガチガチに固めてしまいましょう、という思想のフォーマッターです。そこまでコードの綺麗さにこだわりがない筆者にとっては、余計な事を考えずに全てのコードの形式を統一できるので、非常に助かっています。 「コマンドが見つかりません」と表示されて実施できない場合 blackがインストールされていない環境のようです。環境管理にpipを用いている場合は、以下のコマンドを実行してみて、現在の環境にインストールされているパッケージを確認してみましょう pip list リストの中にblackがない場合、pi

科学計算のためにPythonを実施する際にとても便利な環境がAnacondaです。多くの方々が利用しているかと思います。しかし、せっかく作成した環境にどんどんとパッケージをインストール、アップデートしていってしまうと、依存関係がわからなくなってしまい、他の計算機で環境を再現できなくなってしまうこともあります。 そうなることを防ぐために、環境設定ファイルをしっかりと作成・管理して、だれでもどこでも仮想環境を再現できるようにしましょう。本記事では、初心者でも利用できるようにCUIではなくGUIであるAnacnoda Navigatorで環境設定ファイルから仮想環境を作成する方法を紹介します。 1. 環境設定ファイル(yamlファイル)を用意する 環境設定ファイル「env.yml」の記述例を以下に示します。ファイル名は任意で大丈夫ですが、拡張子はymlとしておきましょう。 name: test-env channels: - defaults - gurobi dependencies: - python=3.8 - gurobi - spyder - pandas - openpyxl "name"は仮想環境の名前です。この環境を使う目的など、わかりやすい名前をつけましょう。日本語だと上手に反映できない場合がありますので、基本、アルファベットでつけましょう。 "channels"ではパッケージのダウンロード元となるチャンネルを指定します。多くのパッケージは”defaults”が書いてあれば問題ありませんが、特定のパッケージは特別にチャンネルを指定する必要があります。使用したいパッケージがどこからダウンロードできるか、確認しておきましょう。 ”dependencies”は、この環境にインストールしたいパッケージを指定します。基本的に最新版をインストールしますが、バージョンを指定したい場合には、パッケージ名の後ろに"="をつけて、バージョンを指定しましょう。 この環境設定ファイルを作成したプログラミング毎に管理するようにしましょう。プログラミング１つに対して１環境です。プログラミングをGitで管理している場合は、環境設定ファイルをGitの追跡対象に追加することで、自然に一緒に管理すること