Translate

2016/05/31

TRNSYS3Dで面の設定を確認する

TRNSYS3Dでモデリングする際、前回紹介したように[Surface Matching]で内壁の設定を一括して行うことができます。隣接する面の形状が同じであれば、自動的に内壁など、Zoneの境界として認識してくれます。

ただ、まれに形状が同じに見えても内壁として認識されないケースがあります。これは頂点が少しだけずれているなど、形状が微妙に異なっているのが原因です。

[Surface Matching]でまとめて一括処理すると、すべての壁が意図したとおり正しく設定されているか確認したくなります。そういう時に[Search Surfaces]で該当する面の検索、表示で確認を行うことができます。

例えば、内壁であれば「ADJ_WALL」に設定されていればまず問題ありません。「ADJ_WALL」を検索、表示して意図した壁が表示されていればOKという事になります。具体的には次のように操作します。

① ツールバーの [Search Surfaces]をクリックしてウィンドウを表示します。

image

② 「Search Surface」の「Construction」の項目で「ADJ_WALL」を選択して、「Search Entire Model」をクリックします。

image

③ 「ADJ_WALL」が割り当てられた面のみが検索、表示されます。

image

ここで、内壁だけが表示されていれば問題ありません。もし、まったく何も表示されていなかったり、意図しない壁が表示されているようであれあば、形状があっている確認して修正を行います。

④ 表示を元に戻すには「Unhide All」をクリックします。

image

2016/05/30

TRNSYS3Dでまとめて隣接面を設定する

TRNSYS3Dの建物形状のモデリングでは内壁など隣接する面の設定が必要になります。この設定は面ごとに個別に設定することもできますが、対象が複数ある場合には、まとめて処理するための[Surface Matching]という機能が用意されています。

① ツールバーの [Surface Matching]をクリックします。

image

② 「Surface Matching」ウィンドウで「Match in Entire Model」をクリックします。

image

③ 実行確認のメッセージが表示されるので、確認して「OK」ボタンをクリックします。

image

隣接する面のマッチング処理が行われ内壁として設定されます。作業後は「Object Info」を使って、内壁として正しく設定さているか確認してください。

2016/05/26

TRNSYSの関数をC/C++から呼び出すと動かない

TRNSYS-USERSにC/C++からの関数呼び出しの話題が流れていました。

[TRNSYS-users] C++ API not working

C/C++のコンポーネントから整数値を返す関数を呼び出すとNaNが返ってくるとか、文字列を返す関数を使うとAccess Violationでクラッシュするとか。なかなか興味深い質問なのでしばらく注目してました。でも誰も返事がない。C/C++でコンポーネントを書いている人ってあんまりいないんですね、たぶん。

試しに書いてみたら、前者のNaNが返ってくるのは再現できませんでした。自分で書いてみたらちゃんと動く。質問者と何が違うんだろうと考えてみたんですが、これ原因はおそらく関数の呼び出しスタイルがTRNSYS16かTRNSYS17の違いじゃないかなー、と思います。どちらのスタイルで書くかによってTRNSYS側の挙動が違っていた気がします。

問題は後者の方ですが、もともとTRNSYSはFORTRANを前提に作られているので、C/C++から呼び出すにはひと手間必要になります。文字列を返す関数は今まで使う機会がなかったので、実は試していませんでした。(単純に呼び出してみたら質問者と同じようにAccess Violationでクラッシュした)

で、いろいろ調べ始めたらFORTRANとC/C++って文字列の扱いが違うので、そのままじゃやり取りできないんですね。(FORTRANは固定長で、C/C++はNULL終端で云々。。。)詳しくはこちら↓

[日本語]
インテル® Fortran コンパイラー 14.0 ユーザー・リファレンス・ガイド
文字データ型の戻り

[英語版]
User and Reference Guide for the Intel® Fortran Compiler 15.0
Returning Character Data Types

この記事の例を参考に、もともとgetDeckFileName()の関数をベースに新しいC/C++用に新しく関数getDeckFileNameEx() を追加してみました。

・TrnsysFunciton.f90
Function getDeckFileNameEx() bind(c,name="getDeckFileNameEx")
!dec$ attributes dllexport :: getDeckFileNameEx
Use TrnsysData
Use, intrinsic :: iso_c_binding
type(C_ptr) :: getDeckFileNameEx
Character(len=maxPathLength) ret 
ret = trim(deckn1)//CHAR(0)
getDeckFileNameEx = C_LOC(ret)
End Function getDeckFileNameEx

C/C++の呼び出し側はこんな感じで記述。。。

・TRNSYS.h
extern "C" __declspec(dllimport) char*    _cdecl getDeckFileNameEx(void);

・Type201.cpp
char *dckfilename;
dckfilename = getDeckFileNameEx();

こうするとちゃんと文字列でファイル名が取得できました。
一応対策はできたんですが、毎回毎回これと同じように関数を追加するのもなんかなー。それにFORTRANのソースコードの変更とリビルドが必要になるのでコンパイラも必要になる。ちょっと一般向けにはお勧めしにくい。他の方法ないかなー、というのが今日のひとまずの結論。

