TRNSYSコンポーネントのPrintデバッグ

あまり需要がある話とは思えないですが、備忘のためまとめておきます。

プログラムをデバッグする方法としてPrintデバッグというのがあります。名前の通り処理の途中にデバッグ用の出力を入れて画面やファイルに書き出して値をチェックするという古典的な方法です。

ファイルに書き出す方法として、TRNSYSにはリストファイル(.lst)へ書き出すAPI、writeToList()が用意されています。これを使って、次のようにコーディングするとリストファイルへの書き出しが行えます。

power_rated = getParameterValue(3)
Call writeToList(‘—– PRINT DEBUG —–‘)   ! コメントの書き出し
write (messageText,'(f10.3)’) power_rated   ! 値を文字列に変換
Call writeToList(messageText)                     ! .lstファイルへ書き出し

なぜか今朝、コンパイラのデバッグモードが使えなくなってしまったため、Printデバッグを使って見ました。TypeStudioでデバッグしようとすると、いまのところこの方法かな?

動作環境

以下の環境で動作を確認しています。
Windows10 Pro(64bit, 1803)
TRNSYS18.00.0019(64bit)

新しいTRNSYSコンポーネントを作成する

前回のつづきです。

サンプルのプロジェクトを利用して新しいコンポーネントを作成する手順の紹介です。この例ではサンプルプロジェクトを元にType202を作成しています。

※予めGithub/TRNSYS.JPから関連するファイルをダウンロードしておいてください。

1 作業フォルダの準備

はじめにサンプルのプロジェクトをコピーして作業用のフォルダを用意します。

フォルダ(”C:TRNSYS18CompilersMyType201″)をコピーして名前をMyType202へ変更します。

image

2 ソースコードの準備

Simulation Studioで新しいType(MyType202)のプロフォルマを作成、FORTRANのソースコード(Type202.f90)を同じフォルダへエクスポートして置きます。

image

3 プロジェクト名の変更

Visual Studio 2017を起動して、ソリューション(MyType.sln)を開き、プロジェクト名をMyType201からMyType202へ変更します。

image

※このプロジェクト名の変更で、出力されるDLLの名前がMyType202.dllへ変わります。

4 ソースコードの差し替え

既存のソースコード(Type201.f90)をプロジェクトから削除(クリア)する。

image

image

Source Filesフォルダを選んで、右クリックから[追加]-[既存の項目]で、先ほど追加した新しいソースコード(Type202.f90)を追加する。

image

ソリューションエクスプローラーの表示が以下のようになっている事を確認する。

image

以上でプロジェクトの準備は終了です。Type202.f90へ処理内容を記述して、無事ビルドできれば完了です。

動作環境

以下の環境で動作を確認しています。
Windows10 Pro(64bit)
Intel Parallel Studio XE2018 Update2
Visual Studio 2017(ver15.7.1)
TRNSYS18.00.0017(64bit)

Intel Parallel Studio XE2018でTRNSYSコンポーネントをビルドする

Intel Parallel Studio XE2018 Fortran でTRNSYSコンポーネントをビルドする際のプロジェクト設定のメモ。

TRNSYS18からTypeStudioがリリースされたので使うケースは減りそうですが、複雑な計算を実装するようなケースではIntel Parallel Studio XE2018は強力なツールです。

※XE2018 で検証していますが、それ以前のバージョンでも項目自体は変わっていないので設定内容は一緒です。

2018/5/15 追記

Gitub/TRNSYS.JPでサンプルのソースコードとビルド用のプロジェクト、テスト用のTPFを公開しました。

●TRNSYS.JP/TRNSYS18/Compilers/MyType201

ソースコードとビルド用のプロジェクト一式

●TRNSYS.JP/TRNSYS18/Studio/Proformas/MyComponents/MyType201

プロフォルマ(*.tmf)

●TRNSYS.JP/TRNSYS18/MyProjects/MyType201Project

テスト用プロジェクト一式

1    プロジェクト設定

Fortran,リンカーの主な設定項目を以下に示す。以下、Release、Debugで設定が異なる項目については併記しています。

1.1    FORTRAN
1.1.1    追加のインクルード・ディレクトリー
● Release

image

● Debug

image

1.1.2    データ
● すべての構成

image

1.1.3    浮動小数点
● すべての構成

image

1.1.4    外部プロシージャ
● すべての構成

image

1.1.5    ライブラリー
● Release

image

● Debug

image

1.1.6    ランタイム
● Release

image

● Debug

image

1.2    リンカー
1.2.1    全般
注)「追加のライブラリー・ディレクトリー」のみ設定が異なる。
● Release

