For Programmers: Free Programming Magazines  


Home > Archive > Fortran > January 2005 > FORTRAN <--> C#. Am I stuck with File IO?









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author FORTRAN <--> C#. Am I stuck with File IO?
david.larsen@gmail.com

2005-01-12, 8:58 pm

I have a web-based application that I am using to make calls to my
number-crunching FORTRAN routines.

Because the output of the FORTRAN is largely variable-length, I am
writing the output to a file and then reading the file from C#. Yikes
this is relatively slow!

I estimate that my output will be anywhere from 100 to 500,000 bytes.

What kind of methods have you used successfully for this type of
communication?

Any simple examples would be appreciated.

Some background info:
Visual Fortran 8.1
C# with .NET 1.1
running on Windows 2003 Server

Gerald F. Thomas

2005-01-13, 3:58 am


<david.larsen@gmail.com> wrote in message
news:1105575104.382972.325400@f14g2000cwb.googlegroups.com...
> I have a web-based application that I am using to make calls to my
> number-crunching FORTRAN routines.
>
> Because the output of the FORTRAN is largely variable-length, I am
> writing the output to a file and then reading the file from C#. Yikes
> this is relatively slow!
>


Indeed!

One way, and I'll leave it to the mullahs of c.l.f. to expound on
alternatives: create a classic FORTRAN DLL with exports. In C# (aka Db,
:-)), use the System.Runtime.InteropServices namespace then the .NET
P/Invoke facility in conjunction with the DLLImport attribute to grab the
data from (extern) FORTRAN subroutines without ever having to go through an
intervening file, a stratagem which is slow, error prone, insecure,
etcetera, etcetera, etcetera.

> I estimate that my output will be anywhere from 100 to 500,000 bytes.


No sweat!

>
> What kind of methods have you used successfully for this type of
> communication?
>
> Any simple examples would be appreciated.
>


Give it a go, it isn't rocket science, although to some here, they'd have
it so. For Fortran on Windows you're a heads up at
http://softwareforums.intel.com/ids/board?board.id=5

--
You're Welcome,
Gerry T.
______
"Science is the belief in the ignorance of experts." -- Feynman, in The
Pleasure of Finding Things Out.



david.larsen@gmail.com

2005-01-13, 4:01 pm

I have used the described method successfully. The only problem is
that I have only been able to pass parameters of fixed size. So I can
have the following:

SUBROUTINE F77SUB(PARAM1, OUTPUT1)

However, I have only been successful when I've specified the size of
the output. I know this should be simple but it eludes me.

(Appologize for newbie post... couldn't find solution in Intel Forums.
Maybe I don't know the answer when it's staring me in the face.)

glen herrmannsfeldt

2005-01-13, 4:01 pm

david.larsen@gmail.com wrote:
> I have used the described method successfully. The only problem is
> that I have only been able to pass parameters of fixed size. So I can
> have the following:


> SUBROUTINE F77SUB(PARAM1, OUTPUT1)
>
> However, I have only been successful when I've specified the size of
> the output. I know this should be simple but it eludes me.



Calling between different languages can be complicated. One way
is to find the manual describing the calling convention of each
compiler and find a way to make them agree. Newer Fortran
standards require additional information to be passed with
arrays in many cases, and C++ normally doesn't supply it.

-- glen

Carlie J. Coats

2005-01-19, 4:22 pm

david.larsen@gmail.com wrote:
> I have a web-based application that I am using to make calls to my
> number-crunching FORTRAN routines.
>
> Because the output of the FORTRAN is largely variable-length, I am
> writing the output to a file and then reading the file from C#. Yikes
> this is relatively slow!


Treat this as a cooperating process problem and use tools designed
for that -- PVM or MPI?

Then (a) it's a memory-to-memory transfer (b) for which someone else
already has written the interlanguage calling fixup.

Not _exactly_ the kind of thing that you're doing, but we use
the cooperating-process paradigm (even (or especially) across
machines routinely in our environmental modeling...
--

Carlie J. Coats, Jr. carlie.coats@baronams.com
Environmental Modeling Center carlie_coats@ncsu.edu
c/o North Carolina State University MEAS Department
1125 Jordan Hall Campus Box 8208
Raleigh, NC 27695 phone: (919)515-7076 / fax: (919)515-7802
"My opinions are my own, and I've got *lots* of them!"
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2009 codecomments.com