Hi,

We just purchased two licenses of Intel Visual Fortran Composer XE for Windows with IMSL. I have downloaded the full installer package and the online installer. I have admin rights on my computer (Windows 7 64 bits). With both installation methods I get a similar error:

With full package: "Error while extracting the file ...\autorun.inf. A file error occured (the system cannot find the file specified)."

With the online installer: "Error writing to file C:\...\antorun.inf. Verify that you have access to that directory".

I also asked our IT person to give it a try with his account and he got the same messages.

Is that a common problem? Is there a workaround?

Thank you very much.

Guillaume 

Hello,

Is there are good way of exporting the compiler settings when upgrading and installing new Fortran Software Updates.

After any new install I if I try to recompile my application typically it would run into hundreds of errors with files and directory includes not found and I will have to manually set them lets say for f90gl libs etc

Is there a way to export the settings beforehand and import them after the new install to make it less painful.

Thanks

I have inherited some FORTRAN code which makes calls to routines written in 'C' and I keep running into runtime errors where parameters are passed or interpreted incorrectly. I have tried using 'INTERFACE' in the FORTRAN code to ensure parameters are passed consistently but it appears that the INTERFACE needs to be declared in every FORTRAN subroutine that makes the calls to 'C'. If you forget to include it, the code compiles but crashes at run-time because it reverts to the default (by ref) calling convention. This is very hard with large programs and is prone to human error. Is there a way to ensure that all FORTRAN subroutines use the correct calling convention without having to search through and include the INTERFACE statements? Perhaps it is better NOT to do this and to ensure that the 'C' code expects parameters to be passed by reference? This seemed like a reasonable approach to me but the FORTRAN compiler appears to allow different size INTEGERS to be passed so the 'C' code might get a pointer to an INTEGER*2 or an INTERGER*4 and BOOM! more runtime errors.

Any advice on how to do this in a consitent and robust way would be greatly appreciated. Please note that I am a C/C++ programmer and know almost zero about FORTRAN (but willing to learn)

Never before I had so much trouble in downloading a new version of Intel Composer XE as with the most recent version SP1 update 2). I did not manage to download the full offline installer packages for the C/C++ and Fortran parts. During download I always received error messages indicating a server timeout, at workdays, at the weekend, at different times of the day, at different stages of the download. I finally managed to install the new version by using the online installer, with server timeout messages as well. But the online installer seems to be able to repair such problems, so the installation was finished successfully. That's what I assumed. I was wrong.

During the first test with the Fortran compiler I received the message "error PRJ0019: A tool returned an error code". What could be the cause for the message? What went wrong during installation? How can I fix the problem? I use Windows 7 Pro 64bit, VS 2012 Ultimate (German version).

  Hello

         I always used fortran but now I have to mix two languages(FORTRAN,C). I followed these steps:

        - I made the 'c' code;

        -I used the 'c' compiler to create the object file(.obj);

       - I created a new fortran project;

 My doubt is only this one: how can I say to the compiler inside the IDE, and not in command prompt, to compile with the c object file? Where is that option?

    thanks in advance

Peter

I am developing a project that includes a module XYGraph and subroutine XYPlot, which I compile for redistribution to other programmers working in my group. The object files XYGraph.obj and XYPlot.obj are put in a library project, CPPf90.lib. The files XYGraph.mod and CPPf90.dbg.lib (my name for the debug build version of the library) were then given to Fred.

The module XYGraph and subroutine XYPlot both contain calls to Intel Quickwin routines SETLINEWIDTHQQ and GETLINEWIDTHQQ. When Fred attempts to build his project, he gets linker errors

"unresolved external symbol _setlinewidth referenced in function _XYGRAPH_mp_..... and similar with _getlinewidth, these are evidently generated by the module; and similar errors apparently generated by the lib file.

Note that the external symbols referenced in the errors do not include the appended QQ that are used in the original code. Is this normal? What other information is needed to pursue this?

The code:

!foo.for

#define DLLIMPORT(name) _EXCLAMATIONDEC attributes dllimport,alias:#name::name

#define DLLEXPORT(name) _EXCLAMATIONDEC attributes dllexport,DECORATE,alias:#name::name 
      subroutine FOO()

      DLLEXPORT(FOO)

      end
!main.for

#define DLLIMPORT(name) _EXCLAMATIONDEC attributes dllimport,alias:#name::name

#define DLLEXPORT(name) _EXCLAMATIONDEC attributes dllexport,DECORATE,alias:#name::name 
      program main

      DLLIMPORT(FOO)

      call FOO

      end

compiled with ivf 2013 running on ia 32 with vs 2010.
the os is win7 64bit
it is compiled with option below to generate exclamation mark:
/fpp /D_EXCLAMATIONDEC=!DEC$