image

● Debug

image

1.2.2    入力
● すべての構成

image

※「全般」「追加のライブラリー・ディレクトリー」でRelease,Debugで参照先が変わるように設定している。このためTRNDll64.libはビルドのモードに応じて適切なライブラリが参照される。

2018/05/15追記

TRNDLL64.libはあらかじめ”C:TRNSYS18CompilersTRNSYSTRNSYS.sln”を開いてRelease,Debugの両方のモードでビルドしておいてください。

1.3    ビルドイベント
1.3.1    ビルド後のイベント
● Release

image

● Debug

image

動作環境

以下の環境で動作を確認しています。
Windows10 Pro(64bit)
Intel Parallel Studio XE2018 Update2
Visual Studio 2017(ver15.7.1)
TRNSYS18.00.0017(64bit)

TRNSYS18のTypeStudioとIntel Visual FORTRAN

TRNSYS18からコンポーネントの開発用の専用ツール(FORTRANコンパイラ)が標準添付します。コーディングからビルド、DLLの配置まで手軽にできるので、コンポーネントの開発が非常に楽になります。

image

とはいえ従来のIntel Visual FORTRAN(以下、IVF)で行っていたコンポーネント開発に比べて制限もあります。主な項目を比較してみました。

機能 TRNSYS/TypeStudio Intel Visual FORTRAN
コンポーネント開発
デバッグ ×
TRNDLLリビルド ×
32bitコンポーネント ×
64bitコンポーネント
外部ライブラリ ×
DLL配置

ちょっとした開発にはTypeStudio、本格的な開発にはIntel FORTRANというところですかね。

開発するコンポーネントの内容や使用環境に合わせて、ケースバイケースでどちらを使うか検討しましょう。以下、表の各項目をもう少し詳しく解説します。

コンポーネント開発

TypeStudio,IVFのどちらでもコンポーネントの開発が可能です。

デバッグ

TypeStudioでは処理の途中で変数の値を調べたり、ステップ実行したりと言った、いわゆるデバッガーの機能がありません。(そのうち付くかも知れないですが。。。)
一方、IVFはもともと本格的な開発ツールなので、非常に強力なデバック機能を備えています。

TRNDLLビルド

TypeStudioはコンポーネントの開発専用です。TRNDLL(TRNSYSの本体)のビルドには対応してません。IVFでは従来通り、TRNDLLのビルドが可能です。

32bitコンポーネント

TRNSYS18よりTRNSYSは64bit化(※)されています。このため、今後は32bitのコンポーネントを作る機会は少なくなると思います。TypeStudioは64bit版のツールのため,32bitコンポーネントにビルドには使用できません。IVFでは従来通り32bitコンポーネントのビルドが可能です。※32bit版のOSに対応した32bitはサポートサイトよりダウンロードできます。

64bitコンポーネント

TypeStudio、IVFともに64bitコンポーネントのビルドが可能です。

外部ライブラリ

コンポーネントによっては外部のライブラリ、例えば数値計算や他のシミュレーションソフトウェアのライブラリを参照したいケースがあると思います。IVFは汎用的なツールでなので問題ありません。
TypeStudioは専用ツールのため参照できません。

DLL配置

TypeStudioではビルドしたDLL(コンポーネントの本体)をTRNSYSのフォルダに自動的に配置します。フォルダの構成を意識せず、すぐにSimulation Studioで配置、利用することができます。IVFではビルドのモード(Release,またはDebug)に合せて、出力先を調整します。

以上、TRNSYS18.00.0012で確認

TRNSYS18 新機能概要(2)パッケージ構成、TypeStudio

前回に引き続き、TRNSYS18の新機能概要です。ドキュメントの改訂と新しく追加されたTypeStudioのご紹介です。

2. パッケージ

2.1. TRNSYSを有効活用するためのドキュメント

マニュアルのほとんどが、初心者がTRNSYSを使い始める際に役立つように書き直されています。 既存のチュートリアルのドキュメントを別のボリュームに移動し、さらに詳細な建物/ HVACプロジェクトを含む新しいチュートリアルを追加しています。多くの例題が追加され、詳細なドキュメントとともにまとめられています。 Mathematical referenceでは、パラメーター/入力/出力項目と各コンポーネントを使用するためのヒントとコツが追記されました。

補足解説

今回のバージョンでは、より分かり易いドキュメントがテーマの一つになっています。初心者向けとありますが、TRNSYSの初心者という意味なので、チュートリアルは割としっかりした内容になるようです。

