Fortran - Fortran77 & GUI

Author

Fortran77 & GUI

Thambi

2004-05-04, 3:06 pm

Hello all,

I have a set of finite element programs that presently run on unix
machines. The present user interface is through the command line using
C-shell scripts. I want to have a better User interface in the form of
Graphical user interface(GUI). I need suggestions as how to go about
this. I right now have options of using Visual Basic as front end and
keeping the existing fortran 77. But I do not know for sure if I can
interface the existing f77 with VB. Please help me on this.

Kannan
Charlotte, NC

Danguard

2004-05-04, 3:06 pm

In article <6625eddc.0405040949.3d18f5e1@posting.google.com>,
jaythambi@yahoo.com says...

> I need suggestions as how to go about
> this. I right now have options of using Visual Basic as front end and
> keeping the existing fortran 77. But I do not know for sure if I can
> interface the existing f77 with VB. Please help me on this.

Hi,

I don't know about interfacing VB and F77 directly...but:

1) I do know that VB can interface C (using DLLs)
2) F77 can interface C (I'm a Fortran newbie, but I read something about
this)

1) and 2) ==> VB can interface F77, via C :-)

i.e.:

You could develop a C interface for your F77 back-end code, and call the
C interface from VB.

Just my 2 cents :)

Bye
Dan

Arjen Markus

2004-05-12, 9:08 pm

Thambi wrote:
>
>
> The reason being the interactive command line based input is time
> consuming and warrants errorfree input (and hard to change them) and
> the simulation takes more time in the present HP-unix machines which
> are being phased out. But the latest windows machines are extensively
> used in the industry now and we want to incorporate this simulations
> also to run in those machines which have pentium-4 processors. We
> expect to save more time by this. GUI is an advancement in the present
> code.
>
> I have been looking into the Tc/Tk and come up with more question.
> Keep sending suggestions.
>
> Thanks,
> Kannan

Hm, have a look at <http://wiki.tcl.tk/3359>. That should help, I think.

Regards,

Arjen

FCC

2004-05-12, 9:08 pm

Mark Stucky wrote:

>
> I have a simple working example that I can send if you are interested.
>

Hello Mark,

I don't know if Kannan is interested, but I would like to see a working
example of this that I could reproduce in my computer. Can it be used
both in Windows and Linux?

Thanks,

FCC.

Mark Stucky

2004-05-12, 9:08 pm

"FCC" <fcc509@netscape.net> wrote in message
news:c7fj55$8fo$1@defalla.upc.es...
> Mark Stucky wrote:
>
>
> Hello Mark,
>
> I don't know if Kannan is interested, but I would like to see a working
> example of this that I could reproduce in my computer. Can it be used
> both in Windows and Linux?
>
> Thanks,
>
> FCC.

FCC,

I sent you a copy via e-mail. Let me know if you have any problems
or questions.

If anyone else is interested, just let me know and I can e-mail you
a copy or post them here (60 lines of Fortran code and 207 lines of
Tcl)

--Mark

Thambi

2004-05-12, 9:09 pm

>
> FCC,
>
> I sent you a copy via e-mail. Let me know if you have any problems
> or questions.
>
> If anyone else is interested, just let me know and I can e-mail you
> a copy or post them here (60 lines of Fortran code and 207 lines of
> Tcl)
>
> --Mark

Mark,

I do need a copy of it. Can you send me one to my email
(jaythambi@yahoo.com)or post it in the group?

Thanks,

Kannan

Kevin G. Rhoads

2004-05-12, 9:09 pm

>The reason being the interactive command line based input is time
>consuming and warrants errorfree input (and hard to change them)

I have run into this issue numerous times. My preferred solution,
which may not be the best for you, is to make interactive command
line input the fall-back which the program attempts if a file of
input data is not specified. By moving input off to a file, there
are several advantages:
1) by use of various OPENs in conditionals, the input unit can be
bound to either the console window or to the file -- no changes
are needed to existing READ statements, provided they already specify
a unit and only trivial changes are needed to add this if they don't,
meanwhile -- the file contains the responses the user would have supplied
interactively
2) this is easy to test using command-line redirection with NO
code changes on many platforms
3) input errors are reduced since the file can be editted in advance
and new, modified runs can be made by copying an input file and
modifying it
4) with a trivial extension, the program can be made to take multiple
command files and do each run in order
5) the existing interactive input is preserved as an option, which may
be an advantage in some situations

Putting a GUI front-end on what is essentially a batch number crunch
program is, to my taste, not a good approach.

YMMV
Kevin

Kevin G. Rhoads

2004-05-12, 9:09 pm

And I should have added

6) it can be done all in Fortran w/o any mixed language stuff

FCC

2004-05-14, 6:31 am

All is well... But, assuming the user makes a mistake in the input file,
he has to run the code first, check the error message that pops up on
the screen (or in the log file), understand it well enough to know how
to correct his mistake.

