This do loop example has NO passes thru it.
dk4=100000000
khi4=huge(k4)/2 ! nowhere near upper limit
klo4=-khi4 ! nowhere near lower limit
kount=(khi4-klo4)/dk4+1
print *,"klo,hi=",klo4,khi4," kount 4=",kount
do k4=klo4,khi4,dk4
print *,"k4=",k4
enddo
It gives the correct result (22) for KOUNT, but the compiler apparently gives ZERO for the same thing.
All variables are integer(4)
In the topic "Declarations of Character Types" of the IVF users reference, it says:
The form CHARACTER*(*) is an obsolescent feature in Fortran 95.
I'm puzzled with the saying "CHARACTER*(*)". The question is elementary maybe, but does it mean the form of old FORTRAN standard " CHARACTER*(some_len_things)" or the * Length Character Syntax which is to be removed from the future standard ?
type :: zmplx2d
complex*16,pointer:: val1(:,:),val2(:,:)
end type
type(zmplx2d),dimension(:),allocatable:: acamats
!$omp parallel do private(ilo,jlo,snedges,fnedges,
& ies,ief) shared(acamats)& schedule(guided)
do j = Levindx(i), Levindx(i+1)-1
ilo = edgeips(2,j)
jlo = edgeips(1,j)
snedges = igall(jlo+1)-igall(jlo)
fnedges = igall(ilo+1)-igall(ilo)
ies = igall(jlo)
ief = igall(ilo)
call farboxInteraction2(snedges,fnedges,acacomps(j),
& acamats(j)%val1,& acamats(j)%val2,ztmp1(ief),ztmp2(ies))
enddo
I want to parallelize the do-loop using OpenMP. the result of the codes is not correct. It seems OpenMP don't support derived types.
Anyone knows why and how to solve this problem ?
On rare occasions, my function DLCONF from the IMSL library exceeds maximum number of function evaluations and I guess it is because my function is flat for some iterations. To avoid that problem, I am curious if there is a way to compute a maximum number of iterations needed to get a convergence as in DZBREN (another IMSL library)?
So before calling DLCONF, I would like to compute the number of iterations needed to get a convergence and call some other routine if maximum number of iterations exceeds my preset value of MAXFCN. So I can avoid that particular iteration with a different routine and my program does not stop iterating? DLCONF so far is fast and I don’t want to entirely switch to a new subroutine.
best
Dear all,
My system is 64 bit with Windows 7.
I want to run ABAQUS 6.13 with a subroutine which should be compiled by Fortran compiler. I have Intel Composer XE 2013 (Intel Compiler 14), which is able to build 32bit and 64bit applications.
The general settings are OK because Abaqus Verfication says it can work with a sample subroutine.
But when I want to do my own simulation it gives again the error:
LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
When Ichanged abaqus_v6.env file (machine type in link_sl and link_exe from /machine:AMD64 to /machine:X86), the error again changed to
export.def : error LNK2001: unresolved external symbol _forceCRTManifestCUR
standardU.lib : fatal error LNK1120: 1 unresolved externals
I first build an object file from my fortran code and the pass it to Abaqus. Maybe the object file is built for a 32 bit application type. I do not know how I can say ifort to build it for a 64bit application type. I searched but no luck. Can you please help me?
Thank you very much,
Vahid
MODULE test IMPLICIT NONE PUBLIC INTEGER, PARAMETER, DIMENSION(6), PRIVATE :: kind_params = [0,1,3,7,9,14] TYPE :: dt(kind) INTEGER, KIND :: kind REAL,DIMENSION(kind_params(kind)) :: comps END TYPE dt END MODULE test
The above code is a stripped down example of something I'm trying to compile that generates an internal compiler error due to the parameter array kind_params being used in the dimension specification of comps.
Dear Steve:
DISLIN is a neat program for drawing plots written by Helmet Michaels in Germany. The program is free for non -commercial use. I bought the really excellent manual whihc explains how to install the libraries.
The library files are installed in a folder called c:\DISLIN
The Module File for DISLIN DISLIN.F90 and DISLIN.MOD is stored in c:\DISLIN\IFC
I set the path command to point to the point to the correct places
Set the DISLIN environment variable to c:\dislin and include
c:\dislin\win in your path. If you have installed DISLIN in a
different directory, you have to use that directory for the
environment variables above.
I then used a VS 2012 Command prompt to run the sample program provided with DISLIN
I also tried setting up a VS 2012 solution and run it from VS.
I get a variety of errors depending on how I configure the VS properties, but the main and first error is ifconsol.lib cannot open file. Helmut suggested the following - this morning
John,
the ifconsol.lib file is part of the Intel Fortran compiler. It seems that the Microsoft linker does not find
this library. I'm just using Visual Studio 2010, where I don't have such a problem. What happens when you
replace the link command by the ifort command. For example:
ifort /c /Ic:\dislin\ifc exa_f90.f90 for compiling
ifort exa_f90.obj c:\dislin\disifl.lib gdi32.lib user32.lib for linking
Best regards,
Helmut
I keep getting the same error - as shown on the attached image whether I use the command line or VS. - I have set the complier variables using the BATCH file.
I am running on a WINDOWS 10 machine - using VS 2012 and the latest Intel Complier - I am not having trouble running any of my other Fortran programs using this system.
Your thoughts would be appreciated - I realize it is something simple - but I am lost
JMN
Question 1.
In the version 10 windows fortran compiler, can the cpu be specifically set to
use which of these floating point calculation modes
single mode (32 bit floating)
or
double mode(64 bit mode)
or
double extgended mode(80-bit)
WHich of the above 3 modes (32,64,80 bit) is the default??
Question 2
In a more up to date version of the fortran compiler
is there more control to instruct the cpu to specifically use for example 64 bit mode floating point calculations
WHat we are seeing is ONLY when the fortran dlls are being run through an EXCEL spreadsheet interface,
sometimes the first time the excel is run values are returned ; but then the second and subsequent runs of the excel
interface produce a consistent set of values that are slightly different from the first set of values (usually differences start
after about 5 significant digits).
the hypothesis is that
1. excel opens and sets the floating point mode
2 the first time the fortran dll loads there is some static initialization that changes the floating point mode.
3 the first run completes
4 control returns to excel which sets the floating point mode back to "normal"
5 the second time the fortran dll is called from excel, there is no further static initialization, so all
floating point numbers are now being calculated in excels mode.......
SO, in version 10 fortran can the floating point mode be set, or what is the default
In more recent fortran releases are there likely to be compiler options that could
clear the problem that run 1 is different from runs 2 and subsequent.
ANy comment is very appreciated.
Thanks
Bill (billg5@yahoo.com)
Problem: A subprogram 'make_child' returns a variable of type 'child' which is an extension of the 'parent' type. 'make_child' itself gets the 'child' from a generic factory, which produces the 'child', but declares it as 'parent' type. (Note: this is not about human genetic engineering, it's a Fortran question...)
Question 1 (Fortran Standard): How can 'make_child' downcast the 'parent'-type into the result declared as 'child', without creating a copy (large data!) ?
What I tried so far:
Question 2 (Intel): In case I use move_alloc nevertheless (if there is no better answer to Question 1), will this non-conforming code compile and work correctly on all future version with ifort?
Code: Here, make_child is a subroutine with intent(out) dummy as result, and not a function. Reason: allocation in a function result cannot be moved to lhs without copying (as Steve pointed out to me in https://software.intel.com/en-us/forums/topic/495399)
Compiles with ifort 14.0.3 and 15.0.1.
program test type :: parent_type end type type, extends(parent_type) :: child_type end type class(child_type), allocatable :: new_child call make_child(new_child) contains subroutine make_child(child) class(child_type), allocatable :: child class(parent_type), allocatable :: tmp ! Create child with help from generic factory ! e.g. in real code: call factory(tmp, make="child") allocate(child_type :: tmp) ! Move allocation in 'tmp' into result 'child' ! Note: not standard-conforming! call move_alloc(from=tmp, to=child) end subroutine end program
PS: I really would like to know a standard-conforming way using allocatables (not pointers) here.
Best regards
Ferdinand
An afterthought ;
Why not use REAL(16) arithmetic to calculate that?
We are always guaranteed to get the correct answer for ANY combination of inputs,
and the most extreme range (-huge to +huge)
You get a REAL(16) result, which you would round off to get the final number.
NO_STEPS = (real(STOP,16) - real(start,16)+real(step,16))/real(step,16)
Since the compiler supports REAL(16) arithmetic, this should not cause any problems.
Anyway, I wanted to see what the compiler guys think about this, since it completely
avoids the integer overflow curse.
I am using VisualStudio2013Pro and Intel(R) Visual Fortran Composer XE 2013 SP1 Update 3 Integration for Microsoft Visual Studio* 2013, 14.0.0092.12.
After compiling/linking in release mode, then sending the executable file to a user, when he runs it, the error message, that libifcoremd.dll is missing, is displayed.
I either need to: (1) link that dll file so that the executable file contains it (preferred, if possible), or (2) have that dll file available to him. I cannot find a way to do (1); if you know of a way, please respond. As far as (2), I have tried sending him the dll file and having the user to place it in the same folder as the program executable file. Then, when he runs the program, it stops unexpectedly.
So, after some investigation, and finding almost no documentation, on (2) above, I am asking for your help. What I really need is a tutorial on how to do this. Some hints exist on the Internet that, along with the Intel Fortran, an executable file or msi file exists for installing, on a user's computer, all the redistributable files. All I find there, however, besides all those dll files, is a msm file which could possibly be used for this purpose (file structure below). I do have InstallShield2013, as well, and I could possibly use this msm file, but no instructions are there to do so.
Surely someone else has experienced this same dilemma. Please help.
C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\intel64\compiler
06/17/2014 11:05 AM <DIR> 1033
06/17/2014 11:05 AM <DIR> 1041
04/23/2014 04:36 AM 305,808 cilkrts20.dll
04/23/2014 04:36 AM 265,216 cilkrts20.pdb
04/23/2014 08:34 AM 429,496 ifdlg100.dll
06/17/2014 11:04 AM <DIR> irml
06/17/2014 11:04 AM <DIR> irml_c
04/23/2014 08:34 AM 212,920 libicaf.dll
04/23/2014 08:34 AM 1,482,680 libifcoremd.dll
04/23/2014 08:34 AM 1,482,680 libifcoremdd.dll
04/23/2014 08:34 AM 1,470,904 libifcorert.dll
04/23/2014 08:34 AM 1,470,904 libifcorertd.dll
04/23/2014 08:34 AM 307,128 libifportmd.dll
04/23/2014 08:34 AM 1,075,640 libiomp5md.dll
04/23/2014 04:37 AM 592,896 libiomp5md.pdb
04/23/2014 08:34 AM 79,800 libiompstubs5md.dll
04/23/2014 08:34 AM 3,438,008 libmmd.dll
04/23/2014 08:34 AM 3,580,344 libmmdd.dll
04/23/2014 08:34 AM 467,384 liboffload.dll
04/23/2014 08:34 AM 9,050,040 svml_dispmd.dll
04/25/2014 06:47 PM 19,910,656 w_fcompxe_redist_intel64_2013_sp1.3.202.msm
Hi
I have an input output question. I am trying to read the values as in the attached text file, until end of file, then multiply the last value (from beginning to end) by a coefficient (example 0.5) and output the table in the same format but with the modified last column. Attached herewith is a test program which I tried to write for this, which appears to go in an infinite loop.
Any pointers and suggestions so as to output the file in the same format would be greatly helpful.
Thank you.
Is there any difference between representations " Z'd[d...]' " and " [s] [[base] #] nnn... " which can be used to represent integer constants ? In my program, the follow two lines generate wired results ( IVF 15.0.1.148 [IA-32] is in use):
! First: This one is all right. INTEGER(KIND=8), PARAMETER :: MaxValue1 = Z'7FFFFFFFFFFFFFFF' ! Second: This one gives an error message: "error #6384: The INTEGER(KIND=4) value is out-of-range." INTEGER(KIND=8), PARAMETER :: MaxValue2 = #'7FFFFFFFFFFFFFFF'
I have clearly declared the integers all have KIND=8 kind type, but why the Second is wrong and the error is about INTEGER(KIND=4) ?
Is it safe to upgrade to Xcode 6.2 or will this break the installed compiler? If it is safe is there anything special I need to do?
TIA
-Zaak
Hello.
I have a fortran multithreaded (omp) code compiled with ifort that runs 24/7 doing
fluid flow calculations. It uses about 6GB of ram and it is run as a series of
self-submitting jobs. The processor is an i7 3930k with 16GB ddr3 @ 1600mhz and
the OS is opensuse but run in konsole. No other application is run on this system
and it not connected to the net.
Each one of the series of these jobs does a virtually identical number of operations -
exept when there is an occasional database dump - so in theory the cpu time used should
be about constant for each of the segments of the run,
The curious thing is that the code runs the fastest after a reboot and
over the subsequent runs the cpu time used creeps up. Over 2 days the cpu
has increased by about 6%. Isolated runs have occured being ~ 20% slower than
average,
Are there any explanations why there this cpu creep?
thanks
--
ps: timing is measured with omp_get_wtime(). also the linux time is used
to time the executable.
The advantage of this method, is:
You don't have to resort to a higher order arithmetic, and you always get the correct result.
integer(8) function two_int(istart,istop,istep)
integer(8) istart,istop,istep,i1m,i2m,i1d,i2d
i1m=mod(istart,istep)
i1d=istart/istep
i2m=mod(istop,istep)
i2d=istop/istep
two_int=i2d-i1d+(i2m-i1m+istep)/istep
end function
This method also works for 4 byte quantities.
Or any number of bytes.
Hello,
I have the following problem with ifort 15.0.2.164 Build 20150121. Even when using "-integer-size 64" I can not create record lager then integer(4) (2^32-1). For the older release of ifort Version 13.1.0.146 Build 20130121 this works just fine. For example
program recltest
implicit none
integer :: reclsize
reclsize=2**31-1
write(6,*) reclsize
open(unit=123,file="test.dat",access="direct",recl=reclsize,form="unformatted")
close(123)
reclsize=2**31
write(6,*) reclsize
open(unit=123,file="test.dat",access="direct",recl=reclsize,form="unformatted")
close(123)
end program recltest
the second open statement works with ifort 13 ( using ifort -integer-size 64 -assume byterecl test.f90 ), while it does not work with ifort 15, giving me the following error message
forrtl: severe (118): The 'RECL=' value in an OPEN statement for unit 123, file test.dat, exceeds the maximum allowed for the file's record type.
Is this a bug or am I doing something wrong ?
Best,
Marius
Wed, May 13, 2015 12:00 PM - 1:00 PM EDT
This session will cover new features in the Intel® Fortran compiler version 16, part of Intel® Parallel Studio XE 2016. Topics include new features from Fortran standards, new OpenMP* features and changes for users of Microsoft Visual Studio*.
This session will be recorded and the recording made available sometime afterward.
Wed, May 13, 2015 12:00 PM - 1:00 PM EDT
This session will cover new features in the Intel® Fortran compiler version 16, part of Intel® Parallel Studio XE 2016. Topics include new features from Fortran standards, new OpenMP* features and changes for users of Microsoft Visual Studio*.
This session will be recorded and the recording made available sometime afterward.
