Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Right product for me?

jciii
Beginner
464 Views
I've just started working with a bunch of scientists who program in fortran, remotely on some super-computer cluster. They all just SSH into the machines and use VI / emacs to do their programming. However, I've become comfortable using MS Visual Studio while programming in C++. I'd really like to continue developing in that type of environment.
I'd also like to do most of the work locally, so I can use a GUI, without suffering painfully slow X11 tunnels.

I was looking for the following:
1) plugin for MS visual studio or a similar environment
2) possibly being able to compile on a remote (linux) machine
3) possibly being able to debug remotely as well.

I believe IVF is the ticket for 1. But, I have no idea how to accomplish 2/3... is it even possible? Can IVF do that? I'd appreciate being pointed in the right direction.

Thanks
jciii

0 Kudos
2 Replies
TimP
Honored Contributor III
464 Views
ifort for linux is licensed separately from Visual Fortran for Windows. It's basically the same compiler, without GUI support (and without requirement for commercial 3rd party tools). Debugging options range from no extra cost command line debuggers to commercial tools, most of which work with multiple compilers.
0 Kudos
Nick2
New Contributor I
464 Views

Go for IVF. Believe me, there is absolutely nothing wrong with using multiple and different compilers - quite the opposite. At work, I use CVF 6.6, IVF 10 (eval for now), G95 on Linux (it would be nice if I could devote the time to learn to debug with it), and Digital Fortran 90 on the Alpha systems (unforunately terminal-based, and a mild pain to debug). Our customers use anything from Intel/AMD PCs running Windows and Linux to Sparc and IRIX systems, you name it.

CVF and IVF are my primary tools. A few folks in my company use Lahey. A few only use the Alpha and DVF. A bunch are CVF-only. Either way, I stick with my own development tools of choosing - as does everyone else; things somehow still work out well. When it comes time to release the product, we compile itwith all (or most) of the above combinations of compilers and platforms, and run the FLINT tool.

What happens is, one compiler will catch some error, another compiler catches something else, and in the end we end up with a better product. Our QA requirements include testing on different platforms/compilers. Most errorsare either debuggable in CVF/IVF, or caught at compile-time with others. For the one or two crashes I get a few times a year on non-CVF/IVF platforms, well, heck, I let somebody else more familiar with the platform fix it.

Every so often, I also find a compiler bug (in my opinion,current development cycles are too aggressive); Intel and G95 folks have been the most responsive in working with me and fixing the problems. That's why I still use them :)

To summarize...if you like IVF, get it. Unless you have a code with a whole bunch of platform-specific junk, you'll be quite happy you did.

0 Kudos
Reply