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

[GEMPAK #KFD-709221]: GEMPAK Help Needed!

Kevin and others,

Thanks for the note.  I admit that getting the GNU and Intel compiler builds 
right is not something I have dealt with in a long time, and I may not have any 
experience with these particular machine types.

I need some more information from you, but I want to see at the beginning here 
if it's possible for me to have a temporary remote login (gempak account) to 
one or all of the machines.  I understand this may not be allowed if there are 
security restrictions on your end, but many times in the past this has allowed 
me to check the build and find problems much more quickly than with an exchange 
of emails.

If that is a possibility, you can write me directly at address@hidden with the 
machine details, and we can arrange a phone call for password.  I asked you to 
write the support-gempak address here so that our exchange goes into our web 
archive, so any machine access info exchanged should be done through private 
email rather than here.

That said, could you provide me with the machine specs (32/64 bit and OS 
version) along with all versions of ifort and icc on intel systems and versions 
of pgf77 and pgcc on the Portland system?

I should warn that I do not have such systems available for testing the build 
right now.  If I can't access your systems to check it may take me some time to 
arrange machines or virtual machines for testing.

Thanks,

Michael James
Unidata



> Hi...
> 
> My name is Kevin Thomas, and I'm with the "Center for Analysis and Predictions
> of Storms" (CAPS) at the University of Oklahoma.  I'm working in support of
> the HWT (Hazardous Weather Testbed) eperiment with SPC and NSSL people.
> 
> We have our own software that creates GEMPAK output for numerical model runs,
> mostly WRF.  Our program WRF2ARPS, has run successfully on our local BOOMER
> supercomputer, NICS/KRAKEN, NICS/ATHENA, plus previous generation computers
> at PSC.
> 
> I'm currently using the new NICS/DARTER supercomputer, and that is where I'm
> having problems.
> 
> Intel builds of our code generate GEMPAK files that are almost 4x the size
> of those generated on BOOMER or KRAKEN.  They are also garbage files, as no
> GEMPAK reader software can recognize the data.
> 
> The GEMPAK release is 5.11.4, built by NICS people.  DARTER Fortran is
> Ifort is version 13.1.0.
> 
> This is what works and what doesn't.
> 
> BOOMER/Intel  Runs fine.      Version 6.4.0
> BOOMER/Portland       Runs fine.
> 
> KRAKEN/Portland       Runs fine.      Version 5.11.4
> KRAKEN/GNU    Endian wrong!   No Intel build here
> 
> DARTER/Intel  Monster files!  Version 5.11.4
> DARTER/GNU    Endian wrong!   No Portal build here
> 
> My only guess is that the Intel compiler had made a mess of optimization.
> 
> It seems strange that a GNU build wouldn't come out right.  As an example
> of the output, from the beginning:
> 
> Good: GEMPAK DATA
> Bad:  PMEGD KA AT
> 
> Any help or ideas would be greatly appreciated!
> 
> Maybe a lower opt level might help, though that hasn't been tried.
> The person compiling, on this list, is new at this too.
> 
> Thanks!
> 
> Kevin W. Thomas
> Center for Analysis and Prediction of Storms
> University of Oklahoma
> Norman, Oklahoma
> Email:  address@hidden
> 
> 


Ticket Details
===================
Ticket ID: KFD-709221
Department: Support GEMPAK
Priority: Normal
Status: Open