カテゴリー: 開発

さて、前回、新しく作ったコンポーネントがTRNSYSから認識されない状況に陥りました。

原因は参照しているMSVCR110.DLLが見つけられないこと。

このファイルが何かというと、一般には「Cランタイムライブラリ」と言われるファイルです。コンポーネントはFORTRANで書いているので、なんでCのランタイム参照してるんだという気もしますが、まあ、必要なんで参照してます。

単純な話、このMSVCR110.DLLをTRNSYSから認識できるパスに放り込んでやればエラーはでなくなります。

例）VS2012では以下のフォルダに格納されています。

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist\x86\Microsoft.VC110.CRT

このフォルダから、DLLをC:\TRNSYS17\Exeフォルダにコピーします。これであっさり解決です。

落とし穴

と、ここで落とし穴が待ち構えています。この「Cランタイムライブラリ」、TRNSYS自身も参照しています。しかも厄介なことに、少し前のバージョンを参照していてファイル名も違っています。（具体的にはMSVCRT.DLLという名前のファイル）

図にすると、こんな感じ。

ここで何が問題かというと、TRNSYS本体とコンポーネントの間で参照先が違うので、実行時に齟齬が発生するケースがあります。（大部分は問題ないのですが、一部の処理で齟齬が出ます）

なんちゅーか、初版と改訂版のテキスト混在みたいな感じですかね。同じ授業なのに人によって使っているテキスト違っているから、受講者の理解している内容が違っているみたいな。ちょっと違うか。

具体的な例としては、データファイルを参照しているコンポーネントだとTRNSYS本体が割り当てたLUがコンポーネント側から見えないといった問題となって現れます。TRNSYSのデータとしては問題ないのに、エラーで動かない状況になります。

こういう時は基本的に新しい方に合わせてしまうのがよろしい。という事でTRNSYS（TRNDLL.DLL）も同じライブラリを参照するようにビルドし直してやればOK.

図にすると、こんどは、こんな感じ。

同じライブラリを参照するようになるので、齟齬もなく安心して使えます。

実作業としてはTRNDLL.DLLを開発中のコンポーネントと同じコンパイラで再ビルドすればOKです。

計算型のコンポーネントを作ったら。。。

条件が成立するまでWaitと計算を繰り返すコンポーネントを作ったら、止まらなくなりました。

いや、いずれ条件が成り立てば止まるんですが、途中で止めたくても止まらなくなってしまいました。

具体的にどうなるかというと。。。

計算が全く進まない状態。条件の成立を待ちをしているので、これはこれで正常な状態。

でも途中で止めたくなって「Abort」ボタンをクリックすると。。。。

これが、本格的に問題があるようなメッセージになってしまう。とほほっ。。。

これはなんか格好が悪い

これって、Windowsのイベント処理の問題というか、コンポーネントが計算に夢中になって処理を返さないのが原因。VBなんかでも計算型のプログラムを書くと陥りやすいパターンです。VBにはDoEvents()っていう便利な関数が用意されているので、適当なタイミング、一般的には時間の掛かりそうなループの途中で呼んであげれば簡単に解決できます。

しかし、今回はFORTRAN。そんな便利な関数はない。というか、言語仕様にそんな機能があったら変だ。

だが、そこはIntel FORTRANのこと、なんか用意してそうだと思ったら、やっぱりありました。Win32 APIを直接呼び出しているサンプルが！

ということで、DoEvents()もどきのサブルーチンに仕立ててみました。

こいつを適宜呼び出すことで無事に解決。

! 呼出し側   

! 計算の途中でイベントの処理を流す   

Call DoEvents() !Windowsイベントを処理する

!-----------------------------------------------------------
! イベント処理   
!-----------------------------------------------------------
SUBROUTINE DoEvents()
use IFWINTY
use USER32
use IFLOGM
logical lNotQuit, lret
integer iret
TYPE (T_MSG) mesg
lNotQuit = .TRUE.
do while (lNotQuit .AND. (PeekMessage(mesg, 0, 0, 0, PM_NOREMOVE) /= 0))
  lNotQuit = GetMessage(mesg, NULL, 0, 0)
    if (lNotQuit) then
      if (DLGISDLGMESSAGE(mesg) .EQV. .FALSE.) then
         lret = TranslateMessage(mesg)
         iret = DispatchMessage(mesg)
      end if
    end if