2.2. 統合型TRNSYS専用Fortranコンパイラ(TypeStudio)

TypeStudioは、新しいType(コンポーネント)を簡単に作成するためのグラフィカルインターフェースとFortranコンパイラから構成されます。

TypeStudioでは、作業用に1つまたは複数のTypeを含むワークスペースを作成、および管理します。ユーザーはこれを使って、TRNSYSエンジンがシミュレーションで使用可能なダイナミックリンクライブラリ(DLL, Dynamic Link Library)をビルドし、適切なフォルダに配置することができます。

image

補足解説

FORTRANコンパイラが標準添付になります。しかもTRNSYSのコンポーネント作成に特化したツールになっているので、簡単な操作でコンポーネントのコーディング(記述)、ビルド、フォルダへの配置が行えます。従来は別途 Intel FORTRANコンパイラを入手する必要がありましたが、TRNSYSのパッケージの中に専用のコンパイラが含まれます。気軽にコンポーネントが作れるので、Equationでは少々難しい計算は試しにコンポーネントにしてしまうことも簡単です。

とはいえ、TRNSYS本体(TRNDLL.DLL)のビルドには引き続きIntel FORTRANが要るようです。また、複雑な処理を行うコンポーネントの開発にはIntel FORTRANのような強力な開発環境は力を発揮します。目的によって使い分ける事になると思います。

動いたけど半信半疑

TRNSYSでコンポーネントを作る際には、計算そのものの実装の他、計算に使う入力やパラメータなどの値をTRNSYSの本体(Kernel)から取得します。この処理はTRNSYSに予め用意されている関数を使って行います。ほとんど場合は実数値を取得するのですが、まれに文字列を取得したいことがあります。例えば実行中のDckファイルをコンポーネントで取得する場合、getDeckFileName()という関数を利用します。

C/C++から関数を呼び出す

TRNSYSの関数はFOTRANからの呼び出しを前提にしています。このためC/C++のような別の言語からの呼び出しは一工夫要ります。
もっとも実数値であれば慣れれば、それほど難しくもないのですが、困るのが文字列の扱いです。そのあたりの事情と対策は以前にまとめています。 参考:TRNSYSの関数をC/C++から呼び出すと動かない この方法でFORTRAN側でC/C++用の関数を用意することで対応はできるものの、TRNDLL.DLLのビルドが必要になります。それはそれでハードルが高い。なにかC/C++だけでなんとかならないかと思っていたのですが、たまたま見たサイトに、そのものずばりを見つけました。

Returning a CHARACTER String

Passing strings between C and Fortran routines is not encouraged. However, a Fortran character-string-valued function is equivalent to a C function with two additional first arguments–data address and string length. The general pattern for the Fortran function and its corresponding C function is:

Fortran function
CHARACTER*n FUNCTION C(a1, …, an)

C function
void c_ (result, length, a1, …, an)
char result[ ];
long length;

出典:Fortran Programming Guide Chapter 11 C-Fortran Interface より抜粋
このリンク先の最後の方に記載があります。

なんと関数呼び出しの引数に文字列と、その長さを受け取るための変数を追加するだけ。こんなシンプルなというか、暗黙の変換があるのがそもそも驚きです。(リンク先の記載の感じだと割と一般的な処理っぽい)半信半疑でgetDeckFileName()を例にヘッダーを書き換えてみます。

extern “C” __declspec(dllimport) int    _cdecl TRNSYSFUNCTIONS_mp_GETMAXPATHLENGTH(void);
extern “C” __declspec(dllimport) char*    _cdecl TRNSYSFUNCTIONS_mp_GETDECKFILENAME(char* dck, size_t len);

赤い文字の部分が書き加えた部分です。getDeckFileName()に加えて、getMaxPathLength()も書き換えています。これはファイル名を取得する際にファイル名の最大長が必要になるため使用します。(ヘッダーの雛形の定義が間違っていて、そのまま使うとエラーになります。かならず書き換えましょう)

そしてC/C++から呼び出す

実際にC/C++から呼び出してみた例が以下になります。
fnameにはNULL終端していない固定長の文字列が返ってくるので、念のためトリミングの処理をしています。

これで最終的に std::string deckFileName にトリミングされたファイル名が入っていればOKという事になります。

size_t maxlen = getMaxPathLength(); // ファイル名の文字列の最大長を取得
char *fname= new char[maxlen];  // ファイル名を受け取る変数を用意する
getDeckFileName(fname, maxlen); // ファイル名を取得
std::string deckFileName = trim(std::string(fname,0,maxlen)); // 念のためトリミングする
delete[] fname; // 変数を削除

