BuckeyeZ
asked on
Calling a Fortran Program from VB .NET
I have a Fortran code (sample.f90) that opens a dat file and returns a number of things. Most importantly, are two arrays, ARRAY1 (an array of 8 integer values) & ARRAY2 (double-dimensioned array containing a whole lot of data). Sample code:
SUBROUTINE READDATA (ARRAY1, ARRAY2)
INTEGER ARRAY1(8)
REAL ARRAY2(400,1016)
.
.
.
RETURN
END
Running the code in Fortran, returns the proper arrays. To call this from VB .NET I built the sample.f90 code as a .dll (sample.dll) and called it using the following VB code:
Declare Sub READDATA Lib "c:\....\sample.dll" (ByVal ARRAY1() As Integer, ByVal ARRAY2(,) As Single)
Private Sub ...
Dim ARRAY1(8) As Integer
Dim ARRAY2(400,1016) As Single
Call READDATA(ARRAY1, ARRAY2)
End Sub
All values in ARRAY1 come back as they should when displayed in a text box, but ARRAY2 is all messed up. ARRAY2(0,0) has one value that doesn't mean much, but then is repeated along the first row for however many rows were in the array on the Fortran side. For example, if there were 10 rows and 254 columns of data in the array as it existed in Fortran, then in VB .NET it would appear as ARRAY2(0,0) = ARRAY2(0,1) = .. = ARRAY2(0,9) = an unintelligible value depending on how it's declared on the VB side (single/double/integer/etc
I'm almost certain that this is a case of a mis-match between variable types from one language to the other, but is there a way to get VB .NET to understand the REAL variable type from Fortran and thus make the array legible?
SUBROUTINE READDATA (ARRAY1, ARRAY2)
INTEGER ARRAY1(8)
REAL ARRAY2(400,1016)
.
.
.
RETURN
END
Running the code in Fortran, returns the proper arrays. To call this from VB .NET I built the sample.f90 code as a .dll (sample.dll) and called it using the following VB code:
Declare Sub READDATA Lib "c:\....\sample.dll" (ByVal ARRAY1() As Integer, ByVal ARRAY2(,) As Single)
Private Sub ...
Dim ARRAY1(8) As Integer
Dim ARRAY2(400,1016) As Single
Call READDATA(ARRAY1, ARRAY2)
End Sub
All values in ARRAY1 come back as they should when displayed in a text box, but ARRAY2 is all messed up. ARRAY2(0,0) has one value that doesn't mean much, but then is repeated along the first row for however many rows were in the array on the Fortran side. For example, if there were 10 rows and 254 columns of data in the array as it existed in Fortran, then in VB .NET it would appear as ARRAY2(0,0) = ARRAY2(0,1) = .. = ARRAY2(0,9) = an unintelligible value depending on how it's declared on the VB side (single/double/integer/etc
I'm almost certain that this is a case of a mis-match between variable types from one language to the other, but is there a way to get VB .NET to understand the REAL variable type from Fortran and thus make the array legible?
This happens because vb reads entire rows and not separate numbers since vb does not have a format command similar with fortran.
The best way i can think to solve the problem is to alter your fortran code to separate the outputs with commas.
For example if u have a 3x3 array output (fortran side) it should be in the form
1, 2, 3
4, 5, 6
7, 8, 9
The best way i can think to solve the problem is to alter your fortran code to separate the outputs with commas.
For example if u have a 3x3 array output (fortran side) it should be in the form
1, 2, 3
4, 5, 6
7, 8, 9
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the tips, but actually, in the time it took for a response, I figured out most of my problem. When I was compiling the .dll, I didn't have the /convert:vaxd qualifier in the line. Once I did that, I could pass the real numbers (sort of). My other problem had to do with having the indexing reversed. On the Fortran side, if the array was ARRAY2(400,1016), it had to be dimensioned in VB as ARRAY2(1016,400). Once I made this two changes, I started to get somewhere.
Now, the only problem is the accuracy of the values that are passed. If I pass a single value (one that is also contained in the array) from the Fortran side to the VB, I get a very accurate value. But if that value is compared to the same one that was contained in the array, it's way off. Is there a way to overcome this problem?
Now, the only problem is the accuracy of the values that are passed. If I pass a single value (one that is also contained in the array) from the Fortran side to the VB, I get a very accurate value. But if that value is compared to the same one that was contained in the array, it's way off. Is there a way to overcome this problem?
ASKER
Thanks for the tips, but actually, in the time it took for a response, I figured out most of my problem. When I was compiling the .dll, I didn't have the /convert:vaxd qualifier in the line. Once I did that, I could pass the real numbers (sort of). My other problem had to do with having the indexing reversed. On the Fortran side, if the array was ARRAY2(400,1016), it had to be dimensioned in VB as ARRAY2(1016,400). Once I made this two changes, I started to get somewhere.
Now, the only problem is the accuracy of the values that are passed. If I pass a single value (one that is also contained in the array) from the Fortran side to the VB, I get a very accurate value. But if that value is compared to the same one that was contained in the array, it's way off. Is there a way to overcome this problem?
Now, the only problem is the accuracy of the values that are passed. If I pass a single value (one that is also contained in the array) from the Fortran side to the VB, I get a very accurate value. But if that value is compared to the same one that was contained in the array, it's way off. Is there a way to overcome this problem?
BuckeyeZ:
This old question needs to be finalized -- accept an answer, split points, or get a refund. For information on your options, please click here-> http:/help/closing.jsp#1
EXPERTS:
Post your closing recommendations! No comment means you don't care.
This old question needs to be finalized -- accept an answer, split points, or get a refund. For information on your options, please click here-> http:/help/closing.jsp#1
EXPERTS:
Post your closing recommendations! No comment means you don't care.
is like soap.
http://www.xml-rpc.org
see implementations sections