[Ncep.list.nems.announce] Feedback requested on replacing the NEMS build system.

James Abeles - NOAA Affiliate james.a.abeles at noaa.gov
Tue Feb 7 19:19:20 UTC 2017

The problem is with your module load order. Make sure when you build and run that ibmpe is loaded after the ics module 

> On Feb 7, 2017, at 2:14 PM, Gerhard Theurich <theurich at sourcespring.net> wrote:
> Moorthi,
> So that "crashes" at start-up, basically during loading? I assume that 
> there are incompatible libraries used during linking vs. running. It may 
> come down to what compiler modules are loaded in your scripts. What 
> modules do you load during compiling vs. running?
> -Gerhard
>> On 02/07/2017 11:09 AM, Shrinivas Moorthi wrote:
>> Gerhard,
>>    I am able to compile now after I upgraded the ICS version. However,
>> I am crashing with error
>> "/ptmpp2/Shrinivas.Moorthi/NEMS/NEMS_574_2012102400_cs_4128_mic7fe/NEMS.x:
>> symbol lookup error:
>> /ptmpp2/Shrinivas.Moorthi/NEMS/NEMS_574_2012102400_cs_4128_mic7fe/NEMS.x: undefined
>> symbol: tbk_string_stack_signal_impl"
>> and I am not getting any info in PET files either.
>> Do you or anyone know what error is this (in ESMF?).
>> Thanks
>> Moorthi
>>> On 02/07/2017 11:27 AM, Gerhard Theurich wrote:
>>> Hi,
>>> Just for the immediate, I am wondering what the problem is with
>>> NEMSAppBuilder on WCOSS? Has anybody looked into it? I thought Patrick
>>> was building the coupled system on WCOSS, so it does surprise me that
>>> Moorthi cannot get GSM standalone working.
>>> Most important for the long term that I see is a _maintained_ system.
>>> Any system that is not maintained will break, especially if it has to
>>> cover a wide range of complex cases that keep changing (e.g. new
>>> components coming in). A maintained system will be able to change
>>> according to changing needs.
>>> One fundamental concept of the NEMSAppBuilder was to provide a single
>>> place where the build recipes of all the various components are kept.
>>> That is why it is part of the NEMS infrastructure: any app that uses a
>>> specific model component (even if it is a different revision of that
>>> component) should be able to just tell the AppBuilder that it wants to
>>> build that certain component, not have to know how to do this. (In the
>>> current AppBuilder this is implemented via the build_xxx() routines in
>>> the script. E.g. build_cice() will tell the system how to build CICE.
>>> These routines are typically just a few lines long and use a few
>>> variables to get the job done.)
>>> Another basic concept was that the configuration for an app should be
>>> provided by a very simple file, telling the app builder what
>>> components are to be built and linked together. Those are the
>>> *.appBuilder files.
>>> Obviously the implementation details, including how maybe a GUI is
>>> implemented could change, but I do think the fundamental concepts and
>>> how they are divided between app layer and NEMS layer are still valid.
>>> -Gerhard
>>>> On 02/07/2017 06:04 AM, Shrinivas Moorthi wrote:
>>>> I can't compile standalone GSM on wcoss. How do I do it without
>>>> blackbox (appbuilder)?
>>>> Thanks
>>>> Moorthi
>>>>> On 02/07/2017 08:46 AM, Samuel Trahan - NOAA Affiliate wrote:
>>>>> Hi all,
>>>>> The NEMS build system, NEMSAppBuilder, is causing a lot of problems,
>>>>> especially for the atmospheric model developers.  We plan on replacing
>>>>> the build system.  What do you want out of the new build system?  What
>>>>> do you dislike about the old one?
>>>>> Some questions to ponder:
>>>>> - How should the build system work internally?  Shell script? Make?
>>>>> Cmake?
>>>>> - How should you run the build system?  Shell script?  Run "make?"
>>>>> Run a GUI?
>>>>> - When do we replace the build system?  Do we do it now, and risk
>>>>> breaking coupled systems? Do we wait until we can test it with the
>>>>> coupled applications?
>>>>> Feedback thus far:
>>>>> 1. It is difficult to navigate the 1900 line NEMSAppBuilder to figure
>>>>> out how to change the build commands.
>>>>> 2. Some users want to be able to manually build the NEMS without
>>>>> running an overarching script.
>>>>> 3. Some users want a simple graphical interface to select components
>>>>> and build the NEMS.  (Yes, there are users that want this.)
>>>>> 4. Sometimes, components compile with options that are incompatible
>>>>> with the linking options.  This is because each component has its own
>>>>> configuration system.  This causes problems, as we saw with FV3.
>>>>> 5. The logic for building a component is in the NEMS framework level.
>>>>> Any time a component's build system changes, the NEMS framework has to
>>>>> be updated, breaking applications that use older versions of the
>>>>> component. This forces applications to use non-trunk versions of the
>>>>> NEMS.
>>>>> 6.  The NEMS/src/configure script contains application-specific
>>>>> logic.  This also forces applications to use non-trunk versions of the
>>>>> NEMS.
>>>>> Sincerely,
>>>>> Sam Trahan
>>>>> _______________________________________________
>>>>> Ncep.list.nems.announce mailing list
>>>>> Ncep.list.nems.announce at lstsrv.ncep.noaa.gov
>>>>> https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce
>>>> --
>>>> Dr. Shrinivas Moorthi
>>>> Research Meteorologist
>>>> Global Climate and Weather Modeling Branch
>>>> Environmental Modeling Center / National Centers for Environmental
>>>> Prediction
>>>> 5830 University Research Court - (W/NP23), College Park MD 20740 USA
>>>> Tel:(301)683-3718
>>>> _______________________________________________
>>>> Ncep.list.nems.announce mailing list
>>>> Ncep.list.nems.announce at lstsrv.ncep.noaa.gov
>>>> https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce
> _______________________________________________
> Ncep.list.nems.announce mailing list
> Ncep.list.nems.announce at lstsrv.ncep.noaa.gov
> https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce

More information about the Ncep.list.nems.announce mailing list