Translate

2018/08/18

吸収式冷凍機の制御方法(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)

2018/08/09

BIMビューワー、eveBIMを試してみた

cstb(フランス建築科学技術センター)のサイトからBIMビューワー、eveBIMをダウンロードして試してみました。

eveBIMのサイトで、ダウンロード(画面左側の赤枠部分)をクリックして必要事項を入力します。仏語のサイトなので、google翻訳など適宜利用して入力します。

image

しばらくすると、ダウンロードのリンクがメールで届きます。Windows版とMac版のリンクが届くので、Windows版をクリックしてダウンロード。

image

あとはダウンロードしたファイルをダウブルクリックしてインストールすればOK.

下の画面はサンプルを表示してみたところです。IFCのクラス(オブジェクト?)がきれいに読み込まれています。

image

下は1階だけ選択して表示した画面です。

image

TRNSYSへの変換は、対象室を選んでBuiファイル(.b17,.b18)へ変換するようです。そのあたりはまたの機会に試してみます。

2018/08/08

TRNSYSのエラーとコンポーネントオーダー

コンポーネントを配置と計算

普段あまり意識していませんが、コンポーネントの配置って、データの流れに沿って並べていないでしょうか?

image

この図はサンプルの例ですが、

  • 左側に気象データやスケジュールなどデータを出力するコンポーネント
  • 真ん中は計算の主になるコンポーネント
  • 右側に計算結果を処理する出力用のコンポーネント

という順で並んでいます。計算の元になるデータは左側(上流)、出力は右側という並びになっています。(この並び順がTRNSYSでは割と一般的な配置です)

TRNSYSの計算順はといえば

ところがTRNSYSの処理順をSettings(Control Cards)で確認すると、意外にも順番がバラバラです。下の図のようにType1b(集熱パネル)、System_Plotter、Type15-6(気象データ)。。。のような並びです。

image

最初に集熱パネルの計算をして、いきなり結果を出力、その後に気象データの読み出し処理と、なんか順番がめちゃくちゃですよね?

ちょっと考えると変な順番に見えますが、複数のコンポーネントを繰り返し計算、収束判定しているので、基本的には順番に関係なく処理できます。

まれにエラーになる事も。。。

コンポーネントに組み合わせによって、まれに並び順が原因でエラーになる事があります。以下は実際に発生したエラーの例です。計算開始直後にType56でなにやらエラーが発生しています。

*** Fatal Error at time : 1.000000
Generated by Unit : 6
Generated by Type : 56
Message : The GetRadiationData routine has been called before the GlobalRadiationData array has been allocated.

これはTRNSYS内部の関数で呼び出し順が逆転しているのが原因です。たまにこういうのがありますが、エラーメッセージを調べるとコンポーネントの処理順が関係している事が推測できます。

こういうときはSettingsComponent Orderタブで、Optimize components order をクリックして並び順を最適化すればOKです。(手動で並び替えることもできます)

image

最適化する前後の画面を見比べると、後の画面ではType15-6(気象データ)、Type14h(スケジュール)、Type1b(集熱パネル)。。。と、データの流れに沿った処理順になっている事が分かります。
この順だと収束も速くなるので、計算時間もほんのちょっと短くなる可能性があります。

並び順が原因で発生するエラーは、大抵は計算直後に発生します。なにか新しいプロジェクトでは、ひとまずOptimize components order をクリックしておくのもありかもです。

とはいえエラーが発生した際に手掛かりになるのはエラーメッセージです。メッセージから発生箇所と原因を調べて対策を取ることが基本です。

参考:TRNSYSのエラーメッセージの読み方と対策

余談

計算の途中で発生するエラーは並び順には関係なくて、コンポーネントのつなぎ方が違っていたり、計算値が間違っているなど、他の原因が考えられます。
こういうときはエラーが発生しているコンポーネントの上流側の計算値を書き出して検討したり、接続に問題が無いかなど調べて対策を施します。(いま思い出したけど、上流の値調べたら湿度100.2%とか計算上あり得ないケースとかありました)


動作環境

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

2018/08/07

Weather Data Map 北米対応版、只今作成中

Meteonormにつづいて、TMY2形式の気象データへ対応作業中です。TRNSYSに添付の気象データでは北米(US)をカバーしています。

地図にプロットしてみると東海岸が多めです。人口が多いんでしょうか?

image

日本の近くにもアイコンが表示されるので不思議に思ったら、グアム。そういえば、ここも米国領。

image

西海岸の沖に4地点まとまっているのは何かと思ったら、こちらはハワイ諸島でした。この地図だとだいぶ北米に近く見えます。(普段見ている地図だと、太平洋の真ん中に見えますよね?)

image

もうちょっと調整したら、リリースする予定です。

2018/08/09追記

リリースしました。ダウンロードはこちらから。
https://github.com/TRNSYSJP/WeatherDataMap/releases

動作環境

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

2018/08/06

Type24で値を積算したい(TRNSYS-USERSより)

TRNSYSの出力の積分に付いての質問がTRNSYS-USERSに流れていました。

[TRNSYS-users] Integrator output unit

単位がkJ/hの出力をType24で積分すると、タイムステップ1hではkJで出力されている。でも、タイムステップ5分で出力する場合は、単位は何になるのか?

単位はkJです

これ割と陥りがちな点です。負荷量や集熱量などは[kJ/h]で出力されています。これをType24で積分するとステップごとの増加分が少なく見える事があります。

Type24ではタイムステップを考慮して出力値を「レート」から「量」に換算しています。(出力値[kJ/h]から[kJ]に換算して計算します)

タイムステップ1hでは出力値[kJ/h]の値をそのまま集計しても積分した値と同じになります。(単位違うんですけど、結果的に一緒になる)

タイムステップ5分だと出力値[kJ/h]から[kJ]に換算で値が小さくなるので、見比べるとなんか違っているように見えます。(この例だと[kJ/h]x5/10[h]で処理されるので大分小さい値に見えます)

サンプルのBegin.tpfの集熱パネルからの集熱量の出力を、実際にタイムステップ1h(左)と5min(右)で比べると図のようになります。

imageimage

Userful(集熱量)とType24の出力値を見比べると妙に値が小さくなっていますが、単位時間(タイムステップ)ごとの値で処理されているためこのような出力値になります。(正しい出力です)

動作環境

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