[Ncep.list.nems.announce] Feedback requested on replacing the NEMS build system.
shrinivas.moorthi at noaa.gov
Tue Feb 7 19:09:57 UTC 2017
I am able to compile now after I upgraded the ICS version. However,
I am crashing with error
symbol lookup error:
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?).
On 02/07/2017 11:27 AM, Gerhard Theurich wrote:
> 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.
> 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)?
>> 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?
>>> - 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
>>> 6. The NEMS/src/configure script contains application-specific
>>> logic. This also forces applications to use non-trunk versions of the
>>> Sam Trahan
>>> Ncep.list.nems.announce mailing list
>>> Ncep.list.nems.announce at lstsrv.ncep.noaa.gov
>> Dr. Shrinivas Moorthi
>> Research Meteorologist
>> Global Climate and Weather Modeling Branch
>> Environmental Modeling Center / National Centers for Environmental
>> 5830 University Research Court - (W/NP23), College Park MD 20740 USA
>> Ncep.list.nems.announce mailing list
>> Ncep.list.nems.announce at lstsrv.ncep.noaa.gov
Dr. Shrinivas Moorthi
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
More information about the Ncep.list.nems.announce