But this is not all that simple for everyone, including people who are
very familiar with developing similar codes. Imagine an error message
composed of only 5 words: How could you possibly be well informed based
on such small amount of information, particularly when so many input
parameters are interacting (say, for large enough codes which address
many phenomena) ? Even a person who is perfectly literate in say, finite
element codes, can be

with the input file, and also with the
error message he receives, unless the error message is a paragraph
describing all that could possibly be causing it.

A GUI, on the other hand, is incremental, that is, it will analyze the
options selected so far and prevent all the following irrelevant ones
from being selected (by e.g. dimming them), which is sort of ``driving"
the user to the correct input. It can, and should, display important
information regarding the last selected option as well. I think such an
approach will save many users a lot of effort and time.

Besides, there is nothing that prevents a GUI front end from saving all
this information selected by the user to a valid, error-free input file,
in which case all your arguments below will apply as well :) .

Regards,

FCC

Kevin G. Rhoads wrote:

>
>
> I have run into this issue numerous times. My preferred solution,
> which may not be the best for you, is to make interactive command
> line input the fall-back which the program attempts if a file of
> input data is not specified. By moving input off to a file, there
> are several advantages:
> 1) by use of various OPENs in conditionals, the input unit can be
> bound to either the console window or to the file -- no changes
> are needed to existing READ statements, provided they already specify
> a unit and only trivial changes are needed to add this if they don't,
> meanwhile -- the file contains the responses the user would have supplied
> interactively
> 2) this is easy to test using command-line redirection with NO
> code changes on many platforms
> 3) input errors are reduced since the file can be editted in advance
> and new, modified runs can be made by copying an input file and
> modifying it
> 4) with a trivial extension, the program can be made to take multiple
> command files and do each run in order
> 5) the existing interactive input is preserved as an option, which may
> be an advantage in some situations
>
> Putting a GUI front-end on what is essentially a batch number crunch
> program is, to my taste, not a good approach.
>
> YMMV
> Kevin

West Coast Engineering

2004-05-14, 12:31 pm

Hi,

I had a similar problem. Big optical design and ray trace code in
Fortran 77 on a VAX 11/785 circa 1992.

My solution was and is:

Compaq Visual Fortran (I'll move to Intel 8 later in the year) and
Lawson Wakefield's WINTERACTER (www.winteracter.com).

The

thing is that Winteracter is available for both Windows and
LINUX.

One time tool costs are about $1300.00 US and about $295/year for
updates and support for Winteracter.

Winteracter has great documentation and Lawson provides the kind of
user support most of us only dream about.

Good Luck,

Jim Klein
West Coast Engineering
www.westcoastengineering.com

Kevin G. Rhoads

2004-05-17, 11:37 am

>But, assuming the user makes a mistake in the input file,
>he has to run the code first, check the error message that pops up on
>the screen (or in the log file), understand it well enough to know how
>to correct his mistake.
>
>But this is not all that simple for everyone, including people who are
>very familiar with developing similar codes.

This depends upon the degree of input-checking in the Fortran and
the personalities and experiences of the users. As I said in
my post, this works for me, but may not be suited to your case.

I am not trying to convince you to do it some way that you think is
unsuited to the task. I was just offerring an alternative that may
or may not be suitable.

>A GUI, on the other hand, is incremental, that is, it will analyze the
>options selected so far and prevent all the following irrelevant ones
>from being selected (by e.g. dimming them)

1) this can be done with a CUI or a GUI
2) it is often done "wrong": things that should be dimmed aren't, and
things that shouldn't be dimmed are -- just like CUI interfaces can be
done wrong -- it takes a LOT of thought and effort to get input checking
right, and that is not any easier if the input format is GUI or CUI or
voice activated or whatever

>Besides, there is nothing that prevents a GUI front end from saving all
>this information selected by the user to a valid, error-free input file,

This is a very good point, and one that may be better suited to your
specific case here.

In any case, good luck with your project whatever you choose to do.

Sincerely
Kevin

Thambi

2004-05-18, 11:32 am

Hi Jim Klein,

I was thinking about winteracter but I found that for using it we need
to convert the fortran-77 to fortran-90. Converting this big code with
lot of subroutines is a time consuming process for me at this time
though that is possible. The conversion softwares from fortran- 77 to
fortran-90 are all buggy. How did you come up with it?

Thanks,

Kannan

