TRNSYS-USERS拾い読み(家具の顕熱容量はどう考えるか?)

TRNSYS-USERSに室内の顕熱容量の話題が流れていました。Zoneの顕熱容量はどう決まるかという質問です。

TRNBuildの初期値ではZoneの顕熱容量は、気積分の値が設定されています。(室内の空気分の顕熱容量として設定されています) 実際簡単なモデルで試すと。。。

検証用にTRNSYS3Dで簡単なモデルを作成
検証用にTRNSYS3Dで簡単なモデルを作成

気積に応じて顕熱容量が設定されている事がわかります。

TRNBuildではZoneの気積(容積)分の空気を顕熱容量として設定している
TRNBuildではZoneの気積(容積)分の空気を顕熱容量として設定している

5mx5mx2.4mx1.2kJ/m3K=72kJ/K

これに家具分を考慮する場合は、この値から20~30倍ほどの値に設定すれば良いというコメントが付いているのですが、いや、基本的には5倍ぐらいで使っているというコメントが更に続いています。

初期値だと確かに値としては小さなことは理解できますが、家具分を想定すると、果たしてどれぐらいが適切なんでしょうかね?住宅と非住宅で違うでしょうし、なにか一般的に使われる値ってないんですかね?

TRNSYS-USERSの一連のやりとりは、こちら↓

[TRNSYS-users] capacitance- TRNBUILD-TRNSYS 17

2017/2/2 追記 こちらのサイトで住宅の顕熱容量についてまとめていただきました。

なんでもよへこ。ときどき、環境工学系 [TRNSYS]家具の顕熱容量

図に起こすと判りやすいかも

TRNBuildのOutputって数が多いですよね。多くないですか?特にBalance Output系はまとまった値がドバっとファイルに出力されます。一塊で見渡せるのはいいのですが、値を読むのも一苦労。マニュアルを読みながら値をチェックしていると、最初の方に出てきた値は何だっけ、てな具合で行ったり来たりしていることがあります。値も記号で記載されているのでちょっと分かりにくい。

Balance1 の記載を読んでいて、あまりに辛かったので途中から図に起こしてみました。はじめは手書きでノートに描いていたのですが、ごちゃごちゃしてきて複雑になってきました。(ほんとBalance Outputは項目が多い)

手書きでは読みにくかったので最終的に図に描きなおしてみました。

BALANCE 1 - SOLAR BALANCE FOR ZONES (NTYPE 901)
BALANCE 1 – SOLAR BALANCE FOR ZONES (NTYPE 901)

値がサクッとわかる程度に描いたので、一部省略しています。項目の詳しい内容はドキュメントをご覧ください。

2017/1/31 
QSADJ(隣接Zoneからの日射)が分かりにくいというご指摘をいただいたので、図を修正して差し替えました。

TRNSYS18の最新情報が。。。

TRANSSOLAR社(TRNBuildを開発しているドイツの会社です)のサイトを見たらTRNSYSの次期バージョン、TRNSYS18の情報が公開されています。 まったく予告なしだったので、正直びっくりです。詳細情報が届いていないので不明な点が多いのですが、事前になんとなく聞いていた範囲でご紹介します。

TRNBuild

新機能として日射関連の機能が大幅に増えます。光環境の計算では定番のRadianceの機能を取り込んだものになるようです。室内の照度がType56で計算できるようです。 TRNLizard(Rhino/Grasshopperプラグイン)で建物のパラメトリックスな形状モデリングにも対応するようです。(これ凝った意匠の検討とかできるのかな?すごくないですか?)

Kernel

64bit版の提供。計算が速くなりますが、周辺のコンポーネントも64bit化する必要があるので、しばらくは計算によって32bit/64bitが混在することになるかと。。。
工学系では人気のプログラミング言語Pythonへの対応もあるようです。どういう使い勝手になるのか楽しみです。(たまたま以前の記事でPythonに言及しましたが、まったくの偶然です)

Simulation Studio

出力関係の機能が増えるようです。既存の出力系はシンプルな機能なので、これはちょっと楽しみです。

TypeStudio

コンポーネントの新しい開発ツール?? しかし、分からないことが多すぎですね。しばらくすると詳しい情報が入ると思うので、またご紹介します。

TRNSYS 18 – NEW FEATURES

TRNSYS 18 – NEW FEATURES
TRNSYS 18 – NEW FEATURES

CONVEX and CLOSED

TRNSYS/Type56には計算のモードがいくつかあります。StandardからDetailedまで何段階かの設定が可能です。StandardモードからDetailedまで日射の扱いが詳細になって行きますが、Standardモード以外では前提条件としてZoneの形状はConvex、かつCloseでなければいけません。2017/08/25 上記赤字部分追記

CONVEX

