Quantcast
Channel: Intel® Software - Intel® Visual Fortran Compiler for Windows*
Viewing all 5691 articles
Browse latest View live

Which version of Intel Fortran Compiler to be used with ASPEN PLUS V10

$
0
0

Hello everyone,

I am a PhD student. I am working in ASPEN PLUs V10 for my research work. Now, I have to use an Intel Fortran compiler and link it with ASPEN PLUS V 10 for a custom user mode operation. Can you please help me and suggest which version of the Intel's Fortran compiler will be compatible. 

I have done a thorough research in the ASPEN PLUS directories and found that ASPEN PLUS V 10 is based on Intel Fortran compiler 2013 SP! and Microsoft Visual Studio 2013 Update 3. But when I try to find the product: Intel Fortran Compiler 2013 SP1, I can not find the product to order online.

Has it (its name) got changed? I am not sure. Please help.

 

Thanks a lot


EXCEL - FORTRAN DLL

$
0
0

Possibly someone out there has experienced something similar?

Finally got beyond the "bad entry point" issue signified by error 453.

Excel is "talking" to the fortran DLL.

Issue is now the following:

1 - when the fortran is compiled without debugging, the DLL is able to be executed one time and it will work fine.  The second attempt to use the DLL returns 65535 values and obviously does NOT run correctly.

2 - when the fortran is compiled with debug and there is an effort to debug the DLL through connection through the spreadsheet, at the end of the run and just before leaving the fortran subroutine, the following error is thrown....."cannot find the VBE7.PDB".

3 - finally, when the code is compiled with debug and NOT stepped through and, instead, just executed, it throws an error 11, division by zero.

Incidentally, there are no "hits nor runs nor errors" evident with the same EXACT code when compiled through the console.

Runs every time.

Any help appreciated.

Thanks.

(empty)

$
0
0

This was a topic for which I have found the answer myself

 

 

Unexpected Submodule Behavior

$
0
0

Someone please look into the case. These USE statements in MODULE scope (Tip 1) were correctly compiled but those in SUBMODULE scope(Tip 2) were not. The error for those in SUBMODULE scope is:

error #6580: Name in only-list does not exist or is not accessible.   [FUNC]

Compiler version: 2018 initial.

BTW, only one scope of USE statements were used when testing. Appreciate any replies.

AttachmentSize
Downloadapplication/octet-streamtest.f902.06 KB

We have an existing Fortran floating license through 29/03/2016 but can't use 2016 Update 2

$
0
0

I believe the 2015 license needs to be upgraded to work with 2016 but I can't see how to do this.

Can some please advise how I can get this to work?

exe file size when using MKL

$
0
0

I have an exe that is about 10 mb when using IMSL, and about 20 mb when using MKL.  So I'm wondering if I'm doing something wrong in the building of the MKL version.  The code runs fine in both flavors.  The code uses MKL routines for elementary matrix operations, linear solving, eigenvalues and ODE integration.

ASSOCIATE vs Setting Local Variables Which Is Best?

$
0
0

Hi All,

 

Just wanted to get peoples opinions to using the ASSOCIATE command compared to setting a local variable within a Fortran Subroutine.

Bellow would be an example code where I either use associate to use the shorter symbols A and B

and the other option of just having a local variable (say double precision) set to the values stored and then use them.

  ! 
  ASSOCIATE ( A=>TYP%SUBTYP(I)%SUBTYP(J)%PROP1, B=>TYP%SUBTYP(I)%SUBTYP(J)%PROP2 )
         !
         !Do stuff with A and B
         !
  END ASSOCIATE
  !
  ! OR
  A = TYP%SUBTYP(I)%SUBTYP(J)%PROP1
  B = TYP%SUBTYP(I)%SUBTYP(J)%PROP2
  !
  !Do stuff with A and B
  !

The main question is which would would be more beneficial to use, at what point does it become too many variables to reassign values (say if I had variables A-Z that were set). It seems like there would be a hit for copying the memory over to the local variables, but I am unsure how much of a speed hit there would be with initiating an ASSOCIATE local environment.

 

Thanks for your inputs!

Unsupported 16-bit application

$
0
0

 

Hi, Intel tech support staff,

Our have  a 64 bit , Windows Server 2016 standard , 4 socket 72 core skylake computer. We  have Intel Parallel Studio XE2018 and  MS Visual Studio 2015 installed on it.