but when link an error occured:
error LNK2019: __imp__FOO

dumpbin -exports foo.lib:

File Type: LIBRARY
     Exports
       ordinal    name
                  _FOO
  Summary
          C0 .debug$S

          14 .idata$2

          14 .idata$3

           4 .idata$4

           4 .idata$5

           C .idata$6

File Type: DLL
  Section contains the following exports for foo.dll
    00000000 characteristics

    53008ECE time date stamp Sun Feb 16 18:11:26 2014

        0.00 version

           1 ordinal base

           1 number of functions

           1 number of names
    ordinal hint RVA      name
          1    0 00001000 FOO
  Summary
        2000 .data

        2000 .rdata

        1000 .reloc

        5000 .text

I'm currently using the GESV subroutine from MKL library  to solve the system of equations (A.x=B). The number I used is Double Precision.

I see the results are accurate up to 11 digits after the decimal point. Now I would like to have the accuracy is up to 16 digits but I can't find the solution yet.

Anyone suggests a solution for that would be highly appreciated.

Thanks a heap!

hello

  I created a c static library with this code:

fileopen.h:

extern FILE *fp;

r.h:

#ifdef HAVE_F77_UNDERSCORE
# define F77_CALL(x)    x ## _
#else
# define F77_CALL(x)    x
#endif
#define F77_NAME(x)    F77_CALL(x)
#define F77_SUB(x)     F77_CALL(x)
#define F77_COM(x)     F77_CALL(x)
#define F77_COMDECL(x) F77_CALL(x)

ex.c:

#include "fileopen.h"
#include "r.h"

static    int jacsng = -1;
static  int jacupd = -1;
static  double jacond = 0.0;

/*
 * output for a single incorrect jacobian entry
 */
 
 void F77_SUB(fileopenclose)()
 {
   fp=fopen("nleqslv.err", "w+");
 }
 
void F77_SUB(nwckot)(int *i, int *j, double *aij, double *wi)
{   
    fprintf(fp,"Chkjac  possible error in jacobian[%d,%d] = %20.13e\n"
            "                         Estimated[%d,%d] = %20.13e\n", *i, *j, *aij, *i, *j, *wi);

}

the library is called test.lib and is linked with this fortran code:

 MODULE INTER

     interface
     SUBROUTINE nwckot(i,j,a,b) BIND(C,name='nwckot')
     use, intrinsic :: ISO_C_BINDING     
     integer (C_INT), value :: i
     integer (C_INT) :: j
     REAL(C_DOUBLE) :: a
     REAL(C_DOUBLE) :: b
     end SUBROUTINE nwckot
     end interface

     interface
     subroutine fileopenclose() BIND(C,name='fileopenclose')
     use, intrinsic :: ISO_C_BINDING
     END subroutine fileopenclose
     end interface

     END MODULE INTER

SUBROUTINE user
USE INTER
INTEGER i,j
DOUBLE PRECISION a,b
CALL fileopenclose()
CALL nwckot(1,2,1.d0,1.d0)
END SUBROUTINE USER

This last sub is called in the main code that I don't show here.

when I run the app I get an access violation error(157) and I know that it is reated with the fprintf code. But why do I get that error?

I am just starting to mixing languages and this is just me trying to learn, step by step, because I have to build a huge app in fortran that uses a lot of c files that I have to turn into a static library to be called inside my code.

thanks in advance

Peter

I'm working to integrate LAPACK and BLAS libraries with a Fortran project in Visual Studio, and I can't seem to get things to work. I have downloaded liblapack.lib and libblas.lib and included their directory in Configuration Properties -> Linker -> General -> Additional Library Directories. I have included "liblapack.lib; libblas.lib" in  Configuration Properties -> Linker -> Input -> Additional Dependencies. However, when I build my program, I get the following errors: "error #11018: Cannot open liblapack.lib;" and "fatal error LNK1181: cannot open input file 'liblapack.lib;'.

Hello!
I am interesting, in wich cases the compiler will force to allocate any of used array from the memory

Case 1:
subroutine VolFracToMassFrac(VolFrac, MassFrac)
  real, intent(in) :: VolFrac(:)  
  real, intent(in) :: MassFrac(:)
    ...
end function

Case 2:
function VolFracToMassFrac(VolFrac, SubstCodes) result(Res)
  real    , intent(in) :: VolFrac(:)
  real Res (SIZE(VolFrac))          
    ...
end function

Case 3:
subroutine VolFracToMassFrac(VolFrac, MassFrac)
  real, intent(in) :: VolFrac(:)  
  real, intent(in) :: MassFrac(:)
      real Temp(SIZE(VolFrac))
    ...
