|
||||||||||||||
|
|
|
||||||||||||
|
||||||||||||||
|
****JavaScript based drop down DHTML menu generated by NavStudio. (OpenCube Inc. - http://www.opencube.com)****
| Search |
|
|
|||||||||||
|
||||||||||||||
|
Fortran Source, Summer 2000 
Volume 16, Issue 2
FEATURES
DEPARTMENTS
LF95 v5.6 Released! Lahey Computer Systems is pleased to announce the release of Lahey/Fujitsu Fortran 95 v5.6 for the Windows operating system. Based on Polyhedron Software’s test suite, version 5.6 offers the best diagnostics of any Fortran 95 language system, improved Fortran 90 performance, and dramatically faster file I/O. “The new version is the *first* compiler to score 100% on our [Polyhedron’s] diagnostic tests – including all of the runtime undefined variable tests, assumed-size array bound violations, non-conforming array assignment and dangling pointer errors. It also shows some significant performance improvements on our Fortran 90 benchmarks.” — John Appleyard, Polyhedron Software New features in 5.6 include:
LF95 now passes 100% of Polyhedron’s diagnostic tests. New diagnostics include the following: – Enhanced runtime and compile--time diagnostics for -CHK option. – Global compile diagnostics with new -CHKGLOBAL option.
Two to four times faster than competing compilers on unformatted sequential and direct files. Faster on formatted sequential too.
Loop optimization is improved when -O1 is specified; FORALL and DOT_PRODUCT statement processing is faster; and evaluation of the exponentiation operator (**) is faster.
Convert big endian and IBM/370 file formats and the corresponding specifier in OPEN and INQUIRE statements.
ALLOCATABLE attributes on array components of structures, dummy arrays, and function results.
Includes checking for uninitialized variables!
Ability to set default target language name-decoration/calling convention for all program units.
Helps avoid name conflicts in porting projects.
Limit is increased from 65,000 to 2,147,483,647 characters.
A library of Fortran-callable procedures that allows you to read data from and write data to databases and spreadsheets.
“Optimized LF95 build,” “Debug LF95 Build,” and “Technical Support Questionnaire.”
LFsplit divides each program unit into separate source files. LFsplit fixes a problem that prevented extremely large source files from compiling successfully. In most cases, splitting a large source file into smaller files improves compile speed.
Automatically guides you through the gathering of appropriate information for formulating technical support inquiries.
From Lahey’s web site (during and after installation).
For more information about LF95 v5.6, please visit www.lahey.com\lf95.htm or contact our sales department at sales@lahey.com.
Maintaining Fortran Programs - 1 by Thomas M. Lahey This is the first in a series of articles on steps you can take to maintain (I resist using the word port) a Fortran program. A side effect: Implementing these changes will serve to familiarize you with some of the more fundamental features of Modern Fortran. As additional articles are written, they will be made available on the Lahey web site, www.lahey.com. There are few Fortran programmers who are not involved in maintaining programs originally written a decade or more ago. This assertion is based on responses made to the Lahey Workshop Questionnaire. If the workshop participants are representative, then, for all practical purposes every Fortran programmer does maintenance. More than forty percent of the average workshop participant’s time is spent maintaining programs, typically on more than one platform. Some of the programs were created using FORTRAN I, but my impression is that most began life as FORTRAN IV,the predecessor to FORTRAN 77. In the past, program maintenance consisted of debugging and enhancing .For decades, our programs ran on a single mainframe and distribution was comparatively limited. Nowadays, thanks to the ubiquitous PC with the Linux, Unix, or Windows operating system plus distribution via the World Wide Web, maintenance places many more demands on the programmer. In addition, the evolution of operating systems, programming languages, chips, and graphics has greatly impacted what needs to be done. Consider the evolution of the operating system. As recently as the early 1990s,Fortran programmers concentrated on FORMAT statements. I/O may have required ten to fifteen percent of a project. Today, thanks to GUIs and graphics, we spend at least one-third of the project coding I/O – this aspect of the project has more than doubled! Next, consider the evolution of the chip. We’ve gone from the 8080 (64K,no floating point)to the 8086 (640K, who would ever need more than that? )plus the 8087 to the Pentium (how much memory do you want?) with floating point included. The chip evolution has had greater impact than the OS on how we should be programming. In comparing the two, chip and OS ,I believe the chip to have been more positive. For instance, what we had to do in the past to make a program fit is no longer a consideration. That is, EQUIVALENCE and overlays need no longer be considerations in making a program “fit ” in available memory. But it is the evolution of the Fortran language and how it impacts program maintenance that is the focus of this series of articles. Assumption: You use an editor that can do global replacements, i.e., the editor can search a directory and any subdirectories to find strings and replace them with other strings. Assumption: You have a Modern Fortran (90 or 95)language system. Suggestion: Save two copies of the program source file(s) with one or more data sets. These steps help ensure that you do not introduce bugs into the program. After you have implemented one of the ideas below ,compile and execute the program. If the program answers are correct, update one of the copies of your saved source. This step reduces the time it will take you to correct any bugs you have introduced. If you wait until the end to recompile, you will have to scratch your head over where you introduced the bug(s). Suggestion: As a starting point,compile your program with the –F90 switch for LF90 or –F95 for LF95.(If you have access to both Lahey language systems consider doing both. LF90 and LF95 source checkers are available at the Lahey website.) Any diagnostics will give you an idea how far the program has strayed from the standard. Consider eliminating as many of these diagnostics as possible, some of which will be redundant with the suggestions below. The projects identified below are listed in order of increasing complexity. Note, however, that these projects are merely suggestions. You know your program best and are responsible for what you decide to do to it.
The following transformations are all global edits, i.e., possibly across more than one source file, possibly in more than one directory.
That's it for the first set of changes. The next article will show how to convert COMMON to a module with some of the pitfalls. Please e-mail any response to this article at tlahe@lahey.com. (Back to Contents) These days, fewer and fewer engineers remember, firsthand, the glory days of the space program, culminating in the historic Apollo moon landing. Fewer still recall just how intimate was the connection between three converging new technologies: Space science, computer science, and Fortran. In the earliest days of the space program, computers were nonexistent, and Fortran was barely so. When I joined NASA in 1959, to say that computing facilities were primitive would be an understatement. Like every new NASA engineer, I was given a standard, government issue, 18" slide rule. The standard "computer" was a 50-pound, mechanical marvel, the Friden calculator. Spreadsheets were something you did by hand, using the Friden; trig functions were something you got from a book of tables; and graphs required drafting instruments, french curves, and a sharp pencil. You could tell a lot about an engineer by the quality of the graphs he drew. Laugh if you like, but it was mostly slide rules, spreadsheets and graphs, not computers, that launched Alan Shephard and John Glenn into space. NASA’s Langley Research center had one (1) computer, a 32k IBM 702. My first dynamic simulation, for a solid-state rocket booster, was written in assembly language, mainly because that’s all we had. As for things like lunar and interplanetary simulations, there were maybe 10 in the entire country. When you consider the challenge of writing a precision simulation in assembly language using, say, 5th-order Adams-Moulton integration, you can appreciate why there weren’t many of them. By 1969, the year of the Moon landing, aerospace companies all over the country had IBM 7094’s, Univac 1108’s, and CDC 6600’s coming out their ears, all busily grinding out solutions of complex trajectory problems, and virtually all written in Fortran. Fueled by the Apollo effort, we had computing power to spare, and dynamic simulations were a dime a dozen. Each of us had an N-body simulation to help solve Apollo trajectories, and many were being used to plan the next step: Mars. Thousands of engineers, worldwide, pored over fan-fold printouts and X-Y plots. As computers evolved, mathematical methods evolved with them. At the beginning of the space program, we used what existed, which were methods developed by astronomers to compute the orbits of comets. They were methods intended to be used by hand, and they often involved decisions concerning precision, signs of results, etc., that required human intelligence to make. They also tended to make heavy use of spherical trig. The methods did not translate well into computer programs. So we developed new methods that depended on vector math, and algebraic rather than trig-based solutions; things the computer was good at. The patched-conic method, the unified two-body theory, the f-g series solutions, Deyst’s method, Lambert’s theorem methods, all were brand-new methods, better suited to computer solutions than manual ones. Practical application of the now-famous Kalman filter came straight out of the Apollo program inspired by the need for efficient midcourse guidance. I think it’s no exaggeration to say that it was computer technology, not money or space science, that helped us land on the Moon. And Fortran was right in the middle of it. What made Fortran so important? It was designed, from the get-go, to help programmers solve math problems. If there was something we had in abundance, it was math problems, and Fortran was the perfect tool to help us solve them quickly AND efficiently. Two features of Fortran were of special significance. One was the subroutine with calling lists. Though the notions of modularity and reusable software were still thirty years away, we knew a good thing when we saw it. We were all building subroutine libraries, and using them to build bigger ones. My very first Fortran "program" was the ubiquitous vector add routine:
SUBROUTINE ADDV(A, B, C, N) I still use that same routine to this very day. The second "feature" was not really a feature, but an accidental result of the primitive state of compiler technology. The original Fortran passed all parameters by reference, not value. To identify a passed parameter as an array, you had to mention it in a dimension statement. But we quickly learned that the size didn't matter; the compiler didn’t do range checking. It only needed to know that the variable was an array. This meant that we could use tricky constructs like the dimension statement above to operate on vectors of any size. Doing the same with matrices was a little trickier, because we had to do our own 2-d to 1-d indexing conversion, but we did it. By the time Fortran IV came along, this practice had become so popular that it couldn’t have been removed from the language, even if they wanted to. So they formalized the syntax into something called "variable dimensions," AKA conformant arrays. Now it was possible to write general functions operating on two-dimensional arrays:
SUBROUTINE MATX(A, B, C, L, M, N) Today, some people consider Fortran passé. More modern languages like Pascal and C are the rage and object-based languages like C++ even more so. To this day, not one of them support conformant arrays. Why is this? Frankly, I consider this a national disgrace. Surely, if Fortran could support the concept in 1967, some compiler wizard could figure out how to do it in C++, in the year 2000. I can only conclude that the people who design modern languages don't really care much about (or even understand) the needs of those of us who still do numerical computing. That's why Fortran remains the premiere language for number crunching. I first encountered Lahey Fortran in its 16-bit guise, back around 1986. I had been trying to sell my company on the idea of using PC's for more serious computations, but they tended to still think of them as toys. The company had a massive, highly computation-intensive covariance analysis program, that had been written in Fortran and ran on a DEC VAX-11/780. To back up my claim that the PC was for serious number-crunching, I was challenged to convert the analysis program to run on a true PC/AT (1 Mb RAM, all of 6MHz clock. The only concession I got was a hardware math chip). After some shopping around, I chose Lahey Fortran mainly for its ability to compile quickly and generate tight code. The program took some tinkering to get it to compile under Lahey. The first time I compiled it, I got hundreds of error messages. After tracking them down, it turned out that every single one was a legitimate error. Lahey had flagged programming errors, mostly type mismatches like implicit and inadvertent double-to-real conversions, that the DEC compiler had blithely accepted. In several cases, it flagged variables that were set but never used, and, worse yet, variables that were used but never set. Once the bugs had all been corrected, the program compiled without a hitch. Interestingly enough, not only was it small enough to run in the AT's 640k RAM space (the DEC version had been 1.5Mb), but it also ran 2-3 times FASTER than on the VAX. In bringing this system up and working out the bugs, I had occasion to call Lahey several times. I always found them to be extremely responsive and helpful, and the compiler itself was absolutely bulletproof. In the world of PC software in 1986 (or 2000, for that matter), I found this a refreshing state of affairs. About a year later, Tyler Sperry, editor of Computer Language, asked me Magazine, to review the current crop of 32-bit Fortran compilers. I think I reviewed seven compilers, all told, and gave each an ordinal rating. Some of the other compilers clearly were mere ports from the VAX world, and it showed. The worst of them crashed and burned on some of my benchmarks. Others were so difficult to use I simply set them aside. Lahey came out the clear victor, not just because of its speed and reliability, but also because it was nicely integrated with a development environment. Not surprisingly, from my experience both before and since, the compiler itself was rock solid. I've come to expect nothing less from Lahey. This review became something of a cult classic because I pulled no punches; I told things as they were. Needless to say, Tyler took a lot of flak from the vendors I'd rated low. One told him that their sales had been cut in half. But Tyler stuck to his editorial guns and refused to bend to pressures to retract any of my comments. Interestingly enough, other software vendors - the ones who had good products, and knew it - found the approach a refreshing breath of fresh air. More than one told Tyler they wanted the magazine to review their product also, but only if I agreed to do the review. I found that attitude a most uplifting one. Before closing, I should mention one other outstanding feature of Fortran: It changes. Other languages, like Algol and PL/1, have come and gone. Fortran is much more dynamic than C or Pascal; it continues to evolve, and change to meet new concepts like objects. That is a great part of its power. But most of all, Fortran has never forgotten its roots: It still remains a language for crunching numbers. And Windows programming to the contrary, sometimes it’s number crunching that we need. Jack W. Crenshaw holds a Ph.D. in Physics from Auburn University. He has spent over 40 years in the aerospace program, beginning with seminal work on Project Apollo. He is currently a senior principal design engineer for ATK, Inc., a defense contractor. He does math-intensive software and system design. He is a contributing editor for Embedded Systems Programming Magazine, and his popular column, "Programmer's Toolbox," has enjoyed an 8-year run with no signs of letup. He is a sometimes president of Crenshaw Technologies, a software/systems consulting firm, and his book, "Software Toolbox for Embedded Systems," is due for release in August. In his "spare" time, Crenshaw raises ducks and chickens, and helps to rehabilitate wild orphan baby birds and animals of all kinds. (Back to Contents) Winteracter v2.20 is now available! (Actually, it's been available since November 26, 1999.) If you haven’t upgraded to the latest version of Winteracter yet, you are missing out. Upgrades from earlier releases include a new manual with loads of new features: Graphoria emulation HelpEd Text Editor Graphics Primitives Bitmap Files Graphics Import Presentation Graphics Windows Memory Bitmaps Dialogs PlotConv So, what is Winteracter anyway? Winteracter is a 32-bit Windows user-interface and graphics package for Fortran 9x developers. It's available on Windows 9x, NT, and 2000 for all the major Fortran 9x compilers. Winteracter is developed by Interactive Software Services Ltd. and available from Lahey. Click on Products at http://www.lahey.com to check it out. Put a Windows front on that old Fortran code. (Back to Contents) GINO is the name of a collection of portable graphics and GUI development tools available on a wide range of platforms including Win95/Win98/Win2000/NT, Linux, UNIX and OpenVMS. GINO products offer everything from simple line-drawings to complex fully-interactive three-dimensional applications with a fully-featured GUI front-end. GINO-F Bundle for Linux Following on from the release of Lahey LF95 Linux Express, GINO-F Bundle has now been ported to LF95 Linux Express. The GINO-F Bundle under Linux comprises GINO F v4.3, GINOGRAF v4.2, GINOSURF v3.2 and GINOMENU v3.1 (compatible with GINOMENU under UNIX). GINOMENU v3.1 provides a unique programmable GUI with emulation styles of Windows 3.1, Windows 95 and MOTIF available. The Bundle is supplied with drivers for X-Windows, Postscript and JPEG and other drivers such as HPGL2, HP-Paintjet, Epson and Canon are also available. The GINO-F Bundle for Linux is routine-name compatible with the GINO-F Bundle for Windows providing seamless portability of applications between the two platforms. Price: $2100 ($1470 for educational license.) GINOMENU v4.0 for Windows Tabbed Dialog Box Tree Views Dockable Toolbars Bubble help Mouse-sensitive Icons Panel Backgrounds Security Text Price: $2100 ($1470 for educational license.) Special OfferAttendees of the F95/GINO Workshop qualify for significant discounts on GINO products. Read the notice in this newsletter for details. Express with Linux Clusters (Back to Contents) Linux versus Windows We hear anecdotal reports that Fortran compilers perform better under Linux than Windows on single processor systems. The reasons cited vary such as the way Linux handles disk I/O or the memory limitations of Windows. We decided to get an expert opinion on the subject. Dr. John Appleyard of Polyhedron performs benchmarks on all the major Fortran compilers for both Windows and Linux. The plusFORT analysis package produced by Polyhedron is the industry standard for analysis tools. According to Dr. Appleyard, "My own view is that for most Fortran related tasks, the two O/Ss give similar performance. Our benchmarks, which emphasize CPU and memory speed, appear to confirm that. Differences may be more apparent in areas such as web-hosting and transaction processing, which require more from the operating system." Linux ExpressThe debate will no doubt continue. On one point, though, there is no debate. The new LF95 Express for Linux has been enthusiastically accepted by the Linux community. For the first time, Linux power users have a high performance Fortran compiler for a price of only $249. We have received gratifying testimonials from all over the globe. A typical response comes from the University of Helsinki, an institute that ought to know a little bit about Linux. "That was quick! We did receive LF95 next day! We have now installed the first two of them and our first impression is very positive. Compared to Gnu g77 (which we used before) LF95 is several times more effective and the debugging information is excellent. Installation was also very straightforward." Jukka Piironen, Department of Astronomy, University of Helsinki MPICH for Linux "Linux Express was easily installed on our K7 Beowulf. With the complete [online] manuals provided by Lahey, the learning curve was extremely short. Performance using Linux Express versus g77 has significantly increased." Richard C. Martineau, Staff Scientist, Idaho National Engineering & Environmental Laboratory We have reports of people using LF95 with MPICH on 64-node systems, with faster performance than other Fortran compilers. The word is spreading fast. We have received requests to document the process to use LF95 Express with MPICH. By popular demand here is the process: Code and documentation for MPICH can be downloaded from http://www-unix.mcs.anl.gov/mpi/mpich. Once the package has been downloaded and unzipped, it can easily be configured for use with LF95 by using the configure script in the ~/mpich directory. Documentation for configure can be viewed by issuing the command: ./configure -help | more. Configuring MPICH for LF95 is straightforward, from the ~/mpich directory, issue the command: ./configure -fc=lf95 -f90=lf95 . This command will set lf95 as both the Fortran 77 compiler and the Fortran 90 compiler. It will find and test lf95 and generate a makefile to direct the actual building of MPICH. Before running make, the output of configure should be inspected for errors, and any problems found should be resolved. When we configured MPICH on our Redhat 6.0 system, no errors occurred. If errors are encountered, they most likely will involve older versions of packages required by MPICH. Downloading the latest stable version of the package in question will likely fix the problem. Once configuration is complete, you can build MPICH by typing make. If the configure was successful, it is most likely the make will proceed without a hitch. Once the make is complete, you may have to modify a couple of files. The first is machines.LINUX in the ~/mpich/util/machines directory. This file should contain the domain name of every machine that will run your program, with one name per line. To start with, this file will only contain the name of the machine building MPICH, repeated several times. MPICH will run multiple jobs on the same machine if it is listed more than once. The second file that needs to be created or modified is the hosts.equiv file in the /etc directory of every machine that will run MPICH. This file should contain the domain name of the machine that contains MPICH. Each node must have the LD_LIBRARY_PATH set with the path to the LF95 runtime libraries resident on the machine that has MPICH installed. A set of test routines comes with MPICH that can be used to validate the installation. Some simple tests are in the ~/mpich/examples/basic directory. You need to first build the fortran examples with the make utility. Do this with the commands make fpi and make fibon . You can run the examples using mpirun. For example, mpirun -np 4 fpi will run the fpi program on four processors. A more extensive test suite is in the ~/mpich/examples/test directory. These need to be configured with the command ./configure -cc=mpicc -fc=mpif77. You can then run the test suite by issuing the command make testing. Note that the test routines are still under development, and some difficulties might occur. If problems arise, first make sure you have the most up-to-date version, then contact the MPICH developers at mpi-maint@mcs.anl.gov for assistance. Although you can use MPICH on systems with a variety of characteristics, performance is best when all the machines have identical hardware and software configurations, as in a Beowolf cluster. This greatly simplifies the problem of load balancing – deciding which machine gets the next piece of the job. When different hardware and software are used, the slowest machine will dictate performance. MPICH provides a significant breakthrough in the availability and cost of high performance computing. LF95 and MPICH, when used with a larger cluster can provide supercomputing capabilities at a fraction of the cost of today’s supercomputers. (Back to Contents) Technical Support We'll continue to offer FREE e-mail, fax, and postal mail support on current product releases. Free support will continue to be available for previous versions of a product for 60 days after the release of a new version. Technical Support Policy
To save your environment variables in a text file, go to a command prompt and redirect the output of the SET command to a file: SET > SETCMD.OUT Attach the SETCMD.OUT file to your e-mail to support@lahey.com.
While simply typing the complete error message is always an option, you can save extensive messages to a text file to send to us, if that is easier. To save the messages as a text file, from the command line redirect the command output as in the following example: your_command_line > CMD.OUT Attach the CMD.OUT file to your e-mail to support@lahey.com. If you are using the ED editor, run your compile command and attach the ERRS.* file of the working directory to your e-mail to support@lahey.com.Support is provided free to solve problems with our products, and to answer questions on how to use Lahey products. Support personnel are not available to teach programming, debug programs, or answer questions about the use of non-Lahey products or tools (such as MS Windows, MS Visual Basic, etc.). These services are provided on a paid consulting basis. In our effort to provide better technical support, we will continue to streamline our procedures to meet the changing needs of our customers. Our goal is to automate the tech support process as much as possible in order to provide the fastest, most complete response possible to as many customers as possible. We will also be extensively modifying the FAQ section of our web site. By expanding and organizing this resource, many problems may be immediately resolved. Currently, e-mail requests for support allow us to organize an efficient tech support department and allow for quick turnaround time if the pertinent information is provided. Furthermore, e-mail is the most cost affective way for our customers to communicate with us. Our porting services and consulting contracts are always available to help you to solve difficult technical challenges or to get your Fortran projects finished. Fortran 95 and GINO Workshops During the week of April 30 - May 4, 2001, Lahey Computer Systems, Inc. and Bradly Associates, Ltd. are conducting Fortran 95 and GINO Workshops. The workshops will be held at Lake Tahoe in Incline Village, Nevada, USA.
Fortran 95 Workshop, April 30 - May 2, 2001 To register or for more information contact Gloria Whitlock, sales@lahey.com, 1-800-548-4778, or 1-775-831-2500 x459.
Fortran 95 Workshop The Fortran 95 Workshop is a six-session, hands-on, Fortran 95 workshop led by Thomas M. Lahey, CEO, Lahey Computer Systems, Inc. Workshop Goals
Capacity
Requirements
While at the workshop, participants use Pentium-class computers provided by Lahey. The Lahey/Fujitsu Fortran 95 language system will be installed on the computers. NOTE: If you prefer to use a different language system, you may bring your own notebook computer and Fortran 90 or 95 language system. Three weeks before the workshop begins, paid participants will receive a notebook containing instructional documents for each session: proprietary papers prepared especially for the workshop and copies of published papers. At the workshop you will also receive a copy of the book Upgrading to Fortran 90, your personal copy of Essential Lahey Fortran 90, and a disk containing copies of the Fortran code discussed in the workshop. Fortran 95 Workshop Agenda Monday, April 30, 2001
9:00 a.m. - 12:00 noon - Session I
12:00 noon - 1:30 p.m. - Lunch break 1:30 - 5:00 p.m. - Session II
Tuesday, May 1, 2001
8:30 a.m. - 12:00 noon - Session III
12:00 noon - 1:30 p.m. - Lunch break 1:30 - 5:00 p.m. - Session IV
Wednesday, May 2, 2001
8:30 a.m. - 12:00 noon - Session V
12:00 noon - 1:30 p.m. - Lunch break 1:30 - 5:00 p.m. - Session VI
Basic GINOMENU Workshop
The Basic GINOMENU workshop will take the form of a hands-on tutorial looking at gradually building up a small "Hello World" program from scratch and developing it into a fully interactive Fortran GUI application under Windows 95. Workshop Goal Capacity Requirements
While at the workshop, participants use Pentium-class computers provided by Lahey. The Lahey/Fujitsu Fortran 95 language system will be installed on the computers. NOTE: If you prefer to use a different language system, you may bring your own notebook computer and Fortran 90 or 95 language system. Basic GINOMENU Workshop Agenda Thursday, May 3, 2001 8:30 - 10:30 a.m. - Session 1
10:30 - 10:45 a.m. - Coffee 10:45 a.m. - 12:00 noon - Session 2
12:00 noon - 1:30 p.m. - Lunch break 1:30 - 3:30 p.m. - Session 3
3:30 - 3:45 p.m. - Tea break 3:45 - 5:00 p.m. - Session 4
GINO/OpenGL Workshop
Workshop Goal Capacity Requirements
You will need to bring your own notebook computer and F90/F95 language system. Thursday, May 3, 2001 8:30 - 9:30 a.m. - Introduction to the 3D World
8:30 - 9:30 a.m. - 3D Drawing
10:30 - 10:45 a.m. - Coffee 10:45 a.m. - 12:00 noon - Lighting and Shading
12:00 noon - 1:30 p.m. - Lunch break 1:30 - 2:30 p.m. - Materials
2:30 - 3:30 p.m. - Texture Mapping
3:30 - 3:45 p.m. - Tea break 3:45 - 5:00 p.m. - Animation
Different animation techniques will be covered and tried. More on performance and use of segments to round things off. GINO 5.0 Workshop
Workshop Goal Capacity Requirements
While at the workshop, participants use Pentium-class computers provided by Lahey. The Lahey/Fujitsu Fortran 95 language system will be installed on the computers. NOTE: If you prefer to use a different language system, you may bring your own notebook computer and Fortran 90 or 95 language system. Thursday, May 4, 2001 8:30 - 9:30 a.m. - Session 1
10:30 - 10:45 a.m. - Coffee 10:45 a.m. - 12:00 noon - Session 2
12:00 noon - 1:30 p.m. - Lunch break 1:30 - 3:30 p.m. - Session 3
3:30 - 3:45 p.m. - Tea break 3:45 - 5:00 p.m. - Session 4
GINOMENU Studio Workshop
The GINOMENU Studio workshop will take the form of a hands-on tutorial looking at interactively developing Fortran GUI front-ends and applications using drag-and-drop methodology. It will be shown how to produce menus, dialogs, widgets and icons, and interactively link up user actions with event-handling code all from the same development environment. The workshop will be led by David and Kevin Bradly, Bradly Associates Ltd. Workshop Goal Capacity Requirements
You will need to bring your own notebook computer and F90/F95 language system. GINOMENU Studio Workshop Agenda Thursday, May 4, 2001 8:30 - 9:30 a.m. - Session 1
9:30 - 10:30 a.m. - Session 2
10:30 - 10:45 a.m. - Coffee 10:45 a.m. - 12:00 noon - Session 3
12:00 noon - 1:30 p.m. - Lunch break 1:30 - 2:30 p.m. - Session 4
2:30 - 3:30 p.m. - Session 5
3:30 - 3:45 p.m. - Tea break 3:45 - 5:00 p.m. - Session 6
Workshop Tuition and Fees Fortran 95 Workshop
Basic GINOMENU Workshop
GINO/OpenGL Workshop
GINO 5.0 Workshop
GINOMENU Studio Workshop
Special Pricing
If you register and pay for a workshop before March 31, 2001, the cost is reduced by 10%. Workshop participants receive a 25% discount on all Lahey Language Systems and GINO products until July 4 2001.
Travel and Accommodations We recommend flying into Reno-Tahoe International Airport. Take Highway 395 South from the airport and exit at Mt. Rose Highway (State Route 431). Travel approximately 35 miles until you reach Highway 28. Turn right on Highway 28 for about 2 mile. The Tahoe Biltmore is on the right at the Nevada-California state line. From the Biltmore, travel east on Highway 28 for about 3 miles (past Mt. Rose Highway 431). The Lahey offices are located between Southwood Boulevard and Village Drive on the Lake Tahoe side of Highway 28 at 865 Tahoe Boulevard (Highway 28) in the Centerpointe Building. Rental cars are available at the airport. You may also contact Budget Chauffeur at 800-426-5644 for shuttle service. They leave the Reno airport for Incline Village and the Tahoe Biltmore numerous times during the day and night. Please make arrangements in advance.
Travel to the Lake Tahoe, Incline Village area from California:
CEO's Letter Dear Fortran Programmer, As you can see from this edition of Fortran SOURCE, the Lahey/Fujitsu partnership has committed to parallel processing in a big way with our Linux Version 6.0. To be frank, there are a number of issues we're concerned about:
There's another aspect: The chips are getting faster and faster, cheaper and cheaper. Both Intel (IA-64) and AMD are working on 64-bit chips that will (eventually) execute programs faster; especially if the programs need to do extended-precision arithmetic. Last but not least: We will conduct a Fortran 95 Workshop here in Incline Village on the shore of Lake Tahoe: April 30, May 1 & 2. Truckee Meadows Community College will provide computers (but not cameras). All you need is a reasonable size (50,000 lines at most) program coded in FORTRAN 77 that your boss would like you to begin porting.
Regards,
News
Briefs
Microway
GINO v5.0 Available In addition to containing the more common graphing features such as line graphs, charts, contour maps and 3D surfaces, GINO includes a fully programmable GUI interface (GINOMENU), and a host of low-level drawing routines for graphics development in 2D and 3D. Version 5.0 features fully integrated OpenGL functionality including facets, lighting, shading, and texture-mapping for developing state-of-the-art 3D models. GINO runs under Windows, Linux, OpenVMS, and most UNIX systems. The major new facility that has been added to the GINO library is the ability to create photo-realistic images using lighting and shading facilities, in conjunction with facets, ready-made objects, and surfaces. These new facilities are utilized with two new 3D device drivers, WOGL and GLX, both of which interface to the OpenGL API on PCs and UNIX workstations. GINO v5.0 libraries are available from Lahey Computer Systems, Inc.
Wineracter v3.0 Available Following are just a few of the many enhancements to Winteracter v3.0:
X/Winteracter
Documentation
Windows and Dialogs
Grid Controls
PNG Files
Presentation Graphics
Help Files
Visual Tools
Miscellaneous Winteracter is available from Lahey Computer Systems, Inc.
Q&A
Q: Can I create a program that runs on and takes advantage of more than one computer, each with two processors?
Q: Will my program take less time to run if I use the new parallel programming features in v6.0?
Q: Why does my program run slower on some newer distributions of Linux?
Workaround: Specify the -static option on your LF95 command line to statically link all the GNU C runtime (part of the Linux operating system) and Fortran runtime libraries into your executable program. This will make a much larger executable file than a dynamically linked one. Note: We don't recommend that you distribute this type of application, as it will be governed by the GNU Public License due to the copy of the GNU C runtime that it contains.
Q: I'm going to move my code from LF95 Windows v5.6 to LF95 Linux v6.0. What do I need to know?
Q: How can I make sure the Linux executables I create run on multiple Linux distributions and are backwards compatible with older distributions, as well as compatible with Linux distributions yet to come?
Q: Lahey keeps referring to Linux as if it were an operating system. Is that correct?
|
By the Solutions Department.