When I compile a Fortran code, the compilation completes without any error. But when the application begins to run,  I get a Windows OS message saying that the application is 16bit and will not run under the 64 bit OS. Detailed messages are given below:

" Unsupported 16-bit Application:  The program or feature cannot start or run due to incompatible with 64-bit versions of Windows, Please contact the software verdor to ask if a 64-bit Windows compatible version is available. "

Please tell me what's wrong with our computer? how to deal with this issue?  This Fortran code is compiled  well with Intel 2018 Fortran compiler and runs well under Linux. This error is only from Windows platform.

Thanks in advance.


Extends Abstract Parameterized Derived Type

$
0
0

Hi, the following code snippet can be compiled but the compiler showed a warning messge that I didn't quite understand.

module test1
    implicit none
    
    private
    public :: tp1
    
    type, abstract :: tp1(length)
        private
        integer, len      :: length = 10
        character(length) :: s
    contains
        procedure(isub1), public, pass, deferred :: sub1
    end type tp1
    
    abstract interface
        subroutine isub1(this)
            import tp1
            class(tp1(*)), intent(in) :: this
        end subroutine isub1
    end interface
    
end module test1
    
module test2
    use test1, only: tp1
    implicit none
    
    private
    public :: tp2
    
    type, abstract, extends(tp1) :: tp2
    end type tp2
    
end module test2

warning #7925: An interface-block in a subprogram that contains an interface-body for a procedure defined by that subprogram is non-standard.   [TEST1^ISUB1]

If tp1 is not a parameterized type, the inheritance is just OK. So is there any restriction for extending an abstract parameterized derived type ?

MKL link2019 error when using Release mode

$
0
0

When I compile my code using Debug mode it is build successfully but when I try the Release mode I get linking error.

I am using some MKL functions:

1>RBUS.obj : error LNK2019: unresolved external symbol DGETRF referenced in function CLASS_STIFFNESS_mp_STIFFNESS_INVERSEK
1>RBUS.obj : error LNK2019: unresolved external symbol DGETRI referenced in function CLASS_STIFFNESS_mp_STIFFNESS_INVERSEK
1>RBUS.obj : error LNK2019: unresolved external symbol DPOSV referenced in function MDLSOLVER_mp_MKLSYMSOL
1>RBUS.obj : error LNK2019: unresolved external symbol DGESV referenced in function MDLSOLVER_mp_MKLSOLVE
1>RBUS.obj : error LNK2019: unresolved external symbol DGETRS referenced in function MDLSOLVER_mp_MKLSOLVEFACT
1>x64\Release\RBUS.exe : fatal error LNK1120: 5 unresolved externals

I could not figure out why this is happening.

dual solution, bug in the code or compiler error?

$
0
0

I just noticed each time I run my model, initial steps are exactly same until after a specific step I get slightly different results.

First I was almost sure that I made a mistake in my code but when I visualize the results I see that each case makes sense:

Solution 1: a crack starts from A and propagates

Solution 2: a crack starts from B and propagates

I now suspect dual solution; but I don't understand how it is possible that one code can generate different results each time I run it.

I am not using any randomization and the problem is exactly same.

I would appreciate if you could help me to understand 'what am I facing'?

AttachmentSize
Downloadimage/pngDaul Solution.png8.4 KB

ifort

$
0
0

Was compiling and running fine for some time.

All of a sudden, I am getting this warning.

1>ifort: warning #10182: disabling optimization; runtime debug checks enabled
1>GPS_MAIN_EXE.F90
1>Linking...
1>Embedding manifest...

I cannot turn on optimization (off the debug) under any circumstances.

I used to have the optimization enabled all of the time ad indirectly enable the debugger through the RUN TIME stack frame and array bounds.

Now, nothing works.

HELP!

Migrating a project from an older version of Intel Visual Fortran

$
0
0

I am migrating a large solution from an older version of Intel Fortran. The old solution file contained the following:

Microsoft Visual Studio Solution File, Format Version 12.00

# Visual Studio 2014

 

The old project file contained the following:

 

<?xml version="1.0" encoding="UTF-8"?>

<VisualStudioProject ProjectCreator="Intel Fortran" Keyword="Console Application" Version="11.0" ProjectIdGuid="{5981CACF-B133-49CD-A4B1-FB8BD7983C3F}">

 

