Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Fortran module checking


I'm a serious newbie to Fortran and am asking this because I'm being forced
to help debug another unwilling person's code.  Forgive the lack of
understanding.

The code that I'm interested in uses modules to retrieve variable names for
the main code.  Essentially there is a variable.f containing all the code
variables which is turned into a .mod file - that is then called by main.f
with a USE statement.

It would appear through my debugger (idebug) that attempts to call code in
that .mod file are returning segmentation faults.  But I can't prove that
and the developer is balking.  So I'm looking for ways to demonstrate that
the contents of the .mod file are being included in the finished product and
available to the executable - that the syntax is proper.  He's a developer
and believes my system is in error, I'm a Sys Ad and believe his code is in
error so I'm trying to establish the validity of my position by
demonstrating that either I'm right or wrong.

Is it as simple as (mind you I'm using xlf90)
! variable.f psuedocode
variable1 = tag1, tag2

xlf90 variable.f -o variable.mod (I'm paraphrasing here)

! main.f psuedocode
use tag1="Hello"
use tag2="Hi"

xlf90 main.f -o program.exe

Or are there compile options that should be invoked to ensure that USE
statements get included into the main code?

On Jun 6, 7:18 pm, "Eigenvector" <m44_mas@yahoo.com> wrote:

One does NOT compile .mod files -- they are produced automatically by
a compiler when compiles a source file containing a MODULE. I'll let
someone else answer in more detail.

Probably to evaluate the code syntax it would be best to post a
reasonable amount of the code itself so it can be looked at directly. As
several other concurrent and recent threads have shown, trying to
paraphrase rather than showing exact symptoms/code is almost futile.

A minimal module and program using that module would look something like

Module my_mod
   implicit none
   integer :: i
   real :: x
end module

program use_module
   implicit none
   use my_mod

   i = 1
   x = 123.45

   write(*,*) i, x
end program

I don't know the xlf compiler so can't help much on it, but one needs
then to compile the file containing the module and have it's output (the
  .mod file although the use of .mod isn't standard but a common choice,
xlf may use something else) wherever the compiler expects to find it --
typically the same location as the source of the code which expects to
USE it.

Then, compile and link the main program that USE's the module.

HTH...

--

In addition to the comments of Beliavsky and dpb, note
that compiling a source file containing a MODULE produces
*both* a module output file (typically .mod) *and* an
object file (.o or .obj, etc.).

Compiling a source file that USEs a module requires the
.mod file be present/accessible.  Linking the program
requires the .o/.obj files from all USEing files *plus*
all USEd modules.

Finally, and to reinforce the comments of the others,
*none* of what you've shown is Fortran so it's basically
impossible to diagnose the error(s).  Please post the
actual source code involved, or at the very least, the
declarations in the module, and the USE statements and
references to the module variables and/or routines in
the main program...exact cut'n'paste please, no paraphrasing...

     -Ken
--
Ken & Ann Fairfield
What:  Ken dot And dot Ann
Where: Gmail dot Com

"Ken Fairfield" <K@Napili.Fairfield.Home> wrote in message

news:5cp9coF30kecaU1@mid.individual.net...

Well I don't have web access from this system so I thought I'd toss out
something and see if anyone bit.  Assuming we don't figure this out
tommorrow I'll post up what I can from the hardcopy.

I'm not an expert, but this doesn't look anything like the way I've seen
modules used.  First, show the code that defines the module.  It should
be something like:

module foo
  integer :: x,y
  character(10) :: a,b
end module

In the places where the module foo is used you should just have:

use foo

then the variables x,y,a,b are made available.

Eigenvector <m44_mas@yahoo.com> wrote:
> So I'm looking for ways to demonstrate that
> the contents of the .mod file are being included in the finished product and
> available to the executable - that the syntax is proper.

...

> xlf90 variable.f -o variable.mod (I'm paraphrasing here)

Let me add to what others have said that if one does make the mistake of
confusing the .mod file with an object file (which is what it sounds
like you and/or the developer might be doing), it won't work well at
all. The .mod file does not contain executable code and should *NOT* get
loaded into the executable. If you manage to force it to get loaded
somehow... well... I'm not even sure that is close enough to sensible to
even be possible, but it sure wouldn't work out well. And if you try to
put the object code into the .mod file, as the above "paraphrased"
command appears to be trying to do, that won't work very well either. If
the developer did happen to try to do either of these things, then
that's probably his problem.

I have seen people do things like that. Or a similar variant is for
someone to name the module source file .mod, thinking that is an
extension for module source code instead of for teh compiler output.

Compiling a module produces 2 output files:

1. A .mod file, which is used in compilation of code that USEs the
module. This is used during compilation only. It is not loadable.

2. An ordinary object file, which is loaded just like any other (or is
not loaded if you fail to specify it, again just like any other object
file).

All of this assumes the most common implementation scheme for module
files. I think I recall that xlf uses that scheme, but it has been a
while, so I could misrecall. The scheme is not 100% universal, though it
is common enough of a defacto standard that some vendors who originally
used other schemes have switched to it.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

> Is it as simple as (mind you I'm using xlf90)
> ! variable.f psuedocode
> variable1 = tag1, tag2

> xlf90 variable.f -o variable.mod (I'm paraphrasing here)

> ! main.f psuedocode
> use tag1="Hello"
> use tag2="Hi"

> xlf90 main.f -o program.exe

I am not sure if I understood it correctly, but here are some
comments:
1) the usage of 'use' in main.f seems incorrect. One does not use
variables, but modules. Suppose that module my_variables contains the
variable var1, then by having the line 'use my_variables' in main.f,
the whole module, and therefore its variables, are known in main.f
see also, the post by dpb for an example of how to employ modules

2) others have pointed out that you shouldn't use the .mod file as
an .o file already. If variable.f is the file with the module and
main.f contains the program, you could compile this as:

xlf90 variable.f main.f -o program.exe

a variable.mod will be generated, and off course program.exe

you might want to generate separate object files. then you should
proceed along the lines of:

xlf90 -c variable.f -o variable.o

xlf90 variable.o main.f -o program.exe

now you will have a variable.mod, variable.o, and a program.exe

hope this helps.

arno

ps. i do not have any experience with xlf90, so i hope that i guessed
right with the flags -c and -o

Something I haven't seen in the other posts.  If your main
program compiles, it is getting access to the module.  The USE
statement will generate a compile time error if it can't find
whatever it wants or needs.  Debuggers often have trouble
finding or understanding Fortran module variables.  Can you
try a simple PRINT statement in the main program?

Dick Hendrickson

"Dick Hendrickson" <dick.hendrick@att.net> wrote in message

news:5vW9i.120704$p47.77092@bgtnsc04-news.ops.worldnet.att.net...

I honestly couldn't figure this one out.

The code was a mess, 15 years and as many owners maintaining it.

It started working, but damned it we could figure out why.

In a nutshell the code was something akin to this

main.f
I'm sure there's some syntax wrong here, as I said I can code C but simply
don't know Fortran and I'm having to do this from memory

program Main
use Variables
call assign_values
write(6,*) Value
contains
!
subroutine assign_values
use Variables !why does this need to be called again?  It's in the main
statement.
Value='value 1'
end subroutine assign_values
!
end program Main

modules.f
module Variables
character (16) : Value
end module

The code would enter the subroutine assign_values, and immediately
segmentation fault when Value was assigned.  In some cases it would
segmentation fault when `use Variables` was called - it didn't even enter
the assignment portion of the subroutine.  The part that pissed us off even
more was that it wasn't ALL modules, but only certain ones.  And then... it
just started working again, we moved all the code, executables, modules, and
input files into the same directory and it worked perfectly - like nothing
had ever been wrong.  I'm still kind of wondering if this was a compiler
flag or Makefile issue rather than anything wrong with the Fortran.

Eigenvector wrote:
> ...
> I honestly couldn't figure this one out...

The USE statement is NOT the same as 'include' (which performs a simple
textual insertion.)  Modules must be compiled *prior* to compiling the
program units that actually USE them.

> ...  I'm still kind of wondering if this was a compiler
> flag or Makefile issue rather than anything wrong with the Fortran.

Clearly, there was a missing dependency in the makefile.  It should
look something like:

main:   main.o modules.o
        $(F90) -o main main.o modules.o

main.o: main.f modules.o
        $(F90) -c main.f

modules.o:      modules.f
        $(F90) -c modules.f

W.

Eigenvector <m44_mas@yahoo.com> wrote:
> don't know Fortran and I'm having to do this from memory

That's not likely to be very helpful for debugging then. Hard to debug
something when we don't actually know what it is. The message is
repeated several times a week (and sometimes multiple times in a day)
here that a person asking for debugging help needs to show the actual
code instead of his imperssion or recollection of it. Pretty much by
definition, if he is asking for help, then he know what the problem is,
which is likely to mean that he doesn't know what the important things
to mention are. It happens a *LOT* that the bug turns out to be in
something that the poster didn't show or mention because he didn't
realize that was important.

> use Variables !why does this need to be called again?  It's in the main
> statement.

One comment. You are consistently talking about "calling" a module.
That's not the right concept. USEing a module is nothing at all like
calling something. All it does is make the identifiers in the module
accessible.

From what you show, the second USE is redundant, but harmless. It could
concievably be there so that the subroutine can be freely moved to other
scopes where the host didn't have the USE. Or perhaps it was moved from
such a scope. Your comment about multiple maintainers makes that seem
quite plausible. Or then, pethaps you've omitted something important.

> The part that pissed us off even
> more was that it wasn't ALL modules, but only certain ones.  And then... it
> just started working again, we moved all the code, executables, modules, and
> input files into the same directory and it worked perfectly - like nothing
> had ever been wrong.  I'm still kind of wondering if this was a compiler
> flag or Makefile issue rather than anything wrong with the Fortran.

I don't think you are likely to be able to get useful help with just
this kind of information. Debugging is likely to require seeing the
exact code - not some imperfectly recalled impression of it. This has
all the signs to me of a problem in something that you didn't think to
mention. What that might be I can't guess. And particularly since you
mention that moving things around changes stuff, exact commands used to
build are probably also relevant.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Eigenvector wrote:

<snip>

> The code would enter the subroutine assign_values, and immediately
> segmentation fault when Value was assigned.  In some cases it would
> segmentation fault when `use Variables` was called - it didn't even enter
> the assignment portion of the subroutine.  The part that pissed us off even
> more was that it wasn't ALL modules, but only certain ones.  And then... it
> just started working again, we moved all the code, executables, modules, and
> input files into the same directory and it worked perfectly - like nothing
> had ever been wrong.  I'm still kind of wondering if this was a compiler
> flag or Makefile issue rather than anything wrong with the Fortran.

An incomplete build, in which some source files that should have been
recompiled weren't, is always a possible source of seg faults and other
problems.  One quick way to test this is to force a clean build,
recompiling everything, and see if the results change.  In fact, if you
haven't done it lately, I would do it now, even if the program is
currently working.

There may be tools out there which automate Makefile generation (and
others here can tell you about them);  if you can find one, it might
save you a lot of trouble, since you can use it to keep your Makefile up
to date as you change files and add or delete modules.  An incomplete
Makefile is worse than none at all;  if you don't have one you trust,
you might be better off just recompiling everything every time.

Louis

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc