Accessing IMSL in Visual Studio .NET Using IVF Pro

[lpartin1]

I must be missing something simple. I got my first dll accessing IMSL to work in Visual Studio .NET but I had to give it the full paths to IMSL include folders and linker libs. What's the right way?

Also, there was an error when uninstalling IVF to install the new package ID. I'm attaching a Word document showing the error.

Thanks,
Lee

[g_f_thomas]

Yes that's how you do it:

In Tools/Options/Intel Fortran/Libraries have an entry
C:Program FilesVNICTT5.0libintel32

and in Includes have the entries

C:Program FilesVNICTT5.0includeIntel32
C:Program FilesVNICTT5.0includeIntel32_s

Ciao,
Gerry T.

[Steven_L_Intel1]

I wouldn't recommend adding both the intel32 and intel32_s paths for includes, as only the first will be used. I would suggest adding intel32_s to your project's properties for additional INCLUDE folders only if you are bothered by linker warnings about locally defined imported symbols.

I've attached a draft of an update to the User's Guide for use of IMSL. You may find it helpful.

[Steven_L_Intel1]

The "package failure" error can and should be ignored. Click "No" on these message boxes to NOT disable the other package support. We're not sure what causes this - seems to be a VS.NET bug.

[g_f_thomas]

The advantage of putting ...Intel32_s via Tools/Options/... is that it's a set and forget approach applicable to all IVF projects, whereas the alternative requires one to remember to do it on a per project basis. Anyways, not worth quibling over.

The VNI release/useage notes allude to the two modules numerical_libraries.f90 and numerical_libraries_f90.f90. The former compiled module is in include but the latter isn't compiled and it's not clear what it's for.Any ideas?

Ciao,

Gerry T.

[Steven_L_Intel1]

The reason it does little good to add the _s folder is that the filenames in it are identical to those in the non-_s folder, therefore, unless you reverse the order in Tools..Options, the second folder will never be used. There's nothing you can do in your project to cause the _s files to be searched without adding it as a project (not global) directory.

The .f90 files are there for reference - they are handy to check what the declarations are if you're having problems with interface matching. The second file is the newer variant that uses generics and is the basis for the xxxx_INT modules (though you don't get the actual sources for those modules.) See the Introduction to the IMSL User Manual for more details on this new interface style. However, the older styles (USE NUMERICAL_LIBRARIES or just calling routines a la F77) still work.

[Steven_L_Intel1]

Some additional useful notes:

• Don't use /iface with IMSL - it assumes the Intel defaults. This issue may go away in a future version.
• Character strings are incorrectly declared in the IMSL interfaces as arrays of single characters. I've asked VNI to fix this for the next release.
• You need to make sure that the appropriate IMSL LIB folder, as well as the Intel compiler BIN folder, are on your PATH if you use any of the DLLs or use the SMP versions of IMSL, otherwise the DLLs won't be found.

[g_f_thomas]

I see what you mean. Thanks for the clarifications.

Ciao,

Gerry T.

[lpartin1]

Thanks, Steve. That will help greatly. It has been difficult to get started without the information. I got it to run but I still have issues around the tasks involved and what files are required for program distribution.

Lee

[Steven_L_Intel1]

Ah, distribution. Yeah, I should add a page on that.

If your program is linked statically, then you're all set. Otherwise, you'll need to include a copy of each IMSL and Fortran DLL the program is linked against. If you use MKL, you may need all of the DLLs in the IMSL LIB folder.

As a licensee of Intel Visual Fortran Pro, you have the right to freely distribute your IMSL-containing application and the required DLLs to as many end-users as you want at no charge (VNI would charge you for run-time licenses). There is one caveat, though. The end-user system may not be a cluster nor a SMP machine with more than 4 processors. For distribution to such systems, you must purchase a run-time license from VNI - I have no idea what the pricing is.

Note that you cannot redistribute programs linked against the "debug" versions of library DLLs (this means Fortran and MSVC - IMSL doesn't have these.)

Read the license texts carefully - they're availabke here.

[lpartin1]

Thanks, Steve. In the past, there was a single run-time fortran dll that I distributed with the application dll.

That reminds me of another issue for the IDE. Did you explain the need for setting a resource directory for the dynamically linked IMSL libs so that the program runs within IDE?

Lee

[g_f_thomas]

Other IMSL issues worthy of mention IMO include:

1. Its use of MKL if you have licensed MKL and what happens if you haven't (and, at the risk of having my knuckles rapped, if the Intel Shop doen't impede your licensing of MKL!)

2. /fpe:3 vs /fpe:0, the Intel default. 3 is favored by numerical analysts but Fortran users like to have their programs crash, heck, it's fun and only hurts for a while.

3. Multithreading, or the lack of thread safety with IMSL, againstNAG, say. It boggles how IMSL can support OpenMP but not provide thread safe libraries.

