[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20050628: 20050628: GEMPAK 5.8.2.a build on Intel 8.1 Fortran Compiler for Linux



Kevin,

The byteswapping code in GEMPAK, in particular the DM library
routines, use the OS code to determine the word order of the machine.
So, when modifying a MTMACH.PRM file for a new platform/compiler, the OS much
match the word order, and as you mention, the RECL must be correct as
genrally 1 or 4. The known machines defined for MTMACH are identified in the
data file that is created by GEMPAK, so that the file word order can be 
identified 
by other machines using GEMPAK to read a file created elsewhere (so back
wards compatibility requires that the other machines recognide the machine 
number.

The little endian machines I have used include the Dec Alpha/OSF1,
Linux on PC architecture, Solaris X86 for PC, Dec Ultrix and Dec VMS.
There may be specific instances where trying to use the OSF machine type
explicitly expects 64 bit configurations.

Steve Chiswell
Unidata User Support



>From: "Kevin R. Tyle" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200506281838.j5SIceW4015748

>Hi Steve,
>
>I got things to work by using a MCHPRM.<os> file that was akin to 
>MCHPRM.osf.  It appears that MTMACH and MMRECL need to be set to what 
>they are in the MCHPRM.osf file for maps to display properly.  I still 
>need to do some more testing to see if other things work properly, 
>although at least
>
>If there's interest, I can provide the Makefile that includes the 
>fortran compiler options that worked.  But basically it appears that the 
>ifort package ultimately had its genesis on the Alpha platform!
>
>--Kevin
>
>Unidata Support wrote:
>
>>Kevin,
>>
>>All map files are now read as big endian. There is not a separate
>>version of maps for DEC/Linux anymore.
>>
>>If you have trouble with maps, you either haven't defined the OS correctly fo
> r
>>MACHPRM.PRM, or your optimization for the compiler isn't working.
>>
>>Steve Chiswell
>>Unidata User Support
>>
>>  
>>
>>>From: "Kevin R. Tyle" <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200506281343.j5SDhrW4028115
>>>    
>>>
>>
>>  
>>
>>>Hi Steve,
>>>
>>>Thanks for that.  Meanwhile, I have built the distribution using the 
>>>Intel Fortran compiler and have found that maps don't display.  I 
>>>believe it requires a byte-swapped version of the map files to work, as 
>>>was necessary for the old DEC/OSF builds of GEMPAK.  It appears that the 
>>>option to build and use  a "DECMAPS" version of the map files has been 
>>>aged out of the build process.  Do you have any advice on how to 
>>>re-enable this?
>>>
>>>Thanks,
>>>
>>>Kevin
>>>
>>>Unidata Support wrote:
>>>
>>>    
>>>
>>>>Kevin,
>>>>
>>>>I added the perror while trying to track down the limitations
>>>>of the pgf77 compilers. Some people wanted to use something
>>>>other than g77, and the pgf77 compiler had a limitation that
>>>>you could not open the same file more than once (which GEMPAK does).
>>>>The perror was necessary to get the 901 translation by the pg compiler.
>>>>That was an internal fortran runtime STATUS error, and not the type of thin
> g
>>>>ththat the ER_ library would know about.
>>>>
>>>>There was no error message there previously, and you can remove it,
>>>>or comment it out as you need for your work.
>>>>
>>>>Steve Chiswell
>>>>Unidata User SUpport
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>>>From: "Kevin R. Tyle" <address@hidden>
>>>>>Organization: UCAR/Unidata
>>>>>Keywords: 200506271957.j5RJvCNi026217
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>>>This is a multi-part message in MIME format.
>>>>>--------------010608080003090905010603
>>>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>>Content-Transfer-Encoding: 7bit
>>>>>
>>>>>Hi Steve,
>>>>>
>>>>>I'm forwarding this little thread with Scott Jacobs regarding a question 
>>>>>I had about FL_WRIT.  It looks like the "perror" line was added in 
>>>>>September 2004 by you guys?  Anyway, it seems to be incompatible with 
>>>>>the Intel Fortran compiler for Linux, which I am playing with.  Do you 
>>>>>think it can safely be removed for future builds?
>>>>>
>>>>>Regards,
>>>>>
>>>>>Kevin
>>>>>
>>>>>--------------010608080003090905010603
>>>>>Content-Type: message/rfc822;
>>>>>name="Re: FL_WRIT and perror"
>>>>>Content-Transfer-Encoding: 7bit
>>>>>Content-Disposition: inline;
>>>>>filename="Re: FL_WRIT and perror"
>>>>>
>>>>>X-Account-Key: account2
>>>>>Return-Path: <address@hidden>
>>>>>Received: from mocbox2.nems.noaa.gov (mocbox2.nems.noaa.gov [140.90.121.14
> 2]
>>>>>        
>>>>>
>>>)
>>>    
>>>
>>>>>   by atmos.albany.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j5RJXoe13310
>>>>>   for <address@hidden>; Mon, 27 Jun 2005 19:33:50 GMT
>>>>>Received: from [140.90.193.205] ([140.90.193.205]) by
>>>>>        mocbox2.nems.noaa.gov (Netscape Messaging Server 4.15) with
>>>>>        ESMTP id IIRD0E00.CV1 for <address@hidden>; Mon, 27 Jun
>>>>>        2005 15:33:50 -0400 
>>>>>Message-ID: <address@hidden>
>>>>>Date: Mon, 27 Jun 2005 15:33:50 -0400
>>>>>From: Scott Jacobs <address@hidden>
>>>>>User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
>>>>>X-Accept-Language: en-us, en
>>>>>MIME-Version: 1.0
>>>>>To: "Kevin R. Tyle" <address@hidden>
>>>>>Subject: Re: FL_WRIT and perror
>>>>>References: <address@hidden>
>>>>>In-Reply-To: <address@hidden>
>>>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>>Content-Transfer-Encoding: 7bit
>>>>>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 
>>>>>   cypress.atmos.albany.edu
>>>>>X-Spam-Status: No, hits=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham
>  
>>>>>   version=2.63
>>>>>X-Spam-Level: 
>>>>>
>>>>>Kevin,
>>>>>
>>>>>Things are ok. Not so hot today, but rather humid -- 81 over 72 -- right 
>>>>>now.
>>>>>
>>>>>I don't know where the call to PERROR came from. My copy of FL_WRIT has 
>>>>>the following:
>>>>>
>>>>>IF  ( iostat .ne. 0 )  THEN
>>>>>    iret = -5
>>>>>ELSE
>>>>>    iret = 0
>>>>>END IF
>>>>>
>>>>>PERROR may have been added by Unidata. I would suggest removing it.
>>>>>
>>>>>Scott
>>>>>
>>>>>
>>>>>Kevin R. Tyle wrote:
>>>>>
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>>>Hi Scott,
>>>>>>
>>>>>>Hope you're doing well and that you're not roasting away in the torrid 
>>>>>>DC summer.  Anyway, I'm trying to build GEMPAK on linux using the 
>>>>>>Intel fortran compiler (ifort).  It doesn't  seem to have a "perror" 
>>>>>>command, which is causing problems when linking against FL_WRIT.  
>>>>>>FL_WRIT has these lines:
>>>>>>
>>>>>>C
>>>>>>C*      Get the GEMPAK file error number.
>>>>>>C
>>>>>>      IF  ( iostat .ne. 0 ) THEN
>>>>>>          write ( *,*) 'iostat ',iostat,irec, lenw
>>>>>>          call perror('flwrit')
>>>>>>
>>>>>>Any idea why perror is used instead of a call to ER_WMSG?  This seems 
>>>>>>to be the only place in the FORTRAN subroutines/programs where perror 
>>>>>>is used insteasd of ER_WMSG when an error messsage needs to be generated.
>>>>>>
>>>>>>          
>>>>>>
>>>>>>From what I can tell, the Intel Fortran compiler looks like it has its 
>>>>>        
>>>>>
>>>>>>roots in the DEC/OSF fortran compilers from days of yore . . .
>>>>>>
>>>>>>Thanks!
>>>>>>
>>>>>>Kevin
>>>>>>     
>>>>>>
>>>>>>          
>>>>>>
>>>>>--------------010608080003090905010603--
>>>>>
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>--
>>>>***************************************************************************
> * 
>>>>      
>>>>
>>><
>>>    
>>>
>>>>Unidata User Support                                    UCAR Unidata Progra
> m 
>>>>      
>>>>
>>><
>>>    
>>>
>>>>(303)497-8643                                                  P.O. Box 300
> 0 
>>>>      
>>>>
>>><
>>>    
>>>
>>>>address@hidden                                   Boulder, CO 8030
> 7 
>>>>      
>>>>
>>><
>>>    
>>>
>>>>---------------------------------------------------------------------------
> - 
>>>>      
>>>>
>>><
>>>    
>>>
>>>>Unidata WWW Service              http://my.unidata.ucar.edu/content/support
>   
>>>>      
>>>>
>>><
>>>    
>>>
>>>>---------------------------------------------------------------------------
> - 
>>>>      
>>>>
>>><
>>>    
>>>
>>>>NOTE: All email exchanges with Unidata User Support are recorded in the
>>>>Unidata inquiry tracking system and then made publicly available
>>>>through the web.  If you do not want to have your interactions made
>>>>available in this way, you must let us know in each email you send to us.
>>>>
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>--
>>**************************************************************************** 
>>Unidata User Support                                    UCAR Unidata Program 
>>(303)497-8643                                                  P.O. Box 3000 
>>address@hidden                                   Boulder, CO 80307 
>>---------------------------------------------------------------------------- 
>>Unidata WWW Service              http://my.unidata.ucar.edu/content/support  
>>---------------------------------------------------------------------------- 
>>NOTE: All email exchanges with Unidata User Support are recorded in the
>>Unidata inquiry tracking system and then made publicly available
>through the web.  If you do not want to have your interactions made
>>available in this way, you must let us know in each email you send to us.
>>
>>
>>  
>>
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.