Second, write a very basic routine in a DLL that you then call from VBA.īetween the two, hopefully helps determine if the issue is with the routine itself, or with the DLL call. This should check if the routine is ported correctly from 32 to 64-bits. I’d probably attack this from two directions.įirst write a Fortran and/or C driver to call your routine directly and then from the DLL.
Hard to tell though going form 32-bits to 64-bits in Fortran usually wasn’t a problem. I am not sure what information I should forward, to enable anybody to suggest a way forward. However, when I re-calculate the model the program goes in what it looks like an endless loop… I mean such programming mistakes can always happen, but the model calculates ok under x32… Ok, so I was probably correct that VBA just couldn’t find the dependent runtime libs.
I did as you advised … By copying the Redist DLLs to my project directory the problem goes away (for a moment) so VBA now finds the project DLL. Though I high doubt this would be an issue for your program. My memory may be off here, but I thought Intel bought CVF back in the early 2000s and then turned it into Intel Visual Fortran, so it would make sense for them to have such a flag. The trouble is that PGI does not have the “cvf” option. It sounds logical, but it didn’t work.ĭoubt it would since you can’t dynamically open a static library so VBA wouldn’t be able to open it. I found the advice to compile using -Bstatic instead of -Bdynamic. Though it could mean the dependent libraries as well. Hmm, if the post is correct, then this means it can’t open the proj1.dll. I did not add any compiler directives to the Fortran code other than the DLLEXPORT (the same as I was doing before):Ĭan anybody please help me solve this problem? There are no compiler or link errors the compiler produces the DLL. Pgfortran -Mmakedll file1.obj file2.obj file3.obj file4.obj file5.obj file6.obj -o proj1.dll I hardwired the path of the DLL in the VBA code, so it should find it. When running the program in the new 64 bit Excel I get the message “file not found – proj1.dll“. proj1.dll) and the VBA code does not work anymore. Since I did this, the interface between the DLL (e.g. Still, also for this problem, the method I described above works well, just too slow.Īfter some reading, I decided to move my project to a more powerful computer (an 8 core Xeon with Nvidia GPU) with Win64 and the PGI Fortran compiler. Recently I have been implementing a rather complex model, so the runtimes on a single processor on my normal Win32 machine became too long. All this worked (and still works) pretty well. Since many years I have been writing Fortran 90 code, compiling it using Fortran Powerstation 4.0 (this is a very old 32 bit compiler), producing DLLs and accessing them from Excel using a VBA i/o interface. I program out of necessity to implement scientific algorithms for subsurface fluid flow (oil industry).
0 kommentar(er)
