Hi
Can Intel comment on this topic? I have received an "update" on the issue submitted several years ago to Premier Support. The issue ID is 0000596485. However, I don't think it is working.
Abhi
↧
Status of Array Visualizer/Viewer
↧
VIsual studio crashes
Since installing the version 15 update, visual studio often crashes. At least two ways:
* With lots of files open in solution/projects, right click file tab and select "close all but this", crashes immediately.
* When changing source code branch using external git program, when switching back to visual studio it ask whether to reload files - on confirming it crashes.
Both were fine previously.
Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Version 4.5.50938
Intel® Parallel Studio XE 2015 Composer Edition for Fortran Windows* Package ID: w_fcompxe_2015.0.108
Intel® Parallel Studio XE 2015 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2013, Version 15.0.0107.12, Copyright © 2002-2014 Intel Corporation. All rights reserved.
* Other names and brands may be claimed as the property of others.
(I tried submitting an issue on the business portal but get error about The requested URL was rejected. Please consult with your administrator. Your support ID is: 1340398033970549014)
↧
↧
Allocatable Huge
Dear Steve:
I was reading the old Microsoft FORTRAN reference manual about allocatable - it says you need to use the huge statement - what is the huge statement - is it not required anymore?
JMN
↧
Module referencing/usage
Hi
I have a kind of hypothetical question...
I have two modules A, B, and a main program P. Module B uses module A and Program P uses module B. (That is, they contain use moduleB and use moduleA statements, respectively.) In order to compile program P, the .mod files for "both" module A and B must be "visible" through the search paths for the modules (i.e. Include directories, working directory, directory of source file etc etc.).
I wonder if the standard says anything about the expected behavior. (I guess not.) What I am looking for is -- isn't/shouldn't/couldn't visibility of moduleB.mod be enough. (I imagine that it would mean size of moduleB.mod file will be bigger.)
Abhi
↧
Must nullify a pointer before check associated status in IVF.
hi,
I do known that pointers should be nullified by null() or nullify or associated to variable before checking associated status in deed.
Now I have a very large project in Lahey fortran, all pointers are not nullified before checking associated status, but it have worked well for decades of years.
Now, I need to transplant it to IVF for some reason, 99% of the upper situation brings no problem, associated function returns false as expected. But there surely is a very little case that associated function returns true, which makes program crash. My question is: is there any laws, or i must change them all, but it will be a quite big job.....
Thanks!
↧
↧
fatal error LNK1104 cannot open file "\Debug\...EXE"
Hi
I always got the same error when I rebuilding the project in in fortran complier on Visual Studio. And It seems that the .EXE in debug folder couldn't be delected when I rebuild the project, thus the error occurs.
I using Microsoft Visual Studio 2008 Tools for Office, and Intel(R) Visual Fortran Composer XE 2013 Update 3 Integration for Microsoft Visual Studio* 2008, 13.0.3624.2008, Copyright (C) 2002-2013 Intel Corporation.
thanks
Youwei
↧
Diagnostic for incompatible arguments to MOVE_ALLOC
MOVE_ALLOC requires that `to` be type compatible with `from`. Could the compiler please diagnose when this requirement is not met.
MODULE m
IMPLICIT NONE
TYPE :: NotMyParent
END TYPE NotMyParent
TYPE :: NotAnExtension
END TYPE NotAnExtension
CONTAINS
SUBROUTINE proc
CLASS(NotMyParent), ALLOCATABLE :: to
TYPE(NotAnExtension), ALLOCATABLE :: from
!****
CALL MOVE_ALLOC(from, to)
END SUBROUTINE proc
END MODULE m
>ifort /c /check:all /warn:all /standard-semantics move-alloc-not-an-extension.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 201407 26 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. (... hours of fun and games begin here...)
↧
Project Only: Link only ... fails
This right click menu option in Visual studio used to do what it says and just link. Now it deletes intermediate files first and then of course can not possibly do a link. Using VS2010 with Fortran Compiler XE 13.1.3.198.
↧
Stack Overflow
Hi,
I have an error message forrtl: severe(170): Program exception - stack overflow
My program is doing some grid search. It ran with a small number of grids, but then I got this message when I increase the number of grids to the realistic level. I read the topic https://software.intel.com/en-us/forums/topic/299402 but I still don't understand. ( I use Intel Visual Fortran Compiler with IMSL libraries (use include 'link_fnl_static_hpc.h') and I ran the program by clicking Start without debugging so I don't know what "ifort" is.
Anyone could suggest me the way out of this ?
Thank you very much.
↧
↧
VS 2010 Integration does not work well
I am using Intel Parallel Studio XE 2015 in Visual Studio 2010 Professional on Windows 7 64-bit Professional. I uninstalled all version of Intel products and installed just Parallel Studio XE 2015 today, but I am still having problems with the VS integration.
I have a console application and the source code is in fixed form .for files. There are several minor problem I am experiencing:
Problem 1:
I have a .for file that contains several simple modules, let's say:
module Fields
integer(kind=4), allocatable, dimension(:,:) :: fieldInt2D
real(kind=8), allocatable, dimension(:,:) :: fieldDouble2D
end module Fields
module Properties
real(kind=8) :: propertyDouble
end module PropertiesIf I start typing "use" anywhere in the code, a list pops up, but it only contains the name of the first module (Fields) and other items in the list that probably correspond to the other modules, but these other items have empty names, so it is not possible to know which one should be selected from the list.
Problem 2:
It often happens that if I hove the mouse pointer over a subroutine call, the list of this subroutine's arguments contains "NONE :: argument1" even though the argument type is specified in the subroutine. It is difficult to give an example as I was not able to find any rule for situations with this problem, but one example would be:
subroutine write_2D_field_double ( x, iunx, finame )
use ifport
use ifwin
include 'frequent.inc' ! contains nx, ny declared as integer(4)
real(8), dimension(nx,ny) :: x
integer(4) :: iunx
character(20) :: finame
...
return
endHovering over the subroutine or its call shows "NONE :: x"; the other arguments are OK.
Problem 3:
Local variables declared as "logical(4) :: logVar" do not show any tool tip when the mouse pointer hovers over their names in the code. The statement "logical" is shown as the intrinsic function in the tooltip, but the compiler understands it is a declaration of a logical variable. Changing the declaration to "logical(kind=4) :: logVar" does not help.
↧
Stack overflow with PACK statement in new V15 compiler
Hi guys,
another issue related to the new V15 version of your Fortran compiler.
The following statement worked fine up until the latest V14, but crashed with a stack overflow using V15:
REAL, POINTER :: BUFFRB(:,:,:,:)
ALLOCATE(BUFFRB(200,200,4,2))
mt_pklv = PACK(BUFFRB(1:200,1:200,1:4,2),.TRUE.)
Do you have any idea, what happened here. I guess, that PACK uses some temporaries on the stack instead of the heap and therefore crashes.
mt_pklv is an REAL vector huge enough to hold all elements of BUFFRB().
Thanks & regards,
Andreas
↧
Catastrophic error when using sNaN
Hi
Attached file when compiled with "ifort /Qsave /Qinit:snan /Qinit:arrays" gives a catastrophic error with XE 2015 (package 108); i.e. the latest release.
Abhi
| Anhang | Größe |
|---|---|
Herunterladen Test_sNaN.f90 | 644 Bytes |
↧
optimization do loop
I am wondering if in the following DO-loop, the introduction of the new INTEGER variable upper_index in place of the two identical calculations x_index(i,l) + N will have a benefit to the performance? I have already timed this loop and compared it to the original loop, and the runtime ratio indicates ~1.40 performance gain.
DO i = 1,N
upper_index = x_index(i,l)+N
coef(i) = 0.5 * vz(x_index(i,l),l)
g2(i) = 2. * ( a(upper_index,k,l) - a(x_index(i,l),k,l) ) / ( dz(x_index(i,l)) * (1.0 + az1(x_index(i,l)) ) )
IF (s(x_index(i,l),l) <= p1 .OR. s(upper_index,l) <= p1) g2(i)=0.0
END DOThis loop is nested in loops over K and L
However, when I tested the same idea in the following simple loop, I did not see meaningful difference in the speed of the code.
do i = 1,nloop1
do j = 1,nloop2
k = i+j
variable(k) = k
end do
end doWhich one of the above two observations I can possibly trust?
Also, I noticed that the use of IF-ELSEIF construct is noticeably less efficient than using multiple IF statements in a DO-loop. Is this observation correct? I am using Intel Fortran compiler 2015, with O2 optimization flag.
Thanks you in advance,
↧
↧
Assignment of array sections
I am using Visual Fortran Compiler XE 15.0.0.108 [IA-32]
I am doing a simple assignment like this:
satfln(:,:,:,app) = fulsln(:,:,:,app)
Both satfln and fulsln are explicit size and shape arrays, both defined in the same module as real, dimension(0:2,2,20,8).
This assignment works fine in a debug build but when I compile with all the optimisation turned on, some elements are not assigned, e.g.
satfln(:,:,1,app) are assigned but satfln(:,:,2,app) aren't.
Also, satfln(:,:,1:3,app) = fulsln(:,:,1:3,app) works but satfln(:,:,1:20,app) = fulsln(:,:,1:20,app) does not. I feel like this has to be a bug in the latest Version 15.
Can anyone shed any light on this?
Mark Besley
↧
Intel Fortran Compiler without preinstalled Visual Studio
Hi.
Sure that this question was asked already, but I have troubles with finding answer. So,
I'm planning to purchase fortran compiler and now are using trial version.
(download full install package of Intel Parallel Studio XE 2015 from https://registrationcenter.intel.com through registration procedure.)
Problem is that there is no any version of Visual Studio in my system so I can't integrate fortran compiler into it.
I skim some pages in here and realize that free express version of VS doesn't support work with fortran compiler. Well, I uninstall it, after that fortran wizard notes that VS 2010 shell can be installed, but that option is unactive because valid license is not found. I suppose that reason is trial version of Parallel Studio, only after buying license installation of VS Shell becomes possible. But in that case it doesn't make any sense to use trial version, I just can't start working to evaluate this.
My main question is
1), that VS 2010 Shell, is it full development enviroment which allows to create, build and debug application from scratch, if I'm using fortran language only?
if yes, then
2), Is it really possible to create any fortran application with trial version of Parallel Studio and without any Visual Studio installed before? I know about starting from command line, but that option seems ineligible for me.
My operating system is Windows 7 x64 and I'm planning to use Windows 8 in future.
Thanks in advance.
↧
Class design questions
I have a product with the following internal structure: 1) a Root_Solver module to have all the root solving routines necessary to solve problems; 2) a base class FuncBase used by the Root_Solver module so that it may access functions to solve; 3) children of the base class to encompass individual needs in the program.
I am running into an implementation problem that has to do with some of the child classes requiring specific solver routines for internal calculations. Obviously this may lead to circular referencing. So how might one handle this?
Specifically, child FuncOne requires a routine from the Root_Solver to solve for an internal variable. At the same time, child FuncOne has class functions used to solve for other variables using another Call. I get no build problems when I create the output, but when run the program complains vehemently after the internal solver routine is called that the FuncOne class variables are all undefined.
↧
Splitting dummy arguments out from /warn:unused
Could some consideration be given to splitting out variables that are dummy arguments from the "This variable has not been used" warning.
Failing that, could we have a "!DEC$ PLEASE_PRETEND_THIS_IS_USED(xxxx)" or similar directive that suppresses this warning for the variable named xxxx in the scope of the directive.
Procedures that implement a binding for a derived type often have arguments that are superfluous to that particular type, so the general nature of /warn:unused is a bit chatty. It is still quite handy for non-dummy variables though, so I don't want to disable it entirely. Being able to specify /warn:all /warn:nounused_dummy would be quite useful.
↧
↧
String Length Argument and arrays
This may sound a bit complex, but here is my problem. I am in the process of building a project that needs to use netcdf. I'm using an older build (3.6.3), which, when I build it with Fortran bindings requires the compiler switch '/iface:mixed_str_len_arg' to work correctly. I'm building them into static libraries so I can then include these in another project where I build a fortran DLL that. I then call this new DLL from a C# program. Passed variables all work now, except for arrays. They get passed into the C# program at the correct length, but the elements in the array are all 'Undefined address'. If I leave off the '/iface:mixed_str_len_arg' compiler switch, the NETCDF libraries won't work, and the string then get clobbered in the pass. And none of these problems existed until I added in these NETCDF libraries...without them everything works fine - except I need them for my project. Any thoughts? Am I going about this totally backwards? I am using Visual Fortran Composer XE 2011 with Visual Studio 2010.
↧
Debugging derived types Composer 15.0 in VS2010
Dear all,
When debugging an extended type that gets the base type form another module, The VS2010 integration gives a syntax error, see the following screenshot
The type is defined as follows:
TYPE, EXTENDS(SL_CaseType) :: SLNK_CaseType
Is there are workaround present to see the contents of the extended type in VS2010?
Regards,
Dirk
↧
Dllexport Function in Subroutine
Hello,
following Code is okay. But I am not sure how to export/import that routines!? The subroutine calls the function.
subroutine RandomFibers(nFib, r, nCellsY, nCellsZ, initW, initH)
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: 'RandomFibers' ::RandomFibers
implicit none
real, dimension (nFib) :: fibCoY, fibCoZ, ranR
integer i, j, k, counter, nFib, nFibCell, nCellsY, nCellsZ, nRestFib
real(8) y, z, rad, delta, dwide, dheight, initW, initH
! parameter for ploting
real, dimension (nCellsY) :: yMin, yMax
real, dimension (nCellsZ) :: zMin, zMax
real r
! calculate and round number of fibers per Cell
nFibCell = (nFib / ( nCellsY * nCellsZ))
! calculate boundaries (dwide / dheight) of cell from initial RVE size
dwide = delta(nCellsY, initW)
dheight = delta(nCellsZ, initH)
!calculate random fiber coordinates in the boundaries of each cell
call random_seed
do i=1, nFib
call RANDOM_NUMBER(y)
call RANDOM_NUMBER(z)
call RANDOM_NUMBER(rad)
fibCoY(i) = 0.0 + y * (initW - 0.0)
fibCoZ(i) = 0.0 + z * (initH - 0.0)
!ranR(counter) = (rad - 0.5) * r / 20.0 + r !calculate random fiber radiu
end do
end subroutine RandomFibers
function delta(nCells, initLeng)
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: 'delta' ::delta
implicit none
integer nCells
real(8) initLeng, delta
delta = (initLeng - 0.0) / nCells
end functionexecute program:
program run
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS: 'delta' ::delta
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS: 'RandomFibers' ::RandomFibers
implicit none
integer nFib, nCellsY, nCellsZ
real(8) initW, initH, dy, dz
real, dimension (11) :: yLeft, yRight
real, dimension (11) :: zBottom, zTop
real r
nFib = 900
r = 0.2
nCellsY = 30
nCellsZ = 30
initW = 20.0
initH = 20.0
Call RandomFibers(nFib, r, nCellsY, nCellsZ, initW, initH)
end program run
↧