I currently have Visual Studio 2015 installed alongside Parallel Studio 2016. I'd like to migrate the above mentioned files to this new setup. After making a dummy project on the new GUI to see what the reference header is for the new system, I changed the solution header to :

 

Microsoft Visual Studio Solution File, Format Version 12.00

# Visual Studio 14

 

I tried changing the project header to:

 

<?xml version="1.0" encoding="UTF-8"?>

<VisualStudioProject ProjectCreator="Intel Fortran" Keyword="Console Application" Version="16.0" ProjectIdGuid="{5981CACF-B133-49CD-A4B1-FB8BD7983C3F}">

 

But this gave me an error. When I changed it back to Version="11.0" it worked.

 

It seems incorrect that Fortran 2016 should show Version="11.0" in the project file header. Am I doing this correctly? Also the compilation procedure was extremely slow, but that might be a question for another thread.

 

Please let me know if I am doing anything wrong, and whether or not I can fix it.

 

Thanks!!

mkl_intel_thread.dll missing??

$
0
0

Hi all,

I was able to successfully compile and run my code using the MS Visual Studio interface -- both on Debug and Release modes. Curiously, though, when I run the exact same executable from the command line, I receive an error message "The program can't start because mkl_intel_thread.dll is missing from your computer. Try reinstalling the program to fix this problem."

Any clue about what can be going on?

Many thanks,
Rafael

catastrophic error: **Internal compiler error

$
0
0

Hi:

I am getting this error whenever I try to compile with -O3, let me know if the source code is required. I will try to update to the latest version of the compiler.

Kind regards

Marco

 

1>------ Rebuild All started: Project: euoxigen, Configuration: Release x64 ------
1>Deleting intermediate files and output files for project 'euoxigen', configuration 'Release|x64'.
1>Compiling with Intel(R) Visual Fortran Compiler 18.0.1.156 [Intel(R) 64]...
1>MParameters.f90
1>MExpadj.f90
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\MExpadj.f90(73): remark #7712: This variable has not been used.   [R]
1>Math.f90
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(564): remark #7712: This variable has not been used.   [I]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(191): remark #7712: This variable has not been used.   [I]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(133): remark #7712: This variable has not been used.   [I]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(74): remark #7712: This variable has not been used.   [I]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(564): remark #7712: This variable has not been used.   [J]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(191): remark #7712: This variable has not been used.   [J]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(133): remark #7712: This variable has not been used.   [J]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(74): remark #7712: This variable has not been used.   [J]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(179): remark #7712: This variable has not been used.   [NLINEAR]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(120): remark #7712: This variable has not been used.   [NLINEAR]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(132): remark #7712: This variable has not been used.   [ROWFMT]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(73): remark #7712: This variable has not been used.   [ROWFMT]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(448): remark #7712: This variable has not been used.   [K]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Math.f90(450): remark #7712: This variable has not been used.   [VECES]
1>MCvode.f90
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\MCvode.f90(323): remark #7712: This variable has not been used.   [ICON]
1>010101_14291
1>catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
1>compilation aborted for D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\MCvode.f90 (code 1)
1>main.f90
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\main.f90(238): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
1>Mkinsol.f90
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(19): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(51): remark #7712: This variable has not been used.   [T]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(51): remark #7712: This variable has not been used.   [IPAR]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(51): remark #7712: This variable has not been used.   [RPAR]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(105): remark #7712: This variable has not been used.   [T]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(105): remark #7712: This variable has not been used.   [FY]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(105): remark #7712: This variable has not been used.   [H]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(105): remark #7712: This variable has not been used.   [IPAR]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(105): remark #7712: This variable has not been used.   [RPAR]
1>D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\Mkinsol.f90(105): remark #7712: This variable has not been used.   [WORK]
1>
1>Build log written to  "file://D:\Users\Administrativo\Documents\Source\Repos\euogit\Console1\Console1\x64\Release\BuildLog.htm"
1>euoxigen - 1 error(s), 0 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

 

AttachmentSize
Downloadapplication/octet-streamMCvode.f9012.02 KB

error #5082: Syntax error, found ',' when expecting one of: )

$
0
0

Hi, I got this error when I write my own code. It's look strange because the syntax I think is correct. The error  exist in this part 

auE_h=(-uCe,(uDx-uCe)/2,0)

