Translate

2017/01/31

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

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

TRNBuildの初期値ではZoneの顕熱容量は、気積分の値が設定されています。(室内の空気分の顕熱容量として設定されています)

実際簡単なモデルで試すと。。。

image

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

image

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

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

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

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

[TRNSYS-users] capacitance- TRNBUILD-TRNSYS 17

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

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

2017/01/30

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

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

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

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

image

BALANCE 1 - SOLAR BALANCE FOR ZONES (NTYPE 901)

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

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

2017/01/27

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

image11

2017/01/23

CONVEX and CLOSED

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

2017/08/25 上記赤字部分追記

CONVEX

直訳すれば凸型です。でもだからといって下図のような形状を作るとエラーになってしまいます。

image

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

image

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

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

上述したようにこの形状ではエラーになってしまいます。なにか対策ないかと、もしかして1つのZoneでもAirnodeで分ければOKだったりとしてと、淡い期待を抱いて試してみました。結果からというと、やはりエラーになってしまいます。プログラム上うまいこと処理してくれるかと思ったんですが、やはりZone単位でしっかり判定しているようです。(まあ、考えてみれば同じ室内なんだから当然か)

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

CLOSED

図形として閉じていない場合もNGなんですが、これは通常モデリングしている限り作られません。意図的にCLOSEじゃない図形を作るというより、なんらかの事故でたまたま出来上がってしまうケースではないかと思います。

image

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

2017/01/22

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

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

www.kankyoukei.com

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

.comなので、なんだか会社みたいですがブログ専用です。今までの記事のURLもそのままアクセスできます(リダイレクトされます)

とはいえ、ドメインの変更に伴って「いいね!」がすべてリセットされてしまったのが少々残念。まあしょうがないっかー。

2017/01/18

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に登録しておきました。

image

2017/01/17

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

source-code-583537_1280

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

大量の計算到来

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

繰り返しは得意なんです

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

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

対応の幅を広げる

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

プログラミング言語

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

2017/01/16

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を作成してください。

image

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

image

image

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

image

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

image

.esoファイルの指定

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

clip_image001[6]

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

アニメーション表示

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

image

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

clip_image001[8]

おまけ

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

動作環境

2017/9/5 追記

以下の環境で動作を確認しています。

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

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

2017/01/13

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

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

Radiation modeの設定

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

image

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

・Beam radiation distribution
・Diffuse radiation distribution
・Longwave radiation exchange within a zone

image

.esoファイルの出力設定

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

image

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

clip_image001

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へ名称変更されています)

clip_image001[7]

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

clip_image001[9]

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

image

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

2017/01/12

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

前々回試したTRNSYS/Type56で温度分布を計算するモデルの作り方の紹介です。

何はなくても計算用の建物のモデルが必要になります。手始めにモデルの準備をします。

SketchUpで床面を分割したモデルを作成

モデルの作り方は通常の多数室モデルの建物とまったく同じで、TRNSYS3D Pluginを使って作成します。図は試しに作成した単室のモデルですが、計算結果がわかりやすいように南側の外壁、西寄りの位置に開口を設けています。

image

次に計算対象の面を適宜分割します。と言っても特に特殊な作業ではありません。「線」ツール(鉛筆のアイコン)を選んで、分割したい面に線を入れていきます。図では等分割にしていますが、詳しく検討したい箇所を細かく分割するのもOKです。(例えば窓周辺をもっと細かく分割して日射の影響を検討するなど)

image

モデルができあがったらTRNBuildへインポートしてSimulation Studioで計算のモデルを作成します。図はトレーニングテキストのモデルをベースにして作成した計算用のプロジェクトです。

image

TRNBuildでOutputを追加する

床面の表面温度の出力を追加します。

① 対象のZoneを選択
② surface outputsの項目を選択
③ 出力項目にTSI(内表面温度)を追加します。
④ つづいて、出力項目をダブルクリックして温度を出力する面を指定します。

image

下図のように床面のSurfaceをすべて出力するように指定します。

image

つづいて、TRNSYS3D Plugin(SketchUp)で表示するための出力の指定ですが、それは次回へと続きます。

2017/01/11

日付時刻から通し時間へ換算

正月明け早々、足を挫いてしまって三連休は自宅警備員として過ごしました。熱があるわけでもないのにじっと動かずにいるのって苦痛ですよね。
あまりに暇なので、HTML5アプリの開発に挑戦してみました。HTML,CSS,JavaScript、それにOnsen UIを少々加えて。。。もはや環境工学とかTRNSYSと全然関係なさそうで、何の話か怪しいですが、できあがったのが下のスマホアプリ(iPhoneで実行中)

image

日付を選ぶと、通し時間に換算して表示します。翌年の日付まで対応しているのでTRNSYSの助走計算で年末を超えて計算する場合も問題なし。

ちなみにAndroid でも動く。

image

まあ、やっていること自体は対応表と大差ないですが。。。いちいち表を引っ張り出して調べるのも面倒なんですよねー。仕事柄、日付時刻から通し時間へ換算する機会が多いので、こういうツールがあるとだいぶストレスが減ります。実測データなど、期間が変則的なデータを使うときに重宝しそうです。

2017/01/10

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

Type56のDetailed ModeとTRNSYS3Dを使って、たぶん出来るだろなーとはわかってたんだけど、やってみるとやっぱりビックリする。(間違っていないか少々心配だが。。。)

