吸収式冷凍機の制御方法(TRNSYS-USERSより)

メーリングリスト、TRNSYS-USERSAbsorption chiller(吸収式冷凍機)の制御方法についての質問が流れていました。

How to control absorption chiller (Type 107)

質問者はスケジュールと条件によって冷凍機の運転状態を変えたいようです。具体的には、

  • 貯湯タンクの温度が75℃に達したら冷凍機を稼働
  • ただし、冷凍機が稼働するのは9:00-22:00のみ

という条件で制御する方法についての質問です。こういう制御に付いての質問って設備機器だったり、内部発熱のような負荷だったり、割とありがちな質問です。

詳しくはリンク先を辿ると質疑のやり取りが確認できますが、それも面倒です。ということで、さくっとまとめてみると、

Control Signalを使えば解決

です。リンク先のスレッドでも説明されていますが、機器のコンポーネントにはたいていの場合、InputにControl signal(制御信号)が用意されています。これを使って運転状態を制御できます。

例えば、冷凍機(Type107)だとChiller control signalという項目が用意されています。

image

既定では”1“が設定されているので、常に運転状態になっています。この値を運転(1)停止(0)で切り換えて制御します。何らかの方法で条件を判定して(1),(0)の値を作って入れてあげればOKです。

ここでは条件が2つあるので、それぞれの判定処理について考えてみます。

温度で制御

単純に貯湯タンクの温度を条件に制御するならサーモスタットを使って、機器の運転を制御できます。(メーリングリストではEquationを使う方法も提案されていますが、モデルによっては収束しなくなるのでサーモスタットがおすすめです)

図はAquastat(Type113)を使って制御した例です。設定温度とDead band(不感帯)を設定するだけで(1),(0)を出力してくれるので簡単です。

image

スケジュール制御

時間による制御はType14など、スケジュールを扱うコンポーネントを使って運転(1)を出力する条件を用意します。これをControl signalへつなげば実現できます。

下の図は9:00-22:00の間だけ(1)を出力するスケジュールを用意して制御している例です。

image

温度とスケジュールで制御

さて、メーリングリストでは温度とスケジュール両方の条件で制御したいという質問です。
それぞれの条件判定はすで上述したとおりで、この両方の値を使ってControl signalの値を生成します。例えばEquationを使って判定する場合は図のような接続になります。

image

EquationではThermostat, Type14の両方の値が1で有れば運転(1)の値を出力すれば良いので、運転状態は、

OK_Chiller = OK_Aquastat * OK_Timer

のような簡単な式で判定できます。他にもAND関数を使うなど判定方法は考えられますが、基本的にControl signalの値を生成できればどんな方法でも問題ありません。

条件が増える場合には、Equationの手前で判定条件を増やしてあげれば対応できます。条件判定が複雑になるようであれば専用のTypeを作成する方法もあります。でも、一般的なケースではこのような方法で十分対応可能です。今回は冷凍機の例ですが、他の機器でも考え方は一緒です。条件判定の処理とControl Signalで処理できます。

動作環境

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

TRNSYS-USERSより(壁の厚みとZoneの容積)

壁の厚み(Thickness)とZoneの容積についての割と良くある疑問です。

TRNSYS-USERS
http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/2018-May/030139.html

質問をざっくりまとめると…

Construction/Wall typeの厚みは壁の熱の特性のみに影響するのか、Zoneの容積にも影響するのか?
また、Zoneの形状を作成する場合は、容積を考慮して内法寸法をとるのか、外周でとるのか?

回答者の答え

Construction/Wall typeの厚みはZoneの容積には影響しません。壁の熱特性のみに影響します。
モデリングをする際に壁の内法、外周、壁芯のどれを採用するかについてのコンセンサスはありません。私は普段は外壁については内法、内壁は壁芯を採用しています。

Zoneの容積を考えると外壁は内法、内壁は壁芯というのは理にかなっている気がします。SketchUp/TRNSYS3Dのモデリングでは、個人的にはすべて壁芯で寸法をとるケースが多いのですが、そうすると壁厚の分だけZoneの容積は増えることになります。そうかと言って容積優先で内法でモデリングするとZone間の位置関係がおかしくなります。

image