ちなみにトリミング処理は、こんな感じで実装
std::string trim(const std::string& str)
{
size_t first = str.find_first_not_of(‘ ‘);
if (std::string::npos == first)
{
return str;
}
size_t last = str.find_last_not_of(‘ ‘);
return str.substr(first, (last – first + 1));
}

結果

で、実際動かしてみたら無事に目的の文字列が取れました。

image

拍子抜けするぐらいあっさりと動きました。逆に不安になるぐらい。これで長年の課題がようやく解決できた。(本当か?)

TRNSYSコンポーネントを作成される方へ

ここまでのあらすじ

FORTRANコンパイラの最新版Intel Parallel Studio XE 2017(以下、XE2017)で、TRNSYSのコンポーネントの雛形が変換できなくなってしまいました。対策として既存プロジェクトを基にしてプロジェクトを構成する方法を検討しました。 File:FortranCardPROJ039.agr.jpg 昔のFORTRANのパンチカード

原因

その後、XE2017のサポート窓口にこの件をレポートしていたんですが、どうも日本語環境でのみ発生する現象のようです。引き続き原因調査をしていただけるという事で、もうしばらく時間が掛かりそうです。(XE2017のサポートの方が実に丁寧に対応いただいているので、じきに直るのではないかと) 当面は既存のプロジェクトを使う方法で対策できるので、実害はないのですが、特定の環境で発生する現象ってあるんですね。 なお、XE2016,XE2015では問題ありません。これらのバージョンをお使いであれば、しばらくはそのまま使われるのがおすすめです。

続FORTRANコンパイラが。。。

前回までの話