4. An IMSL type library as opposed to the 'new' fangled interface which is not at all helpful to the user, indeed it smacksmore like a design of benefit to IMSL with little consideration to the user. In what way is IMSL integrated into VS.NET? It isn't and in this regard it's dragging IVF down. VNI could have made a modicum of effort at pretending that their product lives up to Windows 2K/XP user's expectations. Such attitudes come at a price.

5. Its error reporting mechanism needs to be brought forward from its early '80's design. IVF targets Windows 2K/XP users and it's high time IMSL in use with IVF did likewise. Again, they've thrown IMSL appropriate for Linux at Windows 2K/XP users and expectthem to be grateful. BTW, is IFC Pro (by which I mean IFC + IMSL) free for Linux?

6. Alternatives to IMSL. Lahey offers MATFOR. NAG is available but not attractively bundled with IVF. Math Libraries are a dime/dozen for Intel to offer such at a song, so really what's IMSL's big attraction?, hardly it'sinflated price relative to its time-invariant value.

Ciao,

Gerry T.

[Steven_L_Intel1]

Lee,

There is still a single Fortran run-time DLL to distribute. With CVF, there was no IMSL DLL at all. If you make use of the parallel processing features of Intel Visual Fortran, there may be additional DLLs.

I don't understand your question about resource directory. As is always the case with Windows, DLLs need to be in one of the locations Windows will look for DLLs, and the IDE doesn't change that.

Gerry,

VNI has just released a thread-safe version of IMSL. I don't know the status of that as regards to Intel Visual Fortran Pro. As for type libraries, etc., feel free to send your suggestions to VNI.

[lpartin1]

Thanks, Steve.

Next, I'll find out the name of the single run-time fortran DLL and what .NET IDE feature controls when it is used.

I found the resource directory issue when trying a project from another thread. It shows how to use Matlab routines from IVF .NET. I had to update the fortran and linker include directories. It would then compile and link properly.

I tried to run the application from within .NET. It failed due to not finding the Matlab dll. I added the resource include directory and it worked. I suppose that the same issue holds for when you use the IMSL run-time libs.

I was spoiled by CVF. All that I needed wasthe use numerical_libraries command and it took care of the rest of these IMSL issues.

Lee

[Steven_L_Intel1]

All I can find of a "resource includes" directory is something related to resource (.rc) files. What exactly did you have to change?

It was simpler in CVF because there was only one choice for libraries. With IVF Pro, there are four, with additional capabilities not available in CVF.

[lpartin1]

Steve,

I did a right-click on the fortran project within Solution Explorerand selected Properties. Then, I went to Configuration Properties / Resources / General. Under Additional Include Directories, I typed the same folder as I had to input in Configuration Properties / Linker / General / Additional Include Directories.

Without this addition, the program would not run within .NET (F5 command or Debug..Start. It failed on finding the library.

I expect that the same is true for run-time IMSL libraries when used.

Thanks,
Lee

[Steven_L_Intel1]

Interesting. You must not have chosen to update the system environment variables when you installed IMSL. I will have to look at that option to see what it does.

[lpartin1]

Steve,

I remember clicking Yes at a prompt that mentioned something about updating the registry for IMSL usage. I also had it update the path during my last IVF install.

What are the environment variables supposed to do for me?

Lee

[Steven_L_Intel1]

The primary issue is that you need the IMSL "lib" folder included on PATH so that the DLLs there can be found. The compiler has the same issue for its DLLs - if you don't allow it to add to the environment variables, you can't run programs that use the Fortran library DLLs without amending PATH.

You can manually add the necessary folder to PATH. The default would be C:Program FilesVNICTT5.0libintel32

[lpartin1]

Thanks, Steve, but I am confused by your statements. They seem to apply to running IVF from the command prompt instead of .NET.

I typed PATH at a command prompt and found that it already has the IMSL folder that you mention. I suppose that it was added during the IVF installation by answering yes to the Path addition. In fact,the folder is listed three times at the end of the path. Does your software uninstall remove it??? But again, what does that have to do with running within .NET?

I found something interesting within .NET. Go to Tools .. Options .. Intel Fortran .. General. It gives Project Directories for Executables, Libraries and Includes. The first entries are $(IFortInstallDir)Bin, $(IFortInstallDir)lib and $(IFortInstallDir)Include. What are the proper entries to tell it about IMSL? I'll try with the full path names.

Lee

[Steven_L_Intel1]

The "path to executables" is only for executables that the IDE runs - the compiler, linker, etc. The documents I pointed you to give the details as to what goes where.

PATH is needed for DLLs when running programs, no matter where you are running them from, unless the DLLs are in the same folder as the EXE, in the "current folder", Windows or Windows System folders.