2017/4/15追記
TrnsysFunciton.f90に手を加えずに直接C/C++から関数を呼び出す方法をまとめました。
動いたけど半信半疑

2016/05/25

TRNSYSのトレーニングテキストの動画を公開(β)

TRNSYSのトレーニングテキストに沿った操作画面の動画を作成しました。β版(お試し版)なので後で消すかも?

1. Creating 1st Zone, ‘ROOM1’

Zoneの作成からSurface Matching まで4つ作成しています。

つづきはこちらから↓
TRNSYS操作ガイド TRNSYS3D
http://screencast-o-matic.com/channels/cDhTeDbkn

テキストはこちら↓からダウンロードをお願いします。
TRNSYSのトレーニングテキストを更新
こちらもZoneの表示切替や誤植の修正を行っています。

2016/05/17

DckファイルからTPFを復元する

まれにですが、TPFじゃなくてDckファイルのみ送られてくることがあります。海外の方に多く見られる傾向なんですが、なんでだろ?

DckファイルだけでもTRNSYSの計算はできるんですが、なんのコンポーネントを使っているのかさっぱり分からない。(慣れるとDckファイルが読めるようになるんですが、またそれは別の話)

こういう場合、よくした物でSimulation StudioにはDckからTPFを復元する機能が用意されています。

使い方

1.メニューから、[File]-[Import TRNSYS Input File...] 選ぶ。

2016-05-17_09h54_57

2.Dckファイルを選択して「開く」ボタンをクリック

2016-05-17_10h05_41

3.Dckファイルが読み込まれてTPFが復元されます。

2016-05-17_10h04_40

注意点としては、Dckファイルが標準以外のコンポーネント、例えばオプションのコンポーネントや自作のコンポーネントを使われているとうまく復元できません。その場合、計算に必要なコンポーネントがそもそも不足している状態なので、Dckファイルの作成元と相談して入手する必要があります。

2016/05/16

日本語のファイル名とかパス

TRNSYSって日本語のファイル名とかパスには弱いです。プロジェクトのファイル名に日本語を使用するとエラーの原因になります。

例えば「設計案A.tpf」のような名前を付けると、実行時に次のようなエラーになります。

*** Fatal Error at time   :         0.000000
    Generated by Unit     : Not applicable or not available
    Generated by Type     : Not applicable or not available
    TRNSYS Message    311 : The TRNSYS input file could not be opened. Please check this file and re-run the simulation
    Reported information  : Not available

どうもTRNSYSの計算エンジンが日本語だとうまく認識できないようです。

と言うことで、ファイル名やパスは英数字で設定するのがお勧めです。

2016/05/13

TRNSYSをリビルドする

TRNSYSのエラー対策など、と言っても、かなりディープなのですが。。。
なかなかお目にかからない以下のようなエラーがでる時があります。

*** Fatal Error at time   :         0.000000
    Generated by Unit     : Not applicable or not available
    Generated by Type     : Not applicable or not available
    TRNSYS Message     50 : The number of PARAMETERs specified for one of the components in the simulation is not between 0 and the maximum number allowed per PARAMETERS statement. The maximum number is defined by the nMaxCardValues parameters in the TrnsysConstants.f90 file. Changes made to TrnsysConstants require that the TRNSYS dynamic link library be rebuilt for these changes to take effect.

TRNSYSのパラメータを変更してリビルドし直せと言っています。TRNSYSもプログラムなので、取り扱える値などに上限設定があります。普段は気にする必要はありませんが、ごくまれにこのようなエラーとして現れます。こういう場合、TRNSYSに添付されているソースコードで定義されている上限を変更して対応します。

このメッセージでは nMaxCardValues の値を変更しろという事なので、それに従って変更します。変更するファイル(TrnsysConstants.f90) はC:\Trnsys17\SourceCode\Kernel に格納されています。

2016-05-13_15h53_13

これを開くと、確かに nMaxCardValues という項目があるので、この部分を大きな値へ変更します。

2016-05-13_16h02_36

あとは、コンパイラを起動してリビルドすればエラーを回避できるようになります。

Intel Fortranの開発環境が必要になるので、それなりに大変です。でも、いざって言うときにソースコードがあるのは心強い限りです。

2016/05/12

TRNSYSと換気計算の連成

TRNSYS-UsersにTRNSYSと換気の連成の話が流れていました。

[TRNSYS-users] query regarding TRNflow

TRNSYSで換気計算といえばTRNFlow(有償オプション)、COMIS(オープンソースのツール)がよく使われています。

前者は多数室モデル(Type56)の組み込みオプションで、熱のモデルと換気のモデルを一緒に扱うことが出来ます。詳しくはこちら↓
TRANSSOLAR Software | TRNFlow Overview

