Migrating projects - Intel Visual Fortran 2013 1.4.237 to oneAPI HPC Toolkit 2021.2 classic Fortran

[MatthewZ]

EDIT: the projects I am migrating are running on Windows 10, x64

Budget constraints have prevented our company from keeping up with the Intel FORTRAN compiler updates prior to this, however, the company was finally able to upgrade to the new oneAPI Base + HPC Toolkit and we are on version 2021.2 of the HPC Toolkit.

We were building in Visual Studio 2013 with Visual Fortran Composer XE 2013, sp 1.4.237

We are now using Visual Studio 2017, and at this point, most of our projects compile in the HPC Toolkit, classic fortran compiler, however, when we run some of our projects in a test program that we have, I am seeing substantial differences in values especially in one project that compiles to a DLL and has functions called by a .Net program.

EDIT: The version that I am running in our test program is 32- bit, as are our other projects. I am aware that 32-bit targets are deprecated in ifort.

I am wondering if there is a guide to migrating from prior versions of the fortran compiler?

Also, is there a guide to what needs to be included from a redistributable standpoint? Previously, I had to include the following dlls for the dll to run properly:

msvcr120.dll, libmmd.dll, libifportmd.dll, and libifcoremd.dll

I have searched the oneAPI tree on my disk, and I was able to find msvcr120.dll, however, it is in the subdirectory 2021.2.0\bin64 of vtune which does not seem like it is in a redistributable directory as I am able to find libifcoremd.dll, libifportmd.dll, and libmmd.dll in what are seemingly redistributable directories.

I also searched the online documentation (perhaps not thoroughly enough), and I was unable to find anything relating to redistributables.

Any help will be greatly appreciated.

[Steve_Lionel]

msvcr120.dll is a Microsoft Visual C++ file and would be part of the Visual C++ redistributables for Visual Studio 2013. If you rebuild using Visual Studio 2017, your application would then be dependent on the Visual C++ DLLs from VS2017. The latest supported Visual C++ downloads (microsoft.com)

You should not copy DLLs - instead, have the redistributable package(s) installed on the target system, corresponding to the versions of the compilers you used. You can find the Intel oneAPI redistributables at Intel® oneAPI standalone component installation files (select "Runtime Versions"). 

The great thing about Fortran, and Intel Fortran, is that "migration" is almost always unnecessary. Just load your sources into a project using the current development tools, build and go. If you are seeing differences in results, that could be caused by application coding errors (uninitialized variables, etc.), algorithms very sensitive to last-bit differences in results, or normal variations due to effects of floating point arithmetic. See Improving Numerical Reproducibility in C/C++/Fortran for more on that.