直訳すれば凸型です。下図のような形状であれば良さそうですが、実際作るとエラーになります。

Convexに見えるけどNGな形状
Convexに見えるけどNGな形状

これは計算上、同じZone内ではすべての面がお互いに見通せる形状になっている必要があるためです。Convexは凸型というより、出っ張った多角形というのが正しいです。下図の赤い部分のように互いに見通せない面があるとエラーになります。

Zone内の面が相互に見通せる形状
Zone内の面が相互に見通せる形状

しかし、現実問題としては部屋の形状って凸型以外もありえますよね?

例えば、LDとKのこんなレイアウトってありがちです。

例えば、LDとKのこんなレイアウトってありがちです。

上述したようにこの形状ではエラーになってしまいます。なにか対策ないかと、もしかして1つのZoneでもAirnodeで分ければOKだったりとしてと、淡い期待を抱いて試してみました。結果からというと、やはりエラーになります。

プログラム上うまいこと処理してくれるかと思ったんですが、やはりZone単位でしっかり判定しているようです。(まあ、考えてみれば同じ室内なんだから当然です)

Radiationモードを使用する場合は、モデリング段階で部屋を凸型に分けて作成する、もしくは凸型になるようにデフォルメしておく必要がありそうです。上記の例だとK,LDをぞれぞれ矩形のZoneとして分けて作成するか、デフォルメしてLDKとして一つにまとめてモデリングします。

CLOSED

図形として閉じていない場合もNGなんですが、これは通常モデリングしている限り作られません。

意図的にCLOSEじゃない図形を作るというより、なんらかの事故でたまたま出来上がってしまうケースではないかと思います。

無理やり作るとこんなモデル(壁が一面抜けている)
無理やり作るとこんなモデル(壁が一面抜けている)

独自ドメイン取得しました

このブログ用に独自ドメインを取得しました。

www.kankyoukei.com

いままでBlogger(blogspot)のドメインをそのまま使っていたんですが、専用のものを取得して変更しました。

.comなので、なんだか会社みたいですがブログ専用です。今までの記事のURLもそのままアクセスできます(リダイレクトされます) とはいえ、ドメインの変更に伴って「いいね!」がすべてリセットされてしまったのが少々残念。まあしょうがないっかー。

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

ここまでのあらすじ

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

原因

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

Type21 Time Valuesが謎の値を返す

1h未満のタイムステップ

以前に紹介したType21を使っていて、タイムステップが1h未満では妙な値を出力していることに気づきました。

TIME Month  Day Hour
----- --- --- ----
23.25 1.0 1.0 24.0
23.50 1.0 1.0 24.0
23.75 1.0 1.0 24.0
24.00 1.0 1.0 24.0
24.25 1.0 2.0 1.0 ← 24:15なのに1が出力される
24.50 1.0 2.0 1.0      〃
24.75 1.0 2.0 1.0      〃
25.00 1.0 2.0 1.0 ← ここは1:00なので問題なし
25.25 1.0 2.0 2.0
25.50 1.0 2.0 2.0

なにこれ?24:00 < Hour ≦01:00 は「1」が出力されています。というか、Hourは実数で1.25とか出力されるのかと思いきや、正時の値が出力されるようです。

ドキュメントを調べると。。。

不思議な動きですが、何かルールがあるのかもしれません。こういう時はまずドキュメントを調べてみます。

To coincide with the TRNSYS specification of time, the values
reset during the timestep after the last hour of the segment.
For example with a simulation timestep of 0.25 hour, when the
simulation time is at 24.00 hours, the hour of day value would
be 24, and at simulation time 24.25
the hour of day value would be 1.

TRNSYS Vol.4 Component Mathematical Reference より

どうやら仕様のようです。1h未満では次のタイムステップの時刻(正時)を出力するようになっています。どういう理由でそうなるかは不明ですが、もしかして24時間を1~24(0~23ではなくて)で処理しているのと関係ありそうだけど、どうだろう?

対策

そのままだと扱いにくいので対策を考えてみました。Equationを使って、Timeから時刻を計算してやると、いい具合に出力できます。以下の例では「分」の値も含めて処理して一緒に出力しています。

例)Equationの設定
day = int(time/24)
hour = time-day*24 ! 時刻を小数点以下までHourで計算
hourOnly = int(hour) ! 正時に変換する[0~23hour]
min = (hour-hourOnly)*60 ! 「分」を計算

※注:「月」「日」はType21のCalendar month, Day of the monthをそのまま利用します。