後者は連成用のコンポーネント(typ157)を介してTRNSYS/Type56と換気計算プログラム(COMIS)との間でデータのやり取りをしながら連成計算を行います。熱のモデルと換気のモデルがそれぞれ必要になります。
COMIS

TRNSYS-USERSで紹介されていたのは、CONTAM(オープンソースの換気計算プログラム)との連成です。仕組みとしてはCOMISと同じく、専用のモジュール(Type98)を介して連成を行う方式のようです。
Software Tools

2016-05-11_17h27_13

すでにCONTAMを利用されている場合には便利な選択肢かもしれません。

2016/05/11

TRNSYSの計算の仕組み

TRNSYSではコンポーネントを組み合わて計算を行います。図のように標準コンポーネントやオプションのコンポーネントを必要に応じて組み合わせて計算を行います。

2016-05-02_14h26_13

この例では左端のEqua(Equation)から出力されたデータが矢印に沿って、Type194、Type65dへ順番に流れて計算が進んでいきます。順番にデータが処理されていくので、非常に流れとして分かりやすいモデルになっています。

2016-05-02_14h29_41

ところでこのデータの流れですが、モデルによってはループ状になることがあります。例えば下の図の例(TRNSYS17\Examples\3D_Building)では2つのコンポーネントが相互にループ状に接続されています。(お互いに相手のデータを受け取って計算する接続になっている)

2016-05-02_14h44_03

Building(Type56)は室温を計算し、Switchでは換気の調整を行っています。(いわゆる外気導入の処理)

こういった接続では、お互いの計算結果が相互に影響します。さて、どちらの計算結果が優先されるのでしょうか?そもそもどちらが先に計算されるのでしょうか?

くるくる回るよイテレーション

TRNSYSでは基本的にコンポーネントが配置された順番に計算が行われます。ただし、これは一回のみの計算ではなく、タイムステップごとにすべてのコンポーネントを呼び出して何度も繰り返して計算を行います。(この繰り返し処理をイテレーションと呼びます。)

ループ状に接続されているコンポーネントの間では、このイテレーションを通して、お互いの計算結果を相互に受け取り再計算が繰り返されます。最終的にすべてのコンポーネントの計算結果が変化しなくなった(収束した)時点で次のタイムステップへと処理を進めます。

このようにイテレーションを繰り返すことで相互に依存する接続関係を含め、すべてのコンポーネントの計算を処理します。(図にすると以下のような処理を繰り返しています。)

2016-05-02_15h32_57

このモデルの例でいえば、最終的に換気するか、しないかどちらかに落ち着きます。

Debug機能を使ってログを書き出すと、コンポーネントの間を流れるデータの値がイテレーションを通して、次第に安定していく状態を確認することができます。(参考:「TRNSYSのDebug機能を使ってみる」)

これって、他のツールだと収束処理として内部で行われていると思うんですが、TRNSYSだとちゃんと見えるんですよね。

 

実はイテレーションが終わらないケースも。。。

さて、このモデルですが、イテレーションの流れを順番に見ていくと。。。

1)室温が上昇→外気導入開始

2)外気導入で室温が低下→外気導入停止

3)外導入停止で室温が上昇→1)へ戻る

といった流れで、結果的に計算が終わらなくなるような気がします。実際、単純な判定処理、例えば「外気温」<「室温」なら換気するような判定にすると、1~3の処理の繰り返しになっていまい、計算結果が安定しなくなります。つまりイテレーションが終わらなくなるので、計算が先に進めず最終的にはエラーとして処理されます。

通常、こういった判定では、コントローラーなどを使って、ある程度判定の幅を設けて処理を行います。日常生活でもそうだと思いますが窓を開けて、多少肌寒くなるぐらいまでは開けっ放しにしますよね?それと同じように換気開始と終了の条件を分けて室温が28℃以上なら換気を開始、25℃になったら換気を止める、といったように換気の開始条件と終了条件に幅を持たせておきます。こうすることでイテレーションの繰り返しの中でも計算結果が安定し、外気導入が成り立つようになります。このモデルの例ではコントローラー(Type2)を複数使って、判定処理を行っています。

注:換気量が極端に多かったり、外気温が低かったりと、室温が急に下がる条件になっていると、やはり1~3の繰り返しになってイテレーションが終わらなくなります。

2016/05/09

TRNSYSのEquationでゼロ割対策

2016-05-09_10h18_33

ちょっとした計算や判定処理になにかと便利なTRNSYSのEquaitonですが、計算内容によってはゼロ割(0による割り算)が発生することがあります。TRNSYS-USERSを拾い読みしていたら簡単な対策が紹介されていました。

result = variable1/MAX(0.0001,variable2)

なるほど、シンプル。単純にMAX()で0を避けるだけ。そもそもvariable2が0になる原因をどう考えるかにもよりますが、無視しても構わない場合には簡単でいいですね。

注意点としては、リンク先にも書いてありますが、variable2が負の値になることが想定されるようなケースでは使えません。