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.