Intel OneAPI 2023.1.0 Classic C++ compiler (version 2021.9.0)

[syfu6]

i need this Intel OneAPI 2023.1.0 Classic C++ compiler (version 2021.9.0) and Intel OneAPI 2023.1.0 Classic FORTRAN compiler (version 2021.9.0) for make a subroutine for ANSYS 2025R1 but unable to get the links or the offline installers so is there any way to get this software's

[Ron_Green · Accepted solution]

read this:
https://community.intel.com/t5/Intel-Fortran-Compiler/Older-Compiler-Download-Information/td-p/1372725/page/2

and do a search for "ANSYS".  you will find you do not need that older compiler version.

[syfu6]

i tried doing that but the classic intel fortran is not been found ansys support the classic version is there any way i get the classic fortran with the new version ifort command is not being recognized 

[syfu6]

@Ron_Green hello do you have any solution to this

[andrew_4619]

The solution lies with ANSYS to not use obsolete products. The more immediate solution is to update the ANSYS scripts to work with IFX. 

[avinashs]

@andrew_4619  In an ideal world, this would be the case and the correct approach. However, I am faced with a similar situation. The same code which compiles, links, and runs without error in IFORT (and gfortran) fails in IFX. Unless I resolve this issue, I am unable to update completely to IFX. Similar problems have been noted by our 3rd party external software provider (not ANSYS) who have therefore also not upgraded to IFX. Note that the code fails at only one point in my case, but that is sufficient to break the integration with the 3rd party software. Moreover, the failing subroutine is merely an initialization routine that assigns values to members of a user-defined variable so there isn't much debugging to do. This was reported in the following thread which remains unsolved.

Re: IFX 2025 results in forrtl: severe (170): Program Exception - stack overflow error - Intel Community

[andrew_4619]

OK @avinashs I had a read of your thread and this current thread is rather different. It seems you compiled and linked ( a dll ? ) using IFX and experiences a run time issue (stack overflow). There are many reasons to get a stack overflow, the stack requirement is dependant on your source code and the choices the compiler makes in implementing it.  You need to debug the problem and modify the code or compile options.  In my experience  user Fortran for FEA are usually quite short and  relatively simple user routines with a set of defined inputs and outputs. You did not share any code, so no one could give ant advise on that.  Did you make a test driver main program to exercise your user Fortran for example without using the solver?  I suggest you post the source to your original thread.  

[avinashs]

@andrew_4619  I agree that the current thread is different. My point is only to indicate the kind of problems that are preventing some of us to migrate completely to IFX (though that is the intention). Unfortunately, the real code for the above thread is business confidential and cannot be shared. I am trying to create a reproducer. However, since it works in IFORT and gfortran without error, it is difficult to identify why it fails in IFX.

[andrew_4619]

 "it is difficult to identify why it fails in IFX."  Difficult  a nebulous concept, something is difficult when you don't know how to fix it and easy when you do. In this case it is hard for us users on the forum to know.  Do you know the location of the stack overflow from the traceback? What are the operations of that code area, for example is it a call or does it operate on array slices. It is possible a code construct causes a stack temporary, and  creating that breaks the stack size. A different compiler might make different choices and not create a temporary. A few lines of code around the problem area might  shed some light on the matter. Making a reproducer might be difficult, by the time you have worked that out you will probably already at that point know how to fix it. 

[Ron_Green]

You could try the "-heap-arrays" option.  and in parallel, try "-g -traceback" for a traceback.  Perhaps the statement causing this is not so sensitive that it can be share.

[avinashs]

@Ron_Green Thanks. I tried the /heap-arrays option with traceback with IFX.

Without the /heap-arrays option, the error message was

Unhandled exception at 0x00007FF7F0DF2947 in MyProgram.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000008B79503000).

With /heap-arrays, the error message in the command window is

forrtl: severe (41): insufficient virtual memory

Image                  PC                                    Routine    Line            Source

MyProgram.exe 00007FF7F0DF2947 Unknown Unknown Unknown
MyProgram.exe 00007FF7F0B61480 A 24 A.f90
MyProgram.exe 00007FF7F0884E7F A.t6022 0 B.f90
MyProgram.exe 00007FF7F08735BD C 419 C.f90
MyProgram.exe 00007FF7F0A278DA MAIN 36 main.f90
MyProgram.exe 00007FF7F0D695AB Unknown Unknown Unknown
MyProgram.exe 00007FF7F0DF2B64 Unknown Unknown Unknown
KERNEL32.DLL 00007FFC18657374 Unknown Unknown Unknown
ntdll.dll 00007FFC1893CC91 Unknown Unknown Unknown

(Program and subroutine names have been changed)

[andrew_4619]

so what happens on line 24 of A.f90 that demands a lot of memory?

[Ron_Green]

I am also curious - can you share the statement in A.f90 line 24? 

[avinashs]

Screenshot below shows the line 24. Simple assignment of a passed character variable job_ to internal variable job that may be subsequently processed. Since this error does not occur with IFORT and the code itself is simple requiring low memory, this is difficult to fathom.

[andrew_4619]

It looks innocuous, I do not see a declaration of job_  in this routine BTW. The problem maybe in the call that passes job_ with the stack being corrupt so in effect it went wrong prior to this line this is just the point it falls over as a result. 

[avinashs]

@andrew_4619 Thanks for the analysis. The variable job_ is simply a character string passed to the subroutine and declared as

character(len = *) :: job_. The question remains why this simple code, first written in 2003, that has worked with CVF, all ifort versions up to the last, and gfortran, fails with IFX. First, there is stack overflow when /heap-arrays are not used (should not happen because the program is low memory). Second, when /heap-arrays is used, the situation above with insufficient virtual memory occurs.

The issue could be some corruption that occurs with IFX and does not with other compilers. It has been reproduced on 3 computers in Windows 10 and 11.

As mentioned initially in this thread, it is these kinds of situations that have prevented us and some of our software suppliers from switching to IFX.

[andrew_4619]

I get what you are saying, I have  an optimiser bug that doesn't happen in debug mode, I have isolated it down to a small loop where things go wrong. If I try to instrument (write intermediate data) the problem does not happen. I had an attempt at a small reproducer but I failed to make it fail. I am sure analysis of the code generated would show optimisation is making a bad assumption etc. For now I have reverted back a level on IFX and it is OK but I will go back and look at it again some time soon.  I am sure if I can make a simple reproducer it will get fixed by Intel.

There is a reasonable possibly there is a code generation bug but I also  know from (bitter) past experience that you can have subtly bad code that works OK for years (luck) and then finds you out one day with a new version. Is job_ the only passed var or is there a long list? Any of them could be causing the problem. I can only keep guessing as we only see a small code fragment.