How do I fix the "***ERROR: USER SUBROUTINE DISP IS MISSING" during configuration & verification of Intel Fortran (oneAPI) with Abaqus?
Background: Intel have stopped offering parallel studio and have now moved to oneAPI. It seems to be free, but if you were a student or educator, when your old license expires (after a year) you have to move to oneAPI.
Abaqus verification for user subroutines fails with this new platform with the following in the MSG file
***ERROR: USER SUBROUTINE DISP IS MISSING
As the verification files are provided by Abaqus, it shouldn't fail with this error.
Ensure the correct components of Visual studio (2019) or later are installed - only the “Desktop development with C++” needs to be installed.
Install the oneAPI HPC toolkit (the base toolkit is not required). Only the fortran compiler is required (MPI is optional I think for this).
The Intel installer should pick up the visual studio installation. Ensure that your are running the verification from the "Intel oneAPI command prompt for Intel 64 for Visual Studio 2019".
The error of the subroutine not found is caused by an issue with case sensitivity (see comment by u\Ubuntz on reddit thread).
Add the following line to the top of the FORTRAN source file (std_user.for from the verify folder in this case).
!DEC$ ATTRIBUTES ALIAS:"disp"::DISP
For all other subroutines in actual use/development replace disp with the name of your subroutine, e.g., for a umat write
!DEC$ ATTRIBUTES ALIAS:"umat"::UMAT
Related
I have an executable compiled by MSVS2013 on Windows 7 SP1 32 bit with C runtime statically linked and platform toolset "Visual Studio 2013 - Windows XP (v120_xp)"
It runs perfectly on Win7 (see attached screenshot of Dependency Walker profiling).
It fails to run on WinXP:
Here is the profile log:
Starting profile on 12/9/2014 at 2:55:03 AM
Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
Program Executable: c:\temp\OCTOPUS.EXE
Program Arguments:
Starting Directory: C:\Temp\
Search Path: C:\Program Files\ActiveState Komodo Edit 8\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2009b\bin;C:\VisaPoint\sbperl\perl\bin
Options Selected:
Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
Log DllMain calls for process attach and process detach messages.
Log DllMain calls for all other messages, including thread attach and thread detach.
Hook the process to gather more detailed dependency information.
Log LoadLibrary function calls.
Log GetProcAddress function calls.
Log thread information.
Use simple thread numbers instead of actual thread IDs.
Log first chance exceptions.
Log debug output messages.
Use full paths when logging file names.
Log a time stamp with each line of log.
Automatically open and profile child processes.
--------------------------------------------------------------------------------
00:00:00.000: Failure starting the process. %1 is not a valid Win32 application (193).
[1]: http://i.stack.imgur.com/m82n6.png
[2]: http://i.stack.imgur.com/6Yr37.png
Modern versions of Visual Studio, starting with VS2012, use linker settings that marks the executable image compatible with the current generation of Windows. Version 6, started with Vista. XP and Server2003 were in the previous generation, version 5.
You can still build programs that run on XP with VS2013. But you have to make a setting change. Right-click the project, Properties, General. Change the Platform Toolset setting to v120_xp.
There are a few consequences, your program gets built with an old version of the Windows SDK. V7.1, the last one that was still compatible with XP. The C runtime library makes a bunch of operating system calls that are only available in generation 6. It will stumble along without them, affecting relatively minor details related to threading and culture. This is the kind of FUD that ought to remind you that it might not be the best idea to still promise support for such an ancient operating system. Make sure you keep a running version of XP around so you can properly test and repro. And keep in mind that you can't install VS on it anymore so if you do get a support call from an XP user then you tend to get a fairly heavy migraine.
Ok, just forgot to set SUBSYSTEM in Linker options.
Here is a link with explanations:
https://software.intel.com/en-us/articles/linking-applications-using-visual-studio-2012-to-run-on-windows-xp
I'm trying to build a program from its source code with VC 11. When the compiler is about to finish, it raises the error mentioned in title of this post.
As I've read here and in other forums, I tried to both close as many programs as possible and enlarge the size of the swap file in Windows... neither works.
I've read about a parameter called \Zm but I don't understand how to use it.
Can you please help me?
Take a look at this documentation which gives possible solutions:
I also had that problem and found the documentation useful. Main points:
If the compiler also issues errors C1076 and C3859, use the /Zm compiler option to lower the memory allocation limit. More heap space
is available to your application if you lower the remaining memory
allocation.
If the /Zm option is already set, try removing it. Heap space might be
exhausted because the memory allocation limit specified in the option
is too high. The compiler uses a default limit if you remove the /Zm
option.
If you are compiling on a 64-bit platform, use the 64-bit compiler toolset. For information, see How to: Enable a 64-Bit Visual C++
Toolset on the Command Line.
On 32-bit Windows, try using the /3GB boot.ini switch.
Increase the size of the Windows swap-file.
Close other running programs.
Eliminate unnecessary include files.
Eliminate unnecessary global variables, for example, by allocating memory dynamically instead of declaring a large array.
Eliminate unused declarations.
Split the current file into smaller files.
I can't tell much about the /Zm parameter, but I had the same issue (compiler is out of heap space).
What has helped me was the /m:4 (4 for the count of your CPUs) parameter so that you can use multiple CPUs for building.
Hope that helps you as well.
Also, if you are running on x64, be sure that the x64 version of "msbuild.exe" and "cl.exe" is beeing used. I had the issue that even when using e.g. the x64 ms powershell, the compiler would still choose the 32-bit version of msbuild.exe (in task manager "msbuild.exe*32", windows 7)
In addition to the other answers here (and in my case), fatal error C1060: compiler is out of heap space can be caused by a syntax error. The following code (in certain circumstances) can cause this error even with correct compiler options -- for instance if you've previously successfully compiled the same program.
r.push_back(e[1];
instead of
r.push_back(e[1]);
It seems to only cause this error rather than the standard error C2143: syntax error: missing ')' before ';' when r and e are of certain types, but it's worth checking any code you've edited recently if the program previously compiled without errors.
We had similar problem: a relativelly simple program (although, full of templates, using Eigen library) persistently failed to compile on one of the computers. All were using MSVC2013 x64, but only one was unable to compile the program due to C1060 error. We tried different compiler flags, setting/unsetting -Zm, but failed to resolve it without modifying code.
Some pointers were, however, given to us, when we switched from x64/x64 (64bit compiler for 64bit resulting executable) version of the compiler to the x86/x86 (32bit compiler for 32bit resulting executable). The x86 compiler gave us exact locations of the problematic parts of the program - calls to template functions receiving heavy templated objects. We have rewritten those to normal functions (build in different object file) and that solved the problem...
VS: Visual Studio 2015
OS: Windows10
If you are using VS2015 as your IDE, maybe there is another solution:
Go to update the VS2015 "Update3" package and everything will work smoothly.
In my case, a main program would not compile is VS 2022 Community Edition (free). It had many include files. By process of elimination, I managed to compile it once I removed any "volatile" modifiers in declarations that had this modifier.
A very strange bug, to say the least!
I got this error when compiling OnnxRuntime with MS Visual C++ 17 2022.
The solution for this issue was to close all other programs and compile using a single thread (in this case, removing the --parallel argument from the build.bat call).
I was trying to make my program accept input without the user having to press enter, so I tried the following:
mov ah,01h
int 21h
But it just crashes my program over an unhandled exception. This seems to be the way to do it according to much that I have read, so why isn't it working for me?
Now, I am fairly new to this language so I still do not exactly understand the process of how this piece of code works, so I would also appreciate what the logic is behind accepting input by pressing enter and accepting input without the user having to press enter.
MY OS is Windows, by the way.
Your code looks like MS-DOS-era assembly. VS2010 doesn't support generating DOS executables, and modern versions of Windows (the 64-bit kind) don't support running them, either. Looks like you were going by some old book or site, one that was written in late 80'es-early 90's. Back at that time, assembly was way more relevant and marketable as a job skill. Not so much these days, although some assembly knowledge won't hurt.
Decide what do you want to learn. If you want to learn modern assembly (and target Windows), get some recent guidance. The techniques are quite different, and int21h isn't among them :) If you're indeed after DOS-era assembly, set up a DOS virtual machine with DOSBox, and find some old free assembler. Visual Studio 2010 won't help you here. The latest version of Visual C++ that generated 16-bit executables was v1.5x.
Specifically why does your program crash. Int21h was how MS-DOS exposed its applciation program interface (API). Windows doesn't support it for Windows executables - there are other ways of invoking the API. When you assemble with Visual Studio 2010, you end up with a Windows executable, not a DOS one, and there's no option to generate a DOS one. As for the Windows executables, they're not supposed to invoke interrupts at all - that's a crash condition.
You need to obtain a tool set that can generate 16 MS-DOS programs. These should run on DOSBOX, or on a Virtual PC with MS-DOS installed on it. Microsoft included 16 bit tool sets up to Visual C / C++ 1.52, but Visual C / C++ 4.0 and 4.1 also contain the 1.52 16 bit tool set. The older version of the compilers would be named Microsoft C 8.xx or earlier version. I don't know if any the early versions of Visual Studio (2002 or 2003) include the 16 bit tool set.
Use the linker version 5.60 to generate 16-bit DOS applications. You can get this from:
http://download.microsoft.com/download/vc15/Update/1/WIN98/EN-US/Lnk563.exe
Dirk
I use a small in-house cluster (approx. 31 machines) to help complete parallel runs of a numerical groundwater model. After the groundwater model completes, a short post-processor manipulates some data for use by a code that is collecting output from the parallel runs. It used to be that the post-processor, written in fortran and compiled using intel's visual fortran from inside Vis. Studio 2010, was distribute-able, meaning I could place the .exe in amongst the other files that were distributed across the cluster and run on the various machines. Now, however, if I compile the very same fortran using visual studio 2012 with Intel Fortran XE 2013, I get an error on the cluster machines stating, "The program can't start because MSVCRR110.dll is missing from your computer. Try reinstalling the program to fix this probelm."
One of the reasons I like using Fortran is that it used to be self-contained. In other words, if I wrote small programs to do some short pithy task in another language, say R or Python, then I have to either install these programs on all the cluster machines or else "sandbox" the programs in with my distributed files. Forget about trying to use C# or VB etc., because then the cluster machines would need to have .NET framework installed. For the time being I can go back and use VS2010 to compile, but I don't anticipate having this option available to me much longer. Is there another alternative for keeping fortran programs "self-contained" in VS2012? As you can see in the code below, nothing complicated and no reason for it not be a self-contained executable:
program Calc_Seep
implicit none
! Variables
integer reason
real wp,time,ft,fts,fr,fo,fst,fro,loss1,loss2,loss3
character (len=120) line
character*50 txt
character*20 fmt
wp = 9.38 !a needed constant value
!read(*,*) txt
open(5,file='balance.out')
read(5,'(A)') line
do while (.NOT.line.EQ.'')
read(5,'(A)',IOSTAT=Reason) line
if (Reason < 0) exit
end do
read(line,*) time,ft,fts,fr,fo,fst,fro
!acre-ft/mi/yr
loss1 = (ft/time)*0.3048*5280*208*24/(0.3048**3)/43560.17
!ft/day
loss2 = (ft/time)*24/(0.3048**2)/wp
!cfs/mi
loss3 = (ft/time)*24/(0.3048**2)*5280/86400
close(5)
!now write the processed values to a file
open(5,file="Seepage.out")
write(5,'(A)') "acre-ft/mi/yr ft/day cfs/mi"
write(5,100) loss1, loss2, loss3
100 format(3f13.6)
close(5)
end program Calc_Seep
This is simply a change in default project properties for newly created projects. As of Intel Visual Fortran Composer XE 2013 SP1 (compiler version 14), the default is to link against the DLL libraries, matching what MS Visual C++ does. Existing projects are not affected and you can still change the libraries setting (Fortran > Libraries > Runtime Library) to "Multithreaded" from "Multithreaded DLL". If you do that, then it will again link to the static libraries, though there are some libraries provided only in DLL form (OpenMP and coarray support).
I'd like conditional compilation based on whether the compiling machine is running Windows 7 SP1 or not.
We have a workaround for http://support.microsoft.com/kb/2517589 but I don't want to check the code in unless it is guarded by an #ifdef _WIN7_SP1 otherwise the other devs won't be able to compile it on their non win7-sp1 machines.
I've had a bit of a google but couldn't find anything useful.
You don't. Things in the environment of the build machine generally don't pollute compilation like that. (Imagine if that happened and what effects it would cause on reproducibility of builds.)
If you really need to, I'd instead have your build system (make, Visual Studio, whatever) execute a program that checks the current Windows version and fails as necessary (or possibly your build system can determine this already). Based on that, you then could conditionally make own WIN7_SP1 definition via a command-line argument to your compiler.