Any help will be great thank you and here I posted the whole code

PROGRAM BACKWARD

IMPLICIT NONE

! Declaration parameter

    ! INTEGER TYPE
INTEGER, PARAMETER :: NX=300
INTEGER, PARAMETER :: NY=30
INTEGER dx, dy, i,j, maxIter, maxNMiter, n

    ! REAL TYPE
REAL, PARAMETER :: L=15
REAL, PARAMETER :: H=1
REAL(8) alpha_u, alpha_p, Cs, err, Ho, Hs, nu, Re, uMax


REAL(8) uCe, uCw, uCn, uCs     !CONVECTIVE TERM PARAMETER FOR u 
REAL(8) vCe, vCw, vCn, vCs     !CONVECTIVE TERM PARAMETER FOR v 
REAL(8) dudy, dudx, nutu       !SGS CLASSIC SMAGORINSKY PARAMETER for u
REAL(8) dvdy, dvdx, nutv       !SGS CLASSIC SMAGORINSKY PARAMETER for v
REAL(8) uDx, uDy               !DIFFUISIVE TERM PARAMETER for u
REAL(8) vDx, vDy               !DIFFUISIVE TERM PARAMETER for v


    ! REAL TYPE WITH DIMENSION
REAL, DIMENSION(NX+1,NY+2) :: u, uold, ustar, uprime
REAL, DIMENSION(NX+2,NY+1) :: v, vold, vstar, vprime
REAL, DIMENSION(NX+2,NY+2) :: p, pstar, pprime        
REAL, DIMENSION(1,NY+2) :: uLeft
REAL, DIMENSION(1,NY+2) :: vLeft

REAL(8) auE_h, auW_h, auN_h, auS_h
REAL, DIMENSION(NX,NY) ::auE
REAL, DIMENSION(NX,NY) ::auW
REAL, DIMENSION(NX,NY) ::auN
REAL, DIMENSION(NX,NY) ::auS
REAL, DIMENSION(NX,NY) ::auP
REAL, DIMENSION(NX,NY) ::dU
REAL, DIMENSION(NX,NY) ::dV

REAL(8) avE_h, avW_h, avN_h, avS_h
REAL, DIMENSION(NX,NY) ::avE
REAL, DIMENSION(NX,NY) ::avW
REAL, DIMENSION(NX,NY) ::avN
REAL, DIMENSION(NX,NY) ::avS
REAL, DIMENSION(NX,NY) ::avP

REAL(8) apE_h, apW_h, apN_h, apS_h
REAL, DIMENSION(NX,NY) ::apE
REAL, DIMENSION(NX,NY) ::apW
REAL, DIMENSION(NX,NY) ::apN
REAL, DIMENSION(NX,NY) ::apS
REAL, DIMENSION(NX,NY) ::apP
REAL, DIMENSION(NX,NY) ::bpP

REAL, DIMENSION(NX,NY) ::ux            ! Convergence coeff
REAL, DIMENSION(NX,NY) ::uxold
REAL, DIMENSION(NX,NY) ::vx
REAL, DIMENSION(NX,NY) ::vxold 
REAL(8) cmax_1, cmax_2, convergence       !CONVERGENCE


REAL, DIMENSION(1,NY) ::Y 

! FILL THE VALUE
maxIter=50000       !INTEGER VALUE
maxNMiter=1

alpha_u=0.3         !REAL VALUE
alpha_p=0.7
Cs=0.07
err=1e-5
Ho=1.0
Re=100
nu=2e-3 

dx=L/NX
dy=H/NY  !Step size
Hs=H-Ho
uMax=Re*nu/Hs
! ALLOCATE THE GUESS VALUE AND INITIAL CONDITION

u(:,:)=0
uold(:,:)=0     !INITIAL CONDITION
ustar(:,:)=0
uprime(:,:)=0
dU(:,:)=0

v(:,:)=0
vold(:,:)=0     !INITIAL CONDITION
vstar(:,:)=0
vprime(:,:)=0
dV(:,:)=0

p(:,:)=0
pstar(:,:)=0
pprime(:,:)=0
uLeft(:,:)=0

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!    SIMPLE SCHEME APPLY FROM HERE &
!!!!        CLASSIC SMAGORINSKY SGS
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

DO n=1,maxIter

