Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
27535 Discussions

Life is really simple, but we insist on making it complicated. Confucius

JohnNichols
Valued Contributor II
1,966 Views

The latest VS I loaded by mistake on a NUC.  I then found that it turns off codelens in the community version.   You cannot use it. 

Codelens for those that use it, is really neat.  

Blast Microsoft.  

I always think this the best place to ask all questions,  like why 42, but putting that aside, I asked a question on the Intel Graphics forum, which I should have known the answer to already, but had forgotten the solution. 

@AlHill answered the question in his usual fashion, I like you use of the flame thrower.  

 

JMN

0 Kudos
38 Replies
JohnNichols
Valued Contributor II
1,311 Views

So while I wait for data collection from the accelerometer, I was having a quick play with DRAIN-3DX.  This is a program from the Powell group at UCB.  I have a copy of the program from the archive at UCB.  

When I create sample program in VS - and then load the main module for program, the first calls are to a series of ____.h modules to load.  I get the following error about not being able to open the *.h files.  

I have not used .h files in Fortran, is there something I need to do to open them?  

 

Screenshot_20221202_031256.png

The note on the install.txt is :

 

You must provide your own compiler and linker. We recommend the Microsoft FORTRAN
Powerstation. The following instructions are for this compiler. Microsoft Powerstation
produces a program which runs in extended memory. A PC with a 386 or 486 processor is
required. Compilation and linking is done under WINDOWS. Execution can be from
WINDOWS or DOS. We recommend DOS.

As an alternative to Powerstation we suggest the Lahey 386 compiler. We no longer
recommend or support versions running under the DOS 640K limit.

jimdempseyatthecove
Black Belt
1,291 Views

Experiment by changing 'double.h' to 'DOUBLE.H' under a wild guess the include files are case sensitive. Windows <= 3.n used FATnn file structure that had Short File Name, and later Short File Name + Long File Name. And the files were case insensitive. Your newer system is likely using NTFS, potentially this could be case sensitive.

If this fixes missing double.h, then upcase the remaining include file names.

 

If that doesn't work:

Looks like an issue with the INCLUDE path. Try explicitly adding the folder containing the .h files to the Additional Include Directories.

 

Jim Dempsey

FortranFan
Honored Contributor II
1,282 Views

To the extent the code uses Fortran language syntax and not a compiler extension of some sort, the casing / naming of the include source should make no difference.

Your second suggestion with the "Additional Include Directories" will likely help OP.

JohnNichols
Valued Contributor II
1,270 Views
JohnNichols
Valued Contributor II
1,266 Views

I hunted the error code, on another site, Steve notes that the incudes have to be in the same directory as the other Fortran.  

That option works,  but it is a kludge. 

jimdempseyatthecove
Black Belt
1,257 Views

>>the casing / naming of the include source should make no difference

This depends on the O/S. The file name is not a Fortran symbol (Fortran symbols are case insensitive).

The 'double.h' is Fortran character literal (text), which is case sensitive.

Jim Dempsey

jimdempseyatthecove
Black Belt
1,260 Views

>>the incudes have to be in the same directory as the other Fortran

You should be able to add an additional INCLUDE directory to provide for the *.h files to be located in a different folder.

Jim Dempsey

JohnNichols
Valued Contributor II
1,232 Views

Jim:

Here is the program.  I have not included anything past the first program and the includes so it does not run. But I cannot see how to use includes without the kludge.  

If you do have to use this kludge, then it is a flaw in IFORT running in VS IMHO. 

John

jimdempseyatthecove
Black Belt
1,210 Views

Using MS VS 2019 (16.10.3), ifort 2020.0.166

The program compiles with no error, but the link fails with:

MAIN.obj : error LNK2019: unresolved external symbol CONTRL referenced in function MAIN__

Unable to locate subroutine contrl

 Could you send the file?

 

I also have oneAPI (on my NUC). Will move it there once it builds on this system.

 

Jim Dempsey

jimdempseyatthecove
Black Belt
1,205 Views
JohnNichols
Valued Contributor II
1,206 Views

All of the modules are located in the source directory. I copied the whole lot into there.  

The problem is I had to copy the includes in with the main *.for programs.  If we take them out, it will not work.  The zip file I sent you has them sunk in the main directory.  

This zip file links in the next level of subroutines, it then runs into the include file problem again.   

I prefer not to end up with 200 or so files in one directory. 

 

JohnNichols
Valued Contributor II
1,202 Views
andrew_4619
Honored Contributor II
1,049 Views

andrew_4619_0-1670337316932.png

I had a look at your project  and added the include path.  It then compiles but as you said the project is not complete so it does not link.

JohnNichols
Valued Contributor II
1,232 Views

Blasted Manuals

The manual says - if you set A to 250 and B to 50  then in the data stream consisting of byte groups - each 14 long, the fifth group of 14 and so on will be a B form etc....