【出力例】0-23hで適切に出力される
TIME  	Month 	Day    	Hour    Min(計算値)
----    -----   ----    ----    ----
23.00 	1.0 	1.0 	23.0 	0.0 
23.25 	1.0 	1.0 	23.0 	15.0 
23.50 	1.0 	1.0 	23.0 	30.0 
23.75 	1.0 	1.0 	23.0 	45.0 
24.00 	1.0 	1.0 	0.0 	0.0 
24.25 	1.0 	2.0 	0.0 	15.0 
24.50 	1.0 	2.0 	0.0 	30.0 
24.75 	1.0 	2.0 	0.0 	45.0 
25.00 	1.0 	2.0 	1.0 	0.0

まとめ

タイムステップが1h未満の計算では、ちょっと工夫が要りますが、Equationで簡単に対策できました。(タイムステップが1hなら特に対策不要です)

参考までにサンプル(TimeValues_0.25h.tpf)をGithub/TRNSYS.JPに登録しておきました。

サンプル(TimeValues_0.25h.tpf)
サンプル(TimeValues_0.25h.tpf)

シミュレーションとプログラミング言語

ソースコード
ソースコード

シミュレーションの仕事をしていると、大量の計算作業が発生する事があります。少しずつパラメータを変更して、効果の検討であったり、単に複数条件の検討だったりと、1つ1つの変更箇所は少ないのですが、これが数十パターンにも及ぶとかなりの手間になります。また、うっかりミスですべての計算をやり直すような危険もあるので、それなりにストレスの溜まる作業です。

大量の計算到来

先日も、とある仕事で数十パターンの計算の実行と、さらに計算結果を加工する案件が発生しました。内容を検討すると計算の回数は多いものの、すべて一定の規則で条件を変更、繰り返し処理できる内容でした。

繰り返しは得意なんです

この手の繰り返しパターンはコンピュータが得意とする分野です。早速、数十行ほどのプログラムを試作したところうまく処理できました。プログラミング言語には計算処理に向いているもの、テキスト処理に向いているもの、Webサイトの構築など、用途によって様々なものあります。環境工学の分野の計算ではFORTRANがよく使われています。計算そのものは既存プログラムを使うので、C#を使って計算パターンごとに必要なデータや設定を自動生成しました。そして、実際の計算はバッチファイルを書き出して間接的にプログラムを実行する方法です。この手法は化石クラスの古典的なやり方ですが繰り返し計算には効果絶大です。※

TRNSYSもバッチファイルで実行できます。

対応の幅を広げる

一過性のプロジェクトなので、人海戦術で対応する方法もあったのですが、後から条件が増えたり、設定をミスって振出しに戻ることもあり得ます。前者はクライアントの依頼などでありがちですが、数十計算を終えた後にうっかり間違いに気づいた時のダメージは計り知れません。(いやほんと、絶望的な気分になります)
プログラムで仕組みを整えておくと、ちょっとした変更で再計算に臨めるため、かなりストレスが軽減されます。手作業による間違いも防げます。結果的に作業のログとして残るので、何か問題があっても検証がしやすくなります。
なにより気軽に変更できるので対応の幅が広がります。計算結果を検討して試行錯誤もやりやすくなるので、最終的にはクライアントの利益にもなります。

プログラミング言語

シミュレーションツールは便利なツールですが、合わせてプログラミング言語も何かしら覚えておくと応用が効きます。プログラミング言語は用途によって向き不向きはありますが、基本的な考え方は同じなので、何でも良いので1つでも憶えておくと良いでしょう。個人的には今回使ったC#なんかデスクトップからスマホまで使えてお勧めですが、ちかごろは研究用途だとPythonなんかも面白そうです。

TRNSYSで温度分布を計算する方法(4)

前回まで計算の準備と計算結果を.esoへ出力する設定を行いました。今回は出来上がった.esoをSketchUpを使って表示します。

表示用のモデルの準備

SketchUpを起動して結果を表示するモデルを開きます。計算結果を重ね合わせるモデルが必要になるのですが、注意点としては元々の作成していたIDFではなくて、TRNBuildへインポートした際に自動生成されたファイルを選択します。図の例では元々のモデルはUntitled.idfですが、TRNBuildで生成されたUntitled_b17.idfを選択します。
メニューバーから[プラグイン]-[Trnsys3d]-[Open…]の順で選択して、IDFファイルを開きます。

2017/9/5 追記
※TRNSYS18では、Untitled_b17.idfは自動的に生成されません。このため、予めTRNBuildのメニューバーから
[File]-[Export TRNSYS3d file…]でIDFを作成してください。

.idfファイルを開く
.idfファイルを開く

そのままだと、手前の外壁が邪魔で床面が見えないので、外壁面を選択して「非表示」にして床面が見えるようにします。

手前の外壁を「非表示」に変更する
手前の外壁を「非表示」に変更する

外壁が「非表示」に変更されると、下の図のように室内が見えるようになります。