なぜかIntel Parallel Studio XE 2017(以下、XE2017)でTRNSYSのコンポーネントのプロジェクトが変換できなくなってしまいました。(詳しくはこちら

なにか条件があるのかもしれませんが、どうもうまく変換できません。変換がダメなら、ドキュメントを参考にスクラッチから新しく作ろうかと思いましたが、それもいろいろ設定が細かくて面倒です。(vol 7.Programmer’s Guideに記載されています)
もしかして変換が不要な既存のプロジェクトを元に修正すれば簡単なのではと思いついて試してみました。

プロジェクトを準備する

TRNSYSにはXE2017より少し前のバージョン、XE2011のソリューション(IvfCXE2011.sln)が添付されています。COMPAQ Visual Fortranに比べたらかなり最近のバージョンなのでプロジェクトの変換が不要(※)です。これに含まれているプロジェクトを元に新しいコンポーネント用のプロジェクトを作成してみます。

※「ソリューション」としてはバージョンが違うので変換が必要になりますが、ここでは「プロジェクト」を使うので、特に変換なしで作業できます。

以下、すでにプロフォルマからExportしたソースコード(Type201.for)がある前提で話を進めます。

まずは、IvfCXE2011.slnの所在を確認します。「C:TRNSYS17Compilers」フォルダにある「IvfCXE2011」フォルダがそれです。

image

このソリューションはTRNDLL、その他をビルドするものなので、さらに3個のプロジェクト(フォルダ)が含まれています。

image

ここから「MyType」フォルダを丸ごとコピーして雛形として流用します。コピーしたら分かり易いように「MyType201」といういう名前にリネームしておきます。

image

さらにフォルダの中身を覗くとプロジェクトファイル(.vfproj)があるので、これも分かり易いように「MyType201.vfproj」にリネームします。

image

さらにSimulation StudioからExportしたソースコードを同じフォルダに放り込んだら準備完了です。

image

XE2017(画面はVisual Studio2015で起動)を起動。先ほど用意したプロジェクト「MyType201.vfproj」を開いて、「Sourace Files」フォルダへソースコード「Type201.for」を追加します。

image

プロジェクトのプロパティ変更

あとは、追加したソースコードに合せてプロジェクトの設定を何カ所か変更します。

[プロジェクト]-[プロパティ]で設定画面を表示して、以下の赤枠の項目を変更します。構成「Release」で、「リンカー」の出力ファイルの項目をプロジェクト名に合せて「MyType201.dll」へ変更します。

2017/10/19 追記
ここは $(OUTDIR)$(ProjectName).dll としておくとプロジェクトと同じ名前でDLLが出力されます。プロジェクト名と揃える場合に便利な指定方法です。

image

つづいて「ビルドイベント」のコマンドラインのファイル名を同じように変更します。

image

2017/10/19 追記
ここも copy $(OutDir)$(ProjectName).dll  C:TRNSYS17UserLibReleaseDLLs*.*  とするとプロジェクト名と同じ名前で扱われます。

【重要】構成「Debug」も忘れずに同じように変更を行います。

あとはビルドして、「C:Trnsys17UserLibReleaseDLLs」フォルダにMyType201.dllができあがっていれば無事成功です。

image

これでType201が利用できる状態になったので、TRNSYSのプロジェクトから呼び出して計算に利用できます。

もっと面倒なのかと思ったけど、なんとかなった。 さらにこのプロジェクトをソリューション(IvfCXE2011.sln)へ追加しておくと、TRNDLL.DLLのビルドも同時にできてDebug、Releaseモードの切り替えが楽になります。

複数のコンポーネントを開発する場合には、同じ手順でプロジェクトを作成、まとめてソリューションへ登録しておくと、ソースコードのメンテナンスがやりやすくなります。

FORTRANコンパイラが。。。

2017/06/27 追記

この件、XE2017 Update4で修正されています。以下の環境で確認済み。
TRNSYS17.02.0005
XE2017 Update4
Windows10 Pro (64bit)

TRNSYSのコンポーネントを作成するのに欠かせないIntelのFORTRANコンパイラ。その最新版、Intel Parallel Studio XE 2017(以下、XE2017) でプロジェクトの変換がうまくいかないようです。

詳しくは以前に書いた、「作ってみようTRNSYSコンポーネント(3) ソースコードの生成」の手順に従って「COMPAQ Visual Fortran プロジェクト項目の抽出」を実行する必要があるんですが、その処理がうまくいかないようです。

これSimulation StudioからExportされたCOMPAQ Visual Fortran形式のプロジェクトをXE2017形式へ変換する作業なんですが、はて、なんでできない?いままでできていたのに。 試しにXE2017の評価版をインストールして、CVF66.dsw(C:Trnsys17CompilersCvf66)を開くと。。。

まずは、アップグレードの画面が表示されて、これは無事に終了。

image

つづいて、「COMPAQ Visual Fortran プロジェクト項目の抽出」(Extract Compaq Visual Fortran Project Items)を実行すると以下のような画面が表示されて上手くいきません。

image

「Fortran プロジェクト・ファイルの変換に失敗しました。
プロジェクト・ファイル(.dsp)は変換されていません。」

こりゃ困る。コンポーネントを作るときに困る。XE2013まではちゃんと変換できていたのになんでだろ?いやな汗が出てきた。

なにか手を打たなきゃと思い始めたところで、次回へつづく。

TRNSYSと関連ツール

TRNSYSと関連ツールを備忘のために図にまとめてみました。
計算内容よってTRNSYS本体の他、オプションや市販ツールを導入することで作業が効率的に行えます。

image

オプション

  • TRNFlow(換気モデル)
  • TESS Libs
  • Transsolar NoStandard Types

※価格は構成によって変わるのでお問い合わせください。 以下、市販ツールの情報です。

SketchUp Pro

3Dのモデリングソフト。建物のモデルを作る際にこれがあると、かなり効率的です。
取り扱いは、株式会社アルファコックス(http://www.alphacox.com/
価格は商用版 118,000円(税別)/ライセンス、教育版は年間ライセンス(要申請)

拡張アメダス気象データ

TRNSYSは標準年のデータに対応しています。
取り扱いは、株式会社気象データシステム(http://www.metds.co.jp/
価格(消費税・送料込み)は1ライセンスあたり。
【標準年】EA気象データ 1995年版(1981~1995年に基づく)15,000円
【標準年】EA気象データ 2000年版(1991~2000年に基づく)20,000円

FORTRANコンパイラ

2018/12/27追記TRNSYS18から、TypeStudio(統合型FORTRANコンパイラ)が添付されています。カスタムコンポーネントの開発でご利用頂けます。(カーネルのリビルドや複雑なコンポーネントの開発には引き続きIntel FORTRANが必要です)

カスタムコンポーネントの開発や、TRNSYSカーネルのリビルドはこれ1本でOK.
取り扱いは、エクセルソフト株式会社(https://www.xlsoft.com/jp/products/intel/studio_xe/index.html
価格は一番シンプルな構成で、商用 146,000円(税別)/ライセンス、アカデミック 69,000円(税別)/ライセンスです。

いずれも価格は2016/11/11現在の情報です。最新情報は各社へ要お問い合わせでお願いします。サイトライセンスや教室単位のライセンスもあるようです。