My usual advice is to try a build with all run-time checks enabled and with compile options that help identify errors. One of the best of those is Fortran > Diagnostics > Check Routine Interfaces.  Compiling with standards checking enabled, or warnings for undeclared variables, can sometimes point out errors that are hard to find otherwise. (There may be a lot of diagnostics here you don't care about, but do look at them all.)

As for 32-bit, you should consider that Microsoft is also deprecating 32-bit support and should investigate what it takes to have your Fortran code work from a 64-bit .NET environment. Standard Fortran tends to be mostly insensitive to address size, as long as you don't explicitly declare address-sized things as 32-bit.

[MatthewZ]

Thanks for your reply, Steve.

---

@Steve_Lionel wrote:

The great thing about Fortran, and Intel Fortran, is that "migration" is almost always unnecessary. Just load your sources into a project using the current development tools, build and go. If you are seeing differences in results, that could be caused by application coding errors (uninitialized variables, etc.), algorithms very sensitive to last-bit differences in results, or normal variations due to effects of floating point arithmetic.

With respect to this, all our projects are setup as Visual Studio solutions that then contain a FORTRAN project. I would like to clarify your statement about loading sources into a project using current development tools.

Do you mean that we should just load our existing solution/project files, or do you mean that we should create new FORTRAN projects in VS 2017, then manually re-add all the FORTRAN source files? The former is what I have done so far, and everything seems to work well except for the FORTRAN compiler issuing a couple of warnings about deprecated options. I searched the forum for this first one, and as I understand it, it is a bug - warning #10434: option /extend_source use with underscore is deprecated; use /extend-source instead

However, I did not find anything on this second warning, but it is similar. option '/Qsafe_cray_ptr' use with underscore is deprecated; use 'Qsafe-cray-ptr' instead There appears to be no way to simply change the compiler option on either of these to clear and/or give the complier what it wants, rather, it seems that we would need to use the "Additional Options" specifying the form with the "-" character instead of the underscore character.

---

@Steve_Lionel wrote:

As for 32-bit, you should consider that Microsoft is also deprecating 32-bit support and should investigate what it takes to have your Fortran code work from a 64-bit .NET environment. Standard Fortran tends to be mostly insensitive to address size, as long as you don't explicitly declare address-sized things as 32-bit.

---

We get that. Part of our "migration" on at least a few of our projects will be to specify 64-bit targets.

Thanks again.

[JohnNichols]

I am not the expert Steve or the others are, but and nevertheless, I have been using VS since about 2005 along with Intel fortran since about that time.  I keep all of my programs in a single project folder - separate of course and I always update to the latest VS currently running Preview 2019 and latest IF.  

As long as you just open an existing solution folder it is likely to run.  As Steve noted if you have copied dll's you may create a world of hurt, and sometimes you need to fix switches, but it is pretty transparent.  OneAPI had a few problems with them cleaning out a lot of crap, but that is easy to overcome - MKL was the worst bit. 

I would copy all of the your existing solutions into a new project folder and just try them.  I run Fortran code that dates to 1968 and generally there are no problems except a few.  

[MatthewZ]

I copied all our source into a separate directory. As I mentioned prior, pretty much everything compiles.

Have you uninstalled the previous versions of the Intel Fortran compiler? Why I am asking is because I am noting that the redistributables directory in my path references the redistributables from the 2013 compiler, and on attempting to run a "release" configuration  of the program/.net consumer, I get an error saying it could not load the fortran dll. Unfortunately, I have to keep the 2013 compiler around for now until we get this migration completed.

I forgot to mention, most of the fortran we have is ancient code.

[JohnNichols]

1. Everything in the engineering world is based on some Fortran code, MAPLE, MATLAB etc.  Ancient Fortran just means it has been shock tested and as the computers improve it improves. 

2. In Fortran I can make a FEM model of 20 GB in 5 minutes from a text file, in PYTHON it would take 100 days and still not be right. 

3. C# is Fortran in disguise but slow. 

4. It is fun so relax it could be worse you could be working in LISP.  

5. As the compilers improve so do we find old errors. 

[MatthewZ]

Thanks for the words of wisdom.

The current project I am working on is an FEA program. I was told by one of the former people who worked on it that it used to take in excess of 6-hours to run on a mainframe. They also coded it on punch-cards. It now takes about 20-seconds to run.

It sounds like the new compliers reveal prior coding errors. Some of what I am seeing could be that. I will just have to work through everything. I am not all that familiar with what the code does, however, I am able to consult the person who worked on it before. Its never too late for a deep-dive into the code.

[Steve_Lionel]

If you are taking an old project that hasn't been built in years, I am generally in favor of creating a new project, as you'll get the advantage of new defaults that may help uncover issues. You will want to review the compile and link options to make sure they are transferred properly. But you can certainly start by just opening the old one, building, and see what you get. 

Some alternate option spellings have been deprecated over the years. Look first at the Command Line property page of the project and see if those have been entered in manually. If so, correct them or, if possible, use the project property for that option rather than a manual override.

[MatthewZ]

Thanks for your reply, Steve.

All the projects we have build with the 2013 compiler. None of them have any manually entered compile or link options; however, I am considering taking your advice to recreate the projects in the new compiler anyway.

The two switches I previously mentioned are not correctable using the appropriate property page when opening the 2013 version of the project. Changing the option to inherit from project defaults, then back to the option as the compiler wants to see them, i.e., with hyphens instead of underscores, does not create an entry with hyphens instead of underscores, rather, it simply uses the old option with underscores, and the warning about the option being deprecated persists. In one of my projects, the warning appeared for every single file during the compilation.

IMO, I do not see how these particular spelling changes resulted in any improvements.

[Steve_Lionel]

The underscores are being phased out for consistency - for a long time, either was allowed. I don't think either of those options has its own project property, so they were manually added on the Command Line property page.

[MatthewZ]

---

@Steve_Lionel wrote:

I don't think either of those options has its own project property, so they were manually added on the Command Line property page.

---

FYI - Within Visual Studio (2013 or 2017), at least, they can be found by going to the project properties page -> Fortran -> Language -> Fixed Form Line Length for the "extend_source" option, and project properties page -> Fortran -> Data -> Assume CRAY Pointers Do Not Share Memory Locations for "Qsafe-cray-ptr"  I have created a new project for one of my projects in the oneAPI classic fortran compiler 2021.2, and I note that if I set both of these properties as above, it puts the deprecated, i.e., the ones with the underscores, into the command line when looking at properties page -> Fortran -> Command line. So it appears that in order to work-around the warning, both options would have to be set manually through properties page->Fortran -> Command LIne -> Additional options.