I am running an Abaqus 6.14 simulation using the user subroutine VUAMP.f and I get the "Unexpected LoadLibraryA error 193".
I am using Abaqus 6.14-2, Intel Parallel Studio XE 2013 SP1 and Visual Studio 2012.
I have been running this same model for a while and I had no problems. Now I am changing few things in the geometries of the model and I got this error. When I try running the model without the user subroutine it runs fine, so it's not a problem with the geometry. However I did not make any change to the VUAMP.f file. What is even stranger is that trying to debug the problem I started commenting out the parts of the model in the Abaqus input file that interface with the user subroutine (e.g. user defined amplitude cards, sensor outputs) and the model suddenly worked. Then I uncommented these lines one by one and after few attempts the model ran (the same model that did not run the first time I tried!). However as soon as I change any parameter or geometry the simulations gives me the same error again.
This same model with the same user subroutine works with Abaqus 6.11-3, Intel Composer 2011, Visual Studio 2008.
I also tried in three different machines, but I get the same error. I tried to uninstall Intel Composer and reinstall it but it did not fix the issue.
In summary, it is a problem related to the interface between Abaqus and Intel Composer, but it happens only sometimes. The problem is not in the syntax of the .f file, and it is not in the Abaqus model (even though it is somehow influenced by it).
Can anyone help?
193 is "Bad EXE format". My guess is that you're trying to load a 64-bit DLL in a 32-bit app, or the other way around. It is not an interface issue - it's a problem in your build environment or possibly a wrong file being specified in ABAQUS for loading.
thanks for your quick response (again!). I also tried with Abaqus 6.13 and the same versions of Intel Composer and Visual Studio, and it works. So it must be something Abaqus-specific and only for Abaqus 6.14. However, the error happens only when I use a user subroutine (only when Intel Composer is involved!). Like you are saying, it must be something in my build environment.
Do you have any suggestion on how to tackle the problem?
How do you run the Abaqus job with the user subroutine? Not sure if this will help, but I have had success running Abaqus with user subroutines by opening the Intel Fortran console first, and then run the Abaqus job from there. That way all the Intel Fortran variables are initialized in that console window for Abaqus to use. I open the Intel Fortran console from the Start menu as:
Start -> Intel Parallel Studio XE 2017- > Compiler 17.0 for Intel 64 Visual Studio 2015 environment
(Make changes for your installed versions). This may help to be certain that the 64-bit build is getting used by Abaqus to avoid mixing 32 and 64 files, as Steve mentioned.
You mentioned several combinations you have tried in testing, and do you also have a main program to run the user subroutine outside of Abaqus? That approach has been useful for me to confirm that I can call the user subroutine many times from a "main" program (not Abaqus) with a range of data and get expected return values. That would at least allow you to confirm the user subroutine is working in 64-bit so that you can focus on any issues connecting it to Abaqus.
If it helps for debugging, you can write information to specified Fortran file unit numbers from the user subroutine to get information in the output file. Unit 7 writes to the *.msg message file. Refer to the "Abaqus Analysis User's Guide", section 3.7.1 "Fortran unit number used by Abaqus". Perhaps writing intermediate values to the *.msg file when running from Abaqus may show if values are being corrupted.
dear Alessandro, I met the same trouble when using umat. My model can be calculated for the first time, when I changed something in the inp, the error 193 was happend.
how did you solved the problem?