end function

I am using Compaq Visual Fortran, but I am also intresting how it will be in the Intel Compiler.
Thank you

This is perhaps going to be a red herring, but I'm rather suspicious that the recent installation of the ifort update broke user defined macros in VS 2010.

My macros on two separate machines have started playing up very recently - I can't seem to get them to run at all.  This could perhaps (and perhaps probably) be incompetence on the part of this user, but I'm seeing some cmake build issues when using VS 2010 as the "generator" as well that might indicate its macros are having problems.

Is anyone else running VS2010 with latest ifort update out there, that has working user defined macros?

Hi everybody,

I'm about writing a UEL on ABAQUS.

When I'm trying to run it, I'm getting an error message. I've attached the error messages and my code to this message so you can find them easily.

Would you please help me to solve the problem?

Best Regards,

Hi,

this one sounds more complicated then it is.

I have a C++ lib that is linked into a Fortran dll. Now I want to access some functions of this C++ lib from a C# program. But the program doesn´t find the entry point. Calling Fortran routines is no problem.

Could it be that I can just call the C++ lib from the Fortran dll and not from a program that uses that dll?

Thanks in advance,
Markus

While reviewing the Release Notes for the recent compiler update (Intel Fortran Compiler 14, SP1, Update 2) to see what I'm missing out on, I found the following very interesting:

Quote:

3.3.1.4 New /switch:fe_debug_use_inherit Internal Command Line Switch (14.0.2)

 

Examining the parent fields of an extended derived type in the Microsoft Visual Studio* debugger currently requires that you also list the parent name. Add the internal command line switch /switch:fe_debug_use_inherit to your debug command line, and you will be able to use the abbreviated syntax to examine the parent field.

 

For example:

 
    TYPE BASE
       integer Base_Counter
    END TYPE BASE
 
    TYPE, EXTENDS (BASE) :: Type2
    END TYPE TYPE2
 
    TYPE(Type2) :: Foo
 

It is legal Fortran to reference either Foo%Base_Counter or Foo%base%base_counter.  Without the fe_debug_use_inherit switch, you cannot use the former form within the Microsoft Visual Studio debugger.

 

Please note however, if you do set the fe_debug_use_inherit switch, you are unable to use the latter form within the debugger.

 

This internal command line switch will not be supported in compiler version 15.0 as this feature will then be enabled by default.

 

Can our friends at Intel explain how this will work inside of Visual Studio IDE?  I've never used a debug command line switch before (there is always something new to learn!).

This does sound like a cool feature - kudos for Intel for adding it!  I'm also pleased to learn Intel will enable this by default starting with version 15.0 [even though I can only hope management will allow me an upgrade to that version :-(]

When there is a run time error while I am debugging my application via Visual Studio 2013, I expect that the debugger should stop on the line that is causing the problem. However, the debugger unexpectedly stops on a C++ code line in another part of our application.

The details of what is occuring:

1. a traceback dialog box titled "Intel(r) Visual Fortran run-time error" appears. It has correct traceback source code and line information about where the error happens in the Fortran code. The dialog has a single "OK" button.
2. I click "OK"
3. Visual Studio produces a dialog box indicating that my application has triggered a breakpoint. It has two buttons, "Break" and "Continue"
4. I click "Break"
5. The debugger breaks in our C++ code in another thread.
6. I navigate the through all of the threads in the thread window and observe the call stack window for each thread to try and locate the Fortran thread, but it is already terminated

What should should I do to signal the debugger to stop on the Fortran source code line instead of producing the run-time error dialog box with the traceback information? 

In VS2005 the behavior was for the debugger to stop in the Fortran source code and then when trying to continue the traceback information dialog box would be produced.
  
Our application is a C++ executable that calls Fortran dlls.

The Fortran compiler switches are as follows:

/nologo /debug:full /MP /Od /free /warn:interfaces /iface:cvf /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc120.pdb" /traceback /check:all /libs:dll /threads /dbglibs /c

The linker switches are as follows:

/OUT:"Debug\acerate.dll" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"acerate.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"acerate.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:"acerate.lib" /DLL HTRILogging.lib

My system info:

Microsoft Visual Studio Premium 2013
Version 12.0.30110.00 Update 1
Microsoft .NET Framework
Version 4.5.50938

Installed Version: Premium

Intel(R) Visual Fortran Composer XE 2013 SP1 Update 2 Integration for Microsoft Visual Studio* 2013, 14.0.0086.12

