library and/or module

[salgerman]

O.k., as I might have mentioned before, I have used F77 for a while and I am yet to start practicing F90 habits. Now, I want to start.

I have read about modules but the book does not include real examples...can I get some help?

Currently (F77), my "libraries" are simply a set of subroutines that I compiled into *.o files and put them into *.a file; then, I place such *.a in my .../lib directory. When I compile my program that use such library, I pass such directory in the -L flag.

The programs that use the library do not need much; if anything, an include file with necessary declarations. The include file is put in .../include and I pass such path with -I flag at compile time.

How is this done in F90?
What does my library file look like?
Is it enclosed in a module? Where I put my variables and subroutines?
How do I compile this module and how do I deploy it into my library directory?
How do I compile the program that uses the library?

Maybe a short example would be shorter than any explanation?

Thanks in advance for all the hints that you might offer.

Germán

 

[salgerman]

I am confused by your final hint.

"textbook recommends putting procedures in modules" ...did I not do that? I am asking honestly, this is not a rhetorical question. I put one subroutine and one function into a module.

"and enter the modules into the routines that use this procedure" what does this mean? is this not what one does with "use flib" inside the procedure that uses it?

Other than that, we have a rather small team with over the cube-wall communication and working with the same versioning system (used to be CVS, moved to git).

Germán

 

[FJacq]

What writes Gummibaer is effectively rather confusing ...

First of all, when you modify and recompile modules, the files *.mod often do not change : they are normally modified only if you have added new public symbols or modified the signature of public routines. In that case, you do not need to recompile files using these modules.

When you work within a team, small or not, then you need to have a robust way to "build" (= compile/link) correctly your software. I participate to the development of scientific codes for a while (about 25 years) and the teams may be quite large, like the codes, for instance 30 people belonging to different companies, sometimes located in different countries and working together using CVS on a code containing about, 500000 instructions of Fortran95 + C => several thousand Fortran routines mainly organized as modules connected together by USE statements.

And yes, I often update my version several times the day and run the build phase each time (and often more because of tests on different platforms with different compiling options). But our build procedure is efficient : a full build from scratch requires about 30mn on my laptop, depending on compiling options, the processor being a intel I5 with two cores. Most of the time, only few files have been modified and the cascade of recompilation is limited => less than 5 mn to update a previous build.

What is executed during the night or the weekend are the systematic test phases (non regression tests) sent on a cluster of Linux machines, some computations needing several hours of CPU...

François Jacq

 

[melmacianalf]

Whenever you modify anything within a module - including the program within the module - and bring it to your library then all the programs using this module become outdated at once and need to be recompiled and relinked. If it is only you who uses the library then this might be okay if you have an IDE that follows up on these things. But if your library might be used by other programmers in your organisation then you need to set up an update scheme that includes that all programmers recompile (!!), relink and if necessary redistribute their progs. If the recompile is postponed someone might find out later, when your edit is long past and forgotten history, that suddenly unexpliccable errors come out by 'I just did recompilé, did not change a thing and the prog now produces garbage.'

First of all, people working with large codes use some version control programs. I use darcs to update F90 codes that have millions of lines.

When I update a module or any part of the code, I only pass the 'update' or 'patches' that contains new lines. Using darcs my colleague can selectively pull the new lines without messing up the full program. Darcs also allow one to 'unrecord' any changes selectively.

I think you may benefit by using some version control systems. Checkout the 5 min video in [URL unfurl="true"]http://darcs.net/[/url]


Gordon Shumway

 

[gummibaer]

Germàn,

That came the wrong way. Of course that is what you have been doing. This sentence was meant as a introductory statement for that was to come. What I meant to express was that though the textbook recommends this practice... (rest of my post now).

Francois,

I checked this out when I started my current project. I did put a subroutine into a module, had all this compiled and added a main program to use this. Whenever I modified anything in the module, symbols or statement in the program, VS did a full compile the main program as well. However, performing the same test now, I find that main does not get recompiled, which corroborates your statement. Very confused now .....

Gordon,

thanks for the link.


Norbert

The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.