床面の温度をSketchUpで表示してみた図

image

手前左側の白い矩形が窓で、床面に日射が落ちて表面温度が上がっている様子が表示されています。もうちょっと床面細かく分割すると見栄えがするんだけど、しまった。

計算と表示の仕組み

大まかな流れとしては。。。

① SketchUpで床面を分割したモデルを作成
② TRNSYSの計算結果をType125で.esoファイルへ出力
③ TRNSYS3Dには.esoファイルを基になったモデルへプロットする機能(なんとアニメーションもできる!)があるので、それを使って表示する(上の図)

とまあ、こんなようにSketchUp/TRNSYS3Dを使ってモデリングから計算、表示処理を行います。

image

具体的な作り方は後日まとめます。

2017/01/06

TRNSYSの助走計算

前回の日付時刻の話にも関連しますが、計算を行う際には助走計算(助走期間)が必要になります。
助走というと、陸上なんかの助走をイメージしてしまって、コンピューターで計算するのになぜ助走?という気になりますが、そこにはそれなりの事情があるのです。

鶏が先か卵が先か

TRNSYSでは(というかシミュレーション全般ですが)何らかの条件を設定して計算を行います。建物であれば壁や窓の構成、内部発熱、建設地の気象条件などさまざまな条件を設定します。それらを元に計算の結果として室内の室温や湿度などの値が出力されます。ところが条件の一つとして、室温や湿度も必要になります。これから行う計算の結果として出てくる値を条件として指定するのも変な話に聞こえます。でも何か値が無いと次の時刻の室温が計算できないのです。これは計算の開始時点では不明なので、初期値として任意の室温、湿度を条件として設定します。TRNBuildの初期値では室温20℃として計算を開始します。

助走計算

計算を進めると気象条件など、その他の条件の影響で初期値から徐々に正しい値に近づいていきます。逆に言うと計算開始直後の室温は初期値の影響を受けます。図は初期値から2/1~2/28を計算した室温のグラフです。計算開始から数日間は室温が初期値の20℃から下がり続ける傾向が見て取れます。(自然室温/暖冷房なし)

image

真冬の時期なので自然室温で20℃付近というのはかなり怪しい結果です。初期値の影響が大きく出ています。このグラフに1月から計算を開始した結果、つまり助走計算を1ヶ月取った結果と重ね合わせると。。。

image

一目瞭然ですが、2/1~の室温が大幅に違っているのが分かります。徐々に同じ室温に近づいていきますが、数日どころか計算開始から1ヶ月後(2月末)になってようやく同じ計算結果になります。

このように計算を開始した直後は初期値の影響を大きく受けるので、適切な助走期間を見込む必要があります。一般的には2週間から1ヶ月の助走計算を取ることが多いのですが、建物の形状や規模、仕様などによっても影響するので、そのあたりは調整が必要です。長めに助走計算を行うのは問題ありませんが、その分、計算時間が長く掛かかります。繰り返し何度も計算を行うようであれば、ほどほどの長さに設定します。

1月のための助走はどうする?

この話の流れで考えると、年間暖冷房負荷など1月を含む計算では、1月は常に初期値の影響を受ける事になります。まあ、実際そうなります。それでは困るので、こういう場合は図のように1ヶ月分を助走として12/1(8016h)から計算を開始、翌年の12/31、つまり17520h(=8760h x 2)までを計算します。(都合13ヶ月の計算になる)

image

Control Cardsの設定は図のようになります。

image

繰り返しになりますが、最初の1ヶ月(12月分)は初期値の影響を受ける助走期間です。その部分は忘れずに無視して、それ以降の計算結果(翌年の1月~12月末)を採用すればオッケーです。

しかし、まーなんちゅーか、グラフにすると助走期間のあり/なしの差がすごくてビックリした。助走期間は、やっぱり少なくとも1ヶ月ぐらいは取らないと駄目ですね。

2017/01/05

あけましておめでとうございます

本日、1月5日より仕事始めです。お正月は田舎でゆったりまったりと過ごしました。
まったりしすぎて、いろいろ忘れていないか心配な仕事始めです。気を引き締めていきましょう。

TRNSYSの日付時刻

さて、仕事始めという事でTRNSYSの日付時刻の扱いの話など。
TRNSYSの計算の中で時間は標準的な一年は365日x24hを時間で0h~8760hとして扱います。うるう年という概念はありません。(うるう年の実測結果を使うような計算だと少々混乱しそうですが、2/29を3/1に読み替えて使うのかな?)
1/1の0:00からの経過時間で表すので、例えば本日1/5は96h(1/5 0:00)~120h(1/5 24:00,1/6 0:00)になります。このあたり直感的に解りにくいので、以前に書いたように日付時刻を出力するコンポーネントと組み合わせると分かりやすくなります。
Simulation StudioのControl Cardsでは時間に関連した項目の「More...」ボタンをクリックすると月ごとの時間のリストが表示されます。大まかにはこちらが参考になります。

image

例えば、7月から8月の2か月の計算であれば4344h~5832hと指定します。

image

一工夫して。。。

特定の日付時刻を指定してい計算する場合は、このリストの値から日付、時刻で換算して設定を行います。とはいえ、繰り返しになりますが直感的に分かりにくいので、予め日付との対応表を用意しておくと悩まなくて済みます。

ということで、本年も8760hよろしくお願いいたします。