Out of the Dark Ages I come with Compaq Visual Studio 6.1 on a desk top using Windows XP Home Edition. Reinstalled program after installation of new hard drive, power supply, and video card. Can access the sample program Celsius. When I try to open a Fortran program that worked previously, I get a message "Microsoft Developer Studio has encountered a problem.....The error report says "Error signature AppName:dfdev.exe  Appver6.081682 Mod Name: devshl.dll   ..plus additional info such as code, flags etc. Is it a good guess that dfdev.exe is corrupted? I can open a fortran program from Windows Explorer and run it sucessfully . If I try to open from within Visual Studio program,the program crashes.

For those who want to have a bit of a giggle...

A while back, as a bit of a F2003 learning exercise I started writing a little Fortran parser in Fortran that lets you do dependency analysis - "tell me what order I should compile my files".  If you are working in Visual Studio this sort of thing is done automagically for you, but if you ever have to drop back to the command line then this sort of utility actually can come in handy.  And sometimes it even gives the right output.

Because it was a learning exercise crossed with delusions of grandeur and a good dash of a tasty cabernet/merlot blend it has been put together from "first principles" - some script kiddy could probably achieve the same in a dozen lines of the scripting language of the day using a few regexes and a hash thingamajig, but honestly people - where is the fun in that?  Plus it does F2008 syntax And Nothing More (it was supposed to be a F2003 learning exercise, but I learn real slow).  And you need fairly recent ifort, because writing this has, at times over the years, felt rather like a ifort compiler testing exercise.

So, if you compile the attached (you need /standard-semantics) , you can do things like the following from the cmd prompt (with extensions enabled):

>>set files= & (for /f "usebackq" %f in (`dir *.f90 /b ^| FF08Depends -`) do @(echo %f & ifort /c /nologo /standard-semantics %f & set files=!files! %~nf.obj)) & ifort /nologo /FeFF08Depends.exe !files!

	CharUtils.f90

	Strings.f90

	ErrorLocations.f90

	ErrorLevels.f90

	Errors.f90

	CompilerKinds.f90

	Sources.f90

	SourceLocations.f90

	Tokens.f90

	MatchUtils.f90

	UseStmtsUtils.f90

	UnitUtilities.f90

	SyntaxParts.f90

	SubmoduleStmtsUtils.f90

	StmtFunctionStmtsUtils.f90

	Statements.f90

	StatementData.f90

	SourceFiles.f90

	ErrorCodes.f90

	CharacterTypes.f90

	Scanner.f90

	ScanFreeForm.f90

	ScanFixedForm.f90

	ProgramStmtsUtils.f90

	ModuleStmtsUtils.f90

	IntegerLists.f90

	IncludeLines.f90

	FileUtilities.f90

	Debug.f90

	CompilerHosts.f90

	Classifier.f90

	FileDependencyPass.f90

	DependencyUtils.f90

	DefaultHosts.f90

	DependsImplementation.f90

	CmdLine.f90

	FF08Depends.f90

(which shows you how to compile and link the tool that you need to compile and link the tool that shows you how to compile and link the tool - and to think Fortran previously couldn't handle recursion...) 

Then combine it with the graphviz/dot tool, and you can also generate lots of wacky diagrams:

Now, for some inexplicable reason I think I might go and have spaghetti for dinner.

Hi,

I am running a large project with 50 subroutines in it. The problem is three-dimensional with lots of array allocation/deallocation.When I run the project, the iteration ends in 2 to 3 days. During the iteration, RAM usage stuck in maximum of 6 GB RAM ( 98% = 5.375.500 K). How can I decrease the RAM usage effectively ? There are lots of suggestions in forum but I don't want to mix them and make the process to end in longer time. Any suggestion ?

Thanks !

In debugging a Fortran routine which does not have direct access to a variable in a calling routine which I would like to use in Execute Immediate for debugging purposes.  I want to know when a special case occurs.

I am using Visual Studio 2012 Update 4 along with a recent version of Fortran Composer.  In Visual Studio 2003, I was able to reference variables from calling routines (I can't remember how but I know it no longer works).  I know that using the Call Stack I can get the value of the variable I want but that is much more time consuming than if I could reference it directly.  Note that the variable I want is "undefined" in the Watch list and doesn't necessarily have its current value.  I can double click on it but it then comes up as 'Undefined'.

Thus, if I have variable VC in the current Fortran routine and I want to use the value of variable CRV in Fortran subroutine CSX in the call stack then in Execute Immediate I would like to do something like

                        VC - 'CSX'.CRV

Can this sort of thing still be done in Visual Studio Debug using Fortran?  It wouldn't appear so from the manual (http://msdn.microsoft.com/en-us/library/sc65sadd.aspx).  Is there a work around for Fortran users?

Apologies if this is not relevant to this topic.  I note that the following query in the forum search provided no help whatsoever:

"visual studio debug  execute immediate reference to fortran variable in calling fortran routine".