Zoneを内法で取ると間が詰まるので歪んでしまう

この回答者のように外壁側は内法で寸法を取るのはバランスが良いかもしれません。

とはいえ目的によります。例えば、壁や開口部の断熱性能の違いを比較をするのであれば、モデルは同じで材料物性値や厚みを変えて比較することになります。容積についてはさほど影響ないので、すべて壁芯で問題なさそうです。(部屋の面積や壁厚にもよります)

実測と計算結果を比較するようなケースでは、条件によっては容積が重要なるケースも考えられます。そういった場合には内法でモデリングが有効かも知れません。何を計算したいかによってモデリングの考え方も変わってくるのだと思います。

タマネギとピンポン(TRNSYS-USERSより)

[TRNSYS-users] Excel iteration vs TRNSYS iteration

http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/2018-March/029931.html

TRNSYS-USERSには、いろんな質問が流れています。今回はコンポーネントの呼び出しタイミングに関する話題を拾ってみました。

ざっくり言うと

TRNSYSからExcelを呼び出す場合、呼び出されるタイミングはイテレーションごとなのか収束後なのかという質問。

イテレーションごとに繰り返し呼びされる状態をタマネギ(Onion)、収束のタイミングで規則的に相互にやり取りされる状態をピンポンに例えています。

剥いて剥いて無くなる(収束?)するまで繰り返す様でしょうか?

お互いに収束したタイミングで処理を打ち返す?

ざっくりまとめると

相手がExcelでも、TRNSYSからは単にコンポーネントを呼び出す仕組みになっています。その先で呼び出されいるアプリケーションがなんであれ、普通のコンポーネントと区別できない(見えない)のでイテレーションで呼び出されます。

Excel側でタイムステップごと呼び出される前提で処理してしまうと、予想しない結果になります。良い例が思いつきませんが、例えば結果をワークシートに書き込むような処理を考えると、イテレーションごとの値が山ほど書き出される事になります。

しかし、タマネギ(Onion)って収束の表現は初めて聞きました。ピンポンは処理の流れがイメージし易くて良いですね。いままでステップ・バイ・ステップで連成しているという言い方をしてましたが、今度から使おうと思います。

湿った衣服からの蒸散量はどれぐらい?(TRNSYS-USERSより)

TRNSYS-USERSに流れていた投稿からですが、質問者は観光船の窓の結露検討を行っているようです。ワーストケースシナリオとして、雨の日に濡れた衣服を着た乗船者を想定しています。で、こういったケースのモデルは無いか質問しています。

詳しくはこちら↓

http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/2018-February/029867.html

これに対してANNEX 14 sourcebookを参考にしているという返答がついています。

それがこちら→ http://www.iea-ebc.org/Data/publications/EBC_Annex_14_source_book.pdf

6.3.1 Vapour Production Rates in Rooms に湿った衣類からの蒸散量の他、シャワーや樹木からの蒸散量なども記載されています。こういうの日本にもあるんですかね?何かの時に役に立ちそうなので、備忘の意味でまとめてみました。

加湿、除湿のコントロール(TRNSYS-USERSより)

TRNSYS-USERSでType56の加湿、除湿についての話題が流れていました。

[TRNSYS-users] Conditional Output

http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/2018-February/029874.html

外部の除湿器、加湿器を使って湿度が一定以上なら除湿、一定以下なら加湿としたいようです。(type56のDehumidification,Humidificationでもできますが、除湿器、加湿器そのものをシミュレーションしたいんでしょうね。下図はcooling typeの設定例)

image

メーリングリストでは対策としてThermostatの利用が提案されています。温度の場合と同じように、Thermostatで制御して、おらくVentilation typeで給気へ加湿するような処理なんでしょう。

Thermostatってそういう使い方もあるのか。でも温度と湿度じゃ単位違うからTRNSYSに怒られるかも?(コンポーネントによって単位系をしっかりチェックしているのでエラーになる可能性があります。まあ、そういう場合はEquationを経由すると回避できるんですけどね)

2018/2/26 追記

ドキュメントを見ていたらDehumidistat,Humidistatというコンポーネントを見つけました。(下図)
除湿、加湿の制御にはこれらのコンポーネントが使えそうです。

image