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

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

Brian,

This may be a cause, but I can't say without simply experimenting.  Fortran and 
C compilers are defined in files in $NAWIPS/config/ depending on system type, 
and there's no guarantee that the compiler flags and optimization are correct 
for the intended system.   They are also defined in the common 
$NAWIPS/config/Makeinc.common (which by default links to Makeinc.common_linux).

With $NAWIPS/Gemenviron or Gemenviron.profile (for bash) sourced, you will see 
the determined system architecture in the environmental variable $NA_OS (e.g. 
linux64), and along with the fortran compiler specified in 
$NAWIPS/Makeinc.common, this will tell you which of the makeinc files is being 
used (Makeinc.linux_pgi, Makeinc.linux_gfortran, etc).   We will need to know 
what $NA_OS and $FC and $CC (from Makeinc.common) is for each build.

Michael

> Good day Michael, all,
> 
> Not sure if this information was conveyed earlier: when making the build,
> are there preferred optimization choices for the compiler?  That may play
> a role in this, it may not.  If there are some 'always do this' or 'never
> do that' insights, that may be one place to take a look.
> 
> Regards,
> Brian E.
> 
> 
> On 4/26/13 2:10 PM, "Unidata GEMPAK Support"
> <address@hidden> wrote:
> 
> >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
> >
> 
> 
> 


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