This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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