> Hi,
>
> I had a similar problem. Big optical design and ray trace code in
> Fortran 77 on a VAX 11/785 circa 1992.
>
> My solution was and is:
>
> Compaq Visual Fortran (I'll move to Intel 8 later in the year) and
> Lawson Wakefield's WINTERACTER (www.winteracter.com).
>
> The

thing is that Winteracter is available for both Windows and
> LINUX.
>
> One time tool costs are about $1300.00 US and about $295/year for
> updates and support for Winteracter.
>
> Winteracter has great documentation and Lawson provides the kind of
> user support most of us only dream about.
>
> Good Luck,
>
> Jim Klein
> West Coast Engineering
> www.westcoastengineering.com

Helge Avlesen

2004-05-18, 11:32 am

jaythambi@yahoo.com (Thambi) writes:

| Hi Jim Klein,
|
| I was thinking about winteracter but I found that for using it we need
| to convert the fortran-77 to fortran-90. Converting this big code with
| lot of subroutines is a time consuming process for me at this time
| though that is possible. The conversion softwares from fortran- 77 to
| fortran-90 are all buggy. How did you come up with it?

if your code really is conforming Fortran 77 it will/should work with
a Fortran 90 compiler, since Fortran 77 is a subset of Fortran 90.

Helge

beliavsky@aol.com

2004-05-18, 2:32 pm

jaythambi@yahoo.com (Thambi) wrote in message news:<6625eddc.0405180637.1252c681@posting.google.com>...
> Hi Jim Klein,
>
> I was thinking about winteracter but I found that for using it we need
> to convert the fortran-77 to fortran-90. Converting this big code with
> lot of subroutines is a time consuming process for me at this time
> though that is possible. The conversion softwares from fortran- 77 to
> fortran-90 are all buggy. How did you come up with it?
>
> Thanks,
>
> Kannan

Standard-conforming Fortran 77 code is Fortran 90 code, so by
"convert" I assume you mean move from fixed to free source form. The
convert.f90 program of Michael Metcalf does this and has been around
since at least 1991. If running this program on your F77 code produces
F90 that does not compile, it may indicate that your F77 code is
buggy, or at least non-standard. If you do find cases where
convert.f90 fails to convert legal F77 code, you could post a simple
example here.

Dan Nagle wrote a program "preconvert" that handles some non-standard
F77 code and can be used before convert.f90 -- see
http://users.erols.com/dnagle/download.html . Other programs to
convert fixed to free format have been written Kate Hedstrom
(freeform), Alan Miller (to_f90.f90), and August Miller (EZUP).

Catherine Rees Lay

2004-05-19, 7:32 am

In article <6625eddc.0405180637.1252c681@posting.google.com>, Thambi
<jaythambi@yahoo.com> writes
>Hi Jim Klein,
>
>I was thinking about winteracter but I found that for using it we need
>to convert the fortran-77 to fortran-90. Converting this big code with
>lot of subroutines is a time consuming process for me at this time
>though that is possible. The conversion softwares from fortran- 77 to
>fortran-90 are all buggy. How did you come up with it?
>
>Thanks,
>
>Kannan
>
Kannan,

Fortran 77 is a subset of Fortran 90. You don't need to convert anything
- just use a Fortran 90 compiler set to accept fixed form source code,
and add F90 features as you need them. You don't need that many to use
Winteracter - just to USE the interface module, and a few types.

I've done it for several customers, including my first ever Fortran 90
project. It's really not difficult.

Catherine (I work for Polyhedron as a programmer, we also sell
Winteracter).[color=darkred]
>

--
Catherine Rees Lay
To email me, use my first name in front of the "at".

Thambi

2004-05-24, 4:33 pm

Catherine,

I am finding it hard to compile the f77 codes that I have rightnow
even with compaq's visual fortran, salford's FTN90. The errors are:

1. labels of value zero not allowed
2. unspecified character in the label field. (I have #include in my
program, and I think that it interprets that as a string ... well I do
not know, but I do need to include these files in my program)

For the first error I have no clue. But when I try to label the lines
it does not give out errors. This process will take more time since I
have lot of such codes to work with.

Please suggest.

Kannan

Catherine Rees Lay <spamtrap@polyhedron.org.uk> wrote in message news:<XEYtaXcgbxqAFwYA@spamtram.polyhedron.com>...[color=darkred]
> In article <6625eddc.0405180637.1252c681@posting.google.com>, Thambi
> <jaythambi@yahoo.com> writes
> Kannan,
>
> Fortran 77 is a subset of Fortran 90. You don't need to convert anything
> - just use a Fortran 90 compiler set to accept fixed form source code,
> and add F90 features as you need them. You don't need that many to use
> Winteracter - just to USE the interface module, and a few types.
>
> I've done it for several customers, including my first ever Fortran 90
> project. It's really not difficult.
>
> Catherine (I work for Polyhedron as a programmer, we also sell
> Winteracter).

Richard Maine

2004-05-25, 1:36 am

jaythambi@yahoo.com (Thambi) writes:

> 1. labels of value zero not allowed

Well, that's true, but it seems unlikely to be an accurate diagnosis
of the real problem (unless you actually were trying to use 0 as a
label). I guess I'd need to see the code in question to
understand what exactly is going on. The error message alone isn't enough.

> 2. unspecified character in the label field. (I have #include in my
> program, and I think that it interprets that as a string ... well I do
> not know, but I do need to include these files in my program)

That's not the correct Fortran syntax for include. You can use that
syntax with some preprocessors, and you can often convince Fortran
compilers (or use Make) to run the preprocessors for you. But much
simpler in most cases to just use the Fortran syntax, wich is like

include 'filename'

Note that there is no "#" before the include. ALso note that there
are apostrophes around the filename.

This is technically an f90 fetaure, but most recent f77 compilers
accept the same syntax.

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Sponsored Links