end do
END SUBROUTINE DoEvents

TRNSYS-Usersを見ていたら、FORTRANコンパイラの設定の質問が流れていました。

[TRNSYS-users] No single-threaded DLL option

Type29をビルドしなおしてみたら、コンポーネントからのファイル作成時にエラーになってしまうようです。現象としては”fort.xxx”というファイルの書出しに失敗するというもの。

対策としてコンパイラの設定を変更しようとしたけど、該当項目がない。しょうがないのでWindowsXpとCompaq　Fortranで対応したどWindows7の環境で何とかならんの？という質問。

これと全く同じ話で最近悩んだので、以下、備忘のため書いておきます。

質問者のメールには書いてないけど、この件の対策の元ネタはTRNSYSのドキュメントの以下の記載。

7.5.2.6. Troubleshooting multiple DLL’s

ここに原因と対策が記載されているんですが、悩んだのが対策の記述。

set “Project Settings\Fortran\Libraries” to “Single-threaded DLL” in the Visual Studio

Visual Studioでライブラリーの設定を変更しろとありますが、Intel Visual Fortran(以下、IVF)のライブラリーの設定に”Single-threaded DLL”って無いんです。

でも、IVFの場合はここで、単に”Mutli-threaded DLL”を選べばOK。エラーの原因になるのはSingleかMultiかの違いじゃなくて、ライブラリーをDLLにしているかStaticにしているかの違いです。

ということで”DLL”の方を選べばOKです。

実際の設定画面のキャプチャーを載せておきます。

• Release

• Debug

ただ注意しないといけないのは、TRNDLL側も同じ設定にしてビルドしないと、やっぱりエラーになります。

FORTRANのソースコードの形式には固定形式と自由形式があります。前者はいわゆるFortran77互換の形式、後者はFortran90です。

Intel Fortranはどちらの形式にも対応していて、デフォルトではファイル拡張子で区別しているようです。

拡張子による判定

TRNSYSが書きだすコンポーネントの雛形は拡張子*.forで書きだされます。つまり、Fortran77形式ですね。最初、この切替方法に気づかずに悩んでしまいました。

2019/4/25追記
TRNSYS18から拡張子は”.f90“に変更されています。

あるソースコードではコンパイルできるのに、同じ書き方を別のソースコードで書くとエラーになる。例えば、一行72文字を超えたコードがソースコードによってビルドできたり、できなかったりします。

新旧のソースコードが混在するときは、拡張子で分けてくれるので重宝しますが、それに気が付かないと、あれっ？ってな感じになります。

ちなみに一括してどちらかの形式を指定したい場合は、プロパティダイアログの以下の項目で設定します。

TRNSYSの開発環境の話

FORTRAN / goto_

TRNSYSの開発環境といえばインテルFORTRANが標準です。最新版は「インテル® Visual Fortran Composer XE 2013 Windows版」（以下、XE2013）です。
TRNSYSに添付するソリューションは、少し前のXE2011版用ですが、コンパイラの系列としては同じものなので2013でもビルドできます。

このXE2013はパッケージとして2種類販売されています。

インテル Visual Fortran Composer XE 2013 Windows 版 日本語版
インテル Visual Fortran Composer XE 2013 Windows 版 IMSL 同梱

IMSL（IMSL Fortran 数値計算ライブラリー）が同梱されるか、されないかの違いです。このライブラリには数値計算に便利な関数が大量に含まれています。計算によっては、かなり使い勝手の良いライブラリです。
価格が倍以上違いますが、予算的に余裕があれば購入して損は無いです。

が、最新版ではIMSLの配布条件が変更されています。詳細は販売代理店のサイトに記載がありますが、配布先にもライセンスが必要になります。
例えば、IMSLの関数を利用して開発したコンポーネントを配布しようとすると、配布を受ける側にもライセンスが必要になります。

特定の計算用途で開発者自身が使用する場合は問題になりませんが、将来的に配布や販売などを想定している場合は、この配布条件に注意が必要です。無償で公開しようとしたら、IMSLの配布条件できない、なんてことが想定されます。注意して下さい。