! STEP 1a, solve x-momentum as ustar
DO i=2,NX
DO j=2,NY+1
! Convective flux terms use CENTRAL DIFFERENCE
uCe=dy*0.5*(uold(i,j)+uold(i+1,j))
uCw=dy*0.5*(uold(i,j)+uold(i-1,j))
uCn=dx*0.5*(vold(i,j)+vold(i,j+1))
uCs=dx*0.5*(vold(i,j-1)+vold(i+1,j-1))
! Calculation for rate of strain tensor
dudy=(0.5*(uold(i,j)+uold(i,j+1)))/dy
dudy=(0.5*(uold(i,j)+uold(i+1,j)))/dx
nutu=(Cs*FLOAT(dx))**2*((0.5*(dudx+dudy)**2)**0.5)*(dudx+dudy)
! Diffusive flux term
uDx=(FLOAT(dy)/FLOAT(dx)*((1/Re)+nutu)) 
uDy=(FLOAT(dx)/FLOAT(dy))*((1/Re)+nutu)
! ASSEMBLY COEFFICIENT FROM HYBRID SCHEME
auE_h=(-uCe,(uDx-uCe)/2,0)
auW_h=(uCw, (uDx+0.5*uCw), 0)
auN_h=(-uCn, (uDy-0.5*uCn), 0)
auS_h=(uCs, (uDy+0.5*uCs), 0)
auE(i,j)=MAX(auE_h)
auW(i,j)=MAX(uCw, (uDx+0.5*uCw), 0)
auN(i,j)=MAX(-uCn, (uDy-0.5*uCn), 0)
auS(i,j)=MAX(uCs, (uDy+0.5*uCs), 0)
!Central coeff & under relaxation 
auP(i,j)=(auE(i,j)+auW(i,j)+auN(i,j)+auS(i,j))/alpha_u
!Velocity component for PCE
dU(i,j)=FLOAT(dy)/auP(i,j)
END
END
!Use uold for calculate ustar
ustar=uold
DO iter=maxNMiter
DO i=2, NX
DO j=2, NY+1
ustar(i,j)=(auE(i,j)*ustar(i+1,j)+auW(i,j)*ustar(i-1,j)+auN(i,j)*ustar(i,j+1)+auS(i,j)*ustar(i,j-1)-FLOAT(dy)*(pstar(i+1,j)-pstar(i,j))+(1-alpha_u)*auP(i,j)*uold(i,j))/auP(i,j)
END
END
END
! ustar FOR X-MOMENTUM HAS BEEN SOLVE
!!!!!!!!!! STEP 1B BEGIN
! Solve y-momentum as vstar
DO i=2, NX+1
DO j=2, NY
! Convective flux terms use CENTRAL DIFFERENCE
vCe=dy*0.5*(uold(i,j)+uold(i,j+1))
vCw=dy*0.5*(uold(i-1,j)+uold(i-1,j+1))
vCn=dx*0.5*(vold(i,j)+vold(i,j+1))
vCs=dx*0.5*(vold(i,j)+vold(i,j-1))
! Calculation for rate of strain tensor
dvdy=(0.5*(vold(i,j)+vold(i,j+1)))/dy
dvdy=(0.5*(vold(i,j)+vold(i+1,j)))/dx
nutv=(Cs*FLOAT(dx))**2*((0.5*(dvdx+dvdy)**2)**0.5)*(dvdx+dvdy)
! Diffusive flux term
vDx=(FLOAT(dy)/FLOAT(dx))*((1/Re)+nutv) 
vDy=(FLOAT(dx)/FLOAT(dy))*((1/Re)+nutv)
! ASSEMBLY COEFFICIENT FROM HYBRID SCHEME
avE_h=(-vCe, (vDx-0.5*vCe), 0)
avW_h=(vCw, (vDx+0.5*vCw), 0)
avN_h=(-vCn, (vDy-0.5*vCn), 0)
avS_h=(vCs, (vDy+0.5*vCs), 0)
avE(i,j)=MAX(avE_h)
avW(i,j)=MAX(avW_h)
avN(i,j)=MAX(avN_h)
avS(i,j)=MAX(avS_h)
!Central coeff & under relaxation 
avP(i,j)=(avE(i,j)+avW(i,j)+avN(i,j)+avS(i,j))/alpha_u
!Velocity component for PCE
dV(i,j)=FLOAT(dx)/avP(i,j)
END
END
! Calculate vstar
vstar=vold
DO iter=maxNMiter
DO i=2, NX+1
DO j=2, NY
vstar(i,j)=(avE(i,j)*vstar(i+1,j)+avW(i,j)*vstar(i-1,j)+avN(i,j)*vstar(i,j+1)+avS(i,j)*vstar(i,j-1)-FLOAT(dy)*(pstar(i+1,j)-pstar(i,j))+(1-alpha_u)*avP(i,j)*vold(i,j))/avP(i,j)
END
END
END
! vstar has been calculated, move to next step

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!! STEP 2 CALCULATE PRESSURE CORRECTION