手前の外壁が「非表示」に変更された状態
手前の外壁が「非表示」に変更された状態

つづいて、レンダリングのモードをデータに切り換えます。メニューから[プラグイン]-[Trnsys3d]-[Redering]-[By Data Value]を選択して切り換えます。これで後述する計算結果の値が表示されるようになります。

レンダリングの設定を[By Data Value]へ変更する
レンダリングの設定を[By Data Value]へ変更する

まだ、データを何も設定していない状態なので、下図のように白模型のような表示になります。

データが未設定の状態
データが未設定の状態

.esoファイルの指定

表示用にTRNSYSで計算した結果(.eso)を指定します。メニューから[プラグイン]-[Trnsys3d]-[Rendering]-[Settings…]を選んで、表示される画面で.esoファイルを指定します。

.esoファイルを指定する
.esoファイルを指定する

この画面ではデータの指定の他、表示形式の指定も行えます。初期値ではSurfaceに指定されていますが、室温や湿度などZone単位の表示も指定できます。

アニメーション表示

すべての準備が整ったので、ここでツールバーの再生ボタンをクリックすると表面温度が表示されます。

再生ボタンをクリックして、アニメーション表示を開始する
再生ボタンをクリックして、アニメーション表示を開始する

下の図のように床面の温度がアニメーション表示されたら成功です。

床面の表面温度がアニメーション表示される
床面の表面温度がアニメーション表示される

おまけ

同じモデルで更に床面を細かく分割して計算し直してみました。窓から入った日射の影響で、床面の温度がゆっくり変化しながら移動する様子がわかります。

床面の表面温度が時間によって変化する

動作環境

2017/9/5 追記以下の環境で動作を確認しています。

Windows10 Pro(64bit)
TRNSYS17.02.0005
TRNSYS3D+SketchUp 8Windows10 Pro(64bit)
TRNSYS18.00.0014(64bit)
TRNSYS3D+SketchUp 8

TRNSYSで温度分布を計算する方法(3)

前回はTRNSYS3D Plugin(SketchUp)で作成したモデルへ床面の出力項目を追加しました。更に計算モードの指定、計算結果の出力へと進んでいきます。

Radiation modeの設定

TRNSYS17以降、Type56/TRNBuildでは直達日射、天空日射、長波長の計算方法のオプションを指定することができます。標準では、それ以前からあるStandardモードに指定されています。床面の温度を詳細に計算するためここではオプションを設定を変更します。
対象のZoneを選んだら、画面右上の「Radiation Modes」のアイコンをクリックして、設定画面を表示します。

TRNBuild Zone, Radiation modes
TRNBuild Zone, Radiation modes

設定画面では次の3項目で、それぞれDetailed modelを選択します。←ここ重要です。

  • Beam radiation distribution
  • Diffuse radiation distribution
  • Longwave radiation exchange within a zone
Radiation modes
Radiation modes

.esoファイルの出力設定

計算結果をTRNSYS3D Pluginで表示するためのデータファイル(.esoファイル)の出力を設定します。Simulation Studioの画面右側のDirect Access Toolbarに.eso出力用のコンポーネント(Type125)が用意されています。
[Output]-[TRNSYS Plugin for SketchUp Printer]フォルダからType125を選んで配置します。

Type125を配置
Type125を配置

Type56、Type125の接続では表面温度の項目をすべて接続します。(TSIで始まるのが床の表面温度です。これらをすべてType125へ接続します)

Type56,Type125の接続
Type56,Type125の接続

Type125の設定

さらにType125のInputの項目を次のように設定します。←これも重要!
まずはUnitの項目をすべてstring※へ変更します。そして、Valueの項目へはSurface Noを入力します。Surface NoはType56の出力で名前がTSI_Snという形式になっている’n’の部分です。この番号をValueの項目へ入力します。上の図と見比べると分かり易いですが、Input-1へはTSI_S1が接続されているので’1’を、Input-2はTSI_S3なので’3’をと、すべてのValueを設定します。(この順番を間違えるとSketchUpの表示でズレが出てしまうので注意してください)

2017/09/05追記
※TRNSYS18ではvariable nameへ変更してください。(stringからvariable nameへ名称変更されています)

Type125のInputの設定
Type125のInputの設定

最後にExternal Filesタブで.esoファイルの指定を行います。既定では”***.eso”になっていますが、これはこのまま(.tpfと同じ名前で出力される)でも良いですし、別の名前を指定しても構いません。

Type125 External Filesタブの設定
Type125 External Filesタブの設定

ここまででTRNSYSで計算する設定は終了です。計算を実行して.esoファイルが出力できたら準備完了です。

Simulation Studioで計算実行
Simulation Studioで計算実行

.esoをSketchUpで表示する方法は次回へ続きます。