The experimental measurements show that B has a random value from 0 to 300 and some groups without regular ordering contain B data.  The B data can sometimes look like A data.  

B data is time and A data is acceleration.  

 

 

jimdempseyatthecove
Black Belt
1,203 Views

>> if you set A to 250 and B to 50  then in the data stream consisting of byte groups - each 14 long, the fifth group of 14 and so on will be a B form etc....

To me, this potentially infers the first 4 groups of 14 bytes (56 bytes) belong to the set A (value of 250) or some other header info. This doesn't make sense.

OR implies each B consists of five groups of 14 bytes??

Does the manual have a sketch of the data layout?

Jim Dempsey

 

JohnNichols
Valued Contributor II
1,176 Views

Jim:

It turns out to be something like that.  The accelerometer has nominal speeds of 1333 and 1666 Hz, but if I set it to 1666 it tops out at 1450 Hz.   The time register set can put out 52 cycles per second, so if I read the FIFO stream, I get two characters, st followed by 14 bytes of data.  It repeats forever.  The issue is the accelerometer, divides the 1450 by 52 and pumps out approximately one time signal every 27 to 30 accelerometer sets, but there is no way to tell them apart, it is supposed to be a constant distance, but the 1450 is nominal and it has an error of about +- 20 Hz.  So I can see the data at the start as the time is low, but as it moves to FFFFFFFF after 30 hours it looks like acceleration data. 

I can however, send a read request for the time and temperature every 16 seconds, at the end of a FFT cycle and then calibrate the system again.  It does not drift much in 16 seconds.   

It has taken from April to develop the code. The manuals leave a lot to be desired, but I am slowly understanding how they talk.  

Thanks.  

The sample program from the manufacturer sends streams of 32 bytes and the manufacturer's rep says that is impossible, but it is what shows up in the serial monitor.  I am an experimental engineer, I believe the data and not the computer programmers. 

Now I can calibrate the ten in the Smithsonian.  

Thanks again 

JMN

The FIFO stream comes in different lengths and it has crap embedded in it, so it explains the small variations, I have no idea yet why the manufacturer says 1666 and I get 1450.  I have checked it against a vibrating post.  

 

 

jimdempseyatthecove
Black Belt
1,123 Views

John,

 

For your build issues I've attached your archive but with edited .sln and .vfproj

Note, build fails with many issues:

        Cannot open include file 'cshp.com'

This file is not found in any of the archive folders

       This EQUIVALENCE object must be an array. [NODE]

Node likely declared in cshp.com

        The type of the actual argument differs from the type of the dummy argument. [ELFACT]

        The shape matching rules of actual arguments and dummy arguments have been violated. [SETLOD]

        A non-optional actual argument must be present when invoking a procedure with an explicit interface. [NFECHO]

        If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic. [M]

Many such mismatches like these

 

There will be significant amount of cleanup to get the code to compile.

 

Jim Dempsey

 

jimdempseyatthecove
Black Belt
1,121 Views

One particular/hard issue to correct

BLANK.H contains

     common l(1)

iow, implicit integer array "l", size 1

CONTROL.FOR contains calls such as:

            call stifft (l(kndid),l(kcoord),l(kid),l(kidsp),
     1                   l(klstif),l(kbetak),l(ktank),l(kiad),
     2                   l(kinfb),l(kwkspc),nnods,ntnds,ndsp,niad,
     3                   ninfb,nblok,nwkspc,nchar,nelgr,kpdel)

Where L appears to be an array of some size >1.

Note, what follows L in the unnamed COMMON is not listed in BLANK.H, and is (I presume) to be what follows in one of the next include "....H" file's unnamed common.

Jim Dempsey

JohnNichols
Valued Contributor II
1,036 Views

Jim and Andrew:

Thanks. 

I copied the whole lot over to a NUC and then checked the include path and ran it on 32 bit and it compiles.

As you note there is a missing file, I am hunting for it at the moment, and your note on the errors brought a smile to an old face.  It should be fun.  

I am also looking for an input file or I will create one as I got the manuals. 

When I find them I will upload them.  

A couple of engineers had it running in 2010 using Linux and gfortran.  I do not use either.  I am trying to find them, I asked politely at NISEE in California.  

 

 

 

John

 

 

JohnNichols
Valued Contributor II
1,017 Views
c **********************************************************************
      SUBROUTINE IWRITE (m,lm,nf)
c **********************************************************************
c     Write integer array m(lm) on unit nf.
c ----------------------------------------------------------------------
c     ARGUMENT DECLARATIONS
      integer m(lm)
c **********************************************************************
      write (nf) m
c **********************************************************************
      RETURN
      END

I assume this is valid Fortran for Intel.  What would the output look like?

To get Drain running, the old slow way, treat it as a new program and slowly add stuff.  

Reply