DO i=2, NX+1
DO j=2, NY+1
! Boundary coefficient
apE(i,j) = dU(i,j)*dy
apW(i,j) = dU(i-1,j)*dy
apN(i,j) = dV(i,j)*dx
apS(i,j) = dV(i,j-1)*dx
! Central coefficient
apP(i,j) = apE(i,j)+apW(i,j)+apN(i,j)+apS(i,j)
! RHS value
bpP(i,j)= (ustar(i-1,j)-ustar(i,j))*dy+(vstar(i,j-1)-vstar(i,j))*dx
END
END
!! APPLY BOUNDARY CONDITION FOR PRESSURE
IF (n==1 .AND. i=2 .AND. j=2) THEN
apP(i,j)=1.0
apE(i,j)=0
apW(i,j)=0
apN(i,j)=0
apS(i,j)=0
bpP(i,j)=0
END
!!Calculate pprime
pprime(:,:)=0
DO iter=maxNMiter
DO i=2, NX+1
DO j=2, NY+1
pprime(i,j)=
pprime(i,j)=(apE(i,j)*pprime(i+1,j)+apW(i,j)*pprime(i-1,j)+apN(i,j)*pprime(i,j+1)+apS(i,j)*pprime(i,j-1)+bpP(i,j)/apP(i,j)
END
END
END
!!!!!!!!!! pprime has been calculated move to next section
!!!!!!!!!! STEP 3 CALCULATE VELOCITY CORRECTION
!! u-velocity correction
DO i=2, NX
DO j=2, NY+1
uprime(i,j)=dU(i,j)*(pprime(i,j)-pprime(i+1,j))
END
END
!! v-velocity correction 
DO i=2, NX+1
DO j=2, NY
vprime(i,j)=dV(i,j)*(pprime(i,j)-pprime(i,j+1))
END
END
!!!!!! STEP 3 FINISH MOVE TO STEP 4


!!!!!! STEP 4 CALCULATE REAL u,v, and p
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! CALCULATE REAL u
Do i=2, NX
Do j=2, NY+1
u(i,j)=ustar(i,j)+uprime(i,j)
END
END
!! CALCULATE REAL v
Do i=2, NX+1
Do j=2, NY
v(i,j)=vstar(i,j)+vprime(i,j)
END
END
!! CALCULATE REAL p
Do i=2, NX+1
Do j=2, NY+1
p(i,j)=pstar(i,j)+pprime(i,j)*alpha_p
END
END
!!!!!!! STEP 4 FINISH !!!!!!!!!!

!!!!!!! STEP 5 ITERATION UNTIL CONVERGENCE
!!!!!!! 
ux=u(1:NX+1, 1:NY+1)
uxold=uold(1:NX+1, 1:NY+1)
vx=v(1:NX+1, 1:NY+1)
vxold=vold(1:NX+1, 1:NY+1)
cmax1=MAX(MAX(ux-uxold))
cmax2=MAX(MAX(vx-vxold))
convergence=MAX(cmax1, cmax2)
IF convergence<err THEN
STOP
ELSE 
uold=u
vold=v
pstar=p
!!!!!!!! CONVERGENCE CRITERIA IS SET
!!!!!!!! STEP 6 PROBLEM SET UP 

!!!!!! APPLY INLET VELOCITY FUNCTION
DO j=NY+1, 2, -1
Y(1,j)=(1, H:-dy:0)
IF Y(1,j)<Ho THEN
uLeft(1,j)=4*umax*(Y(i,j)/Ho)*(1-(Y(1,j)/Ho))
vLeft(1,j)=0
ELSE IF Y(1,j)>Ho THEN
uLeft(1,j)=0
vLeft(1,j)=0
END
END
!!!!!! APPLY BOUNDARY CONDITION FOR VELOCITY
uold(:,1)=0.0 !bottom bound
vold(:,1)=0.0
uOld(:,Ny+2) = 0.0 
vOld(:,Ny+1) = 0.0
uOld(1,:) = uLeft(1,:)
vOld(:,1) = vLeft(:,1)
uOld(Nx+1,:) = uOld(Nx,:)
vOld(Nx+2,:) = vOld(Nx+1,:)
END
END
END
END
END PROGRAM BACKWARD
  1.  

Module variable is shown to be undefined in the "watch" window

$
0
0

Hello,

I'm using the intel parallel studio (XE2018 update 1 cluster edition).

I found that a variable globally defined in a module is shown as undefined variable in the "watch" window, as depicted below, even though the module is declared as "USE" in the subroutine.

I attached a sample code illustrating this issue.

If I use this variable in the subroutine, then the "watch" window shows the variable properly. But, if it is not used explicitly, it is declared as undefined variable.

In my opinion, even though the variable ("m_tot" in the attached code) is not explicitly used in the subroutine, it needs to be a defined variable since the subroutine use the module where the variable is defined.

I hope to get some comments on this.

Thanks.

Below is the sample code.

===========================================================

      MODULE test_module
     
      DOUBLE PRECISION M_TOT
   
      END MODULE

      PROGRAM Module_test
     
      USE test_module
     
      INTEGER a,b,c
     
      a=10
      b=11
      c = a + b  
               
      continue
             
      END

 

 

AttachmentSize
Downloadapplication/zipModule_test.zip140.76 KB

Integration with VB.net and loss of Double Precision

$
0
0

The problem in short: My VB.net application will only maintain double precision calculations if it first calls an old DLL file that was compiled on the old DEC/Compact Fortran compiler (predecessor of Intel Fortran).

Details: I maintain a large engineering application (model building, FEM analysis, etc.) that was originally developed in Visual Studio VB.net 2003. It relies on several DLLs for critical calculations that were developed originally with DEC/Compact Visual Fortran compiler back in about 2005. We have since migrated the main application to Visual Studio 2013 and 2017, and have recompiled the Fortran DLLs with the Intel Fortran which is integrated into Visual Studio.

All variables that are involved in the critical calculations in both the VB code and the Fortran are declared as Double Precision. (The double precision is absolutely required) If the main VB application calls one of the old DLL files that was compiled years ago with the Compact Visual Fortran then everything works fine, all calculations are done to double precision accuracy, both in the VB part and in the Fortran DLLs. If instead the application calls a DLL that was compiled with the current Intel Fortran compiler, the entire application loses its ability to do proper double precision math, including calculations that are done in the main VB application.

I have tested all of the newly compiled DLLs using small VB test applications to simulate how the DLLs are called from the real application. The DLLs pass all of our tests. When called from the small VB test programs, they return the proper double precision results so it appears that there is nothing inherently wrong with the DLLs.

I believe the Microsoft Visual Studio and/or NetFramework might be causing the problem. It appears as though Visual Studio is making its own decision when to maintain double precision results and when to throw them away.

Again, the bazar thing is that all it takes is call with dummy arguments to one of the old DLLs and then everything is maintained in double precision, even back in VB code. It is as if there was a setting used in the old Fortran compiler that forced everything to stay correct. Maybe stopping the VS/VB parts from changing data types, or stopping some optimization process.

Any ideas would be greatly appreciated !

error #6404: This name does not have a type, and must have an explicit type. [MATOPEN]

$
0
0

Hi all,

I am trying to use matOpen to open and read .mat file but I got this error. Anyone can help me? Here is my code:

 

    program reading
    implicit none
    integer i,j,mp
    real(8), allocatable :: b(:,:)
    character(40) :: text
    
    mp=matOpen('motion_1.mat','r')
    
    open(unit=10, file="D:\fortranmatlab\readmatfile\readmatfile\motion.txt.")
    
    do i=1,108001
        do j=1,6
            write(10,*) b(i,j)
        end do
    end do
        
    end program reading

String match for specific subroutines or functions

$
0
0

I am using Visual Studio 2015 with Intel Fortran 2016. I would like to be able to search for specific strings within  a specific subroutine or function. Is there a Ctrl+F type functionality which can allow me to do something like this? Thanks

Viewing all 5691 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>