<div dir="ltr"><div><div><div>Gerhard,<br><br></div>Regardless of the surrounding political issues, if we have a build system where configuration is set in fewer places, it will be easier to port and maintain. I'm hoping this discussion with the general NEMS community will produce such a thing.<br><br></div>Sincerely,<br></div>Sam Trahan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 7, 2017 at 12:35 PM, Gerhard Theurich <span dir="ltr"><<a href="mailto:theurich@sourcespring.net" target="_blank">theurich@sourcespring.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sam,<br>
<br>
I understand. Just that it makes building a unified system that spans atm-only to complex coupled systems very difficult. Further there is also a mandate to the larger community. And it wasn't like the old (pre-AppBuilder) system was all that great. E.g. folks could not just take it to a different system and expect to get it to build unless you had good knowledge of the system - and that was just for atm-only. Considering all of the different coupled systems at EMC, the atm-only development, and the larger community (e.g. represented in the SAWG), I am honestly scared of how the unanimous consent will look like (if even achievable). But I know you know all that, too.<br>
<br>
-Gerhard<span class=""><br>
<br>
On 02/07/2017 09:21 AM, Samuel Trahan - NOAA Affiliate wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Gerhard,<br>
<br>
The ideas behind the NEMSAppBuilder are fundamentally sound.<br>
Unfortunately, the underlying implementation of it and the surrounding<br>
system (conf files, module files, nems/src/configure) make it hard to<br>
develop and maintain. The largest problem is not a technical issue, it<br>
is a problem with the EMC corporate culture.<br>
<br>
The atmospheric standalone developers refuse to use or maintain the<br>
NEMSAppBuilder, which is making it difficult for the coupled model<br>
developers to update their atmospheric component. Unfortunately, EMC<br>
has no command structure (except on paper) and developers are free to do<br>
as they please. That means we need unanimous consent about the NEMS<br>
build and test systems in order to move forward.<br>
<br>
Sincerely,<br>
Sam Trahan<br>
<br>
On Tue, Feb 7, 2017 at 11:27 AM, Gerhard Theurich<br></span><div><div class="h5">
<<a href="mailto:theurich@sourcespring.net" target="_blank">theurich@sourcespring.net</a> <mailto:<a href="mailto:theurich@sourcespring.net" target="_blank">theurich@sourcespring.<wbr>net</a>>> wrote:<br>
<br>
Hi,<br>
<br>
Just for the immediate, I am wondering what the problem is with<br>
NEMSAppBuilder on WCOSS? Has anybody looked into it? I thought Patrick<br>
was building the coupled system on WCOSS, so it does surprise me that<br>
Moorthi cannot get GSM standalone working.<br>
<br>
Most important for the long term that I see is a _maintained_ system.<br>
Any system that is not maintained will break, especially if it has to<br>
cover a wide range of complex cases that keep changing (e.g. new<br>
components coming in). A maintained system will be able to change<br>
according to changing needs.<br>
<br>
One fundamental concept of the NEMSAppBuilder was to provide a single<br>
place where the build recipes of all the various components are kept.<br>
That is why it is part of the NEMS infrastructure: any app that uses a<br>
specific model component (even if it is a different revision of that<br>
component) should be able to just tell the AppBuilder that it wants to<br>
build that certain component, not have to know how to do this. (In the<br>
current AppBuilder this is implemented via the build_xxx() routines in<br>
the script. E.g. build_cice() will tell the system how to build CICE.<br>
These routines are typically just a few lines long and use a few<br>
variables to get the job done.)<br>
<br>
Another basic concept was that the configuration for an app should be<br>
provided by a very simple file, telling the app builder what components<br>
are to be built and linked together. Those are the *.appBuilder files.<br>
Obviously the implementation details, including how maybe a GUI is<br>
implemented could change, but I do think the fundamental concepts and<br>
how they are divided between app layer and NEMS layer are still valid.<br>
<br>
-Gerhard<br>
<br>
On 02/07/2017 06:04 AM, Shrinivas Moorthi wrote:<br>
> I can't compile standalone GSM on wcoss. How do I do it without<br>
> blackbox (appbuilder)?<br>
> Thanks<br>
> Moorthi<br>
><br>
> On 02/07/2017 08:46 AM, Samuel Trahan - NOAA Affiliate wrote:<br>
>> Hi all,<br>
>><br>
>> The NEMS build system, NEMSAppBuilder, is causing a lot of problems,<br>
>> especially for the atmospheric model developers. We plan on<br>
replacing<br>
>> the build system. What do you want out of the new build<br>
system? What<br>
>> do you dislike about the old one?<br>
>><br>
>> Some questions to ponder:<br>
>><br>
>> - How should the build system work internally? Shell script? Make?<br>
>> Cmake?<br>
>><br>
>> - How should you run the build system? Shell script? Run "make?"<br>
>> Run a GUI?<br>
>><br>
>> - When do we replace the build system? Do we do it now, and risk<br>
>> breaking coupled systems? Do we wait until we can test it with the<br>
>> coupled applications?<br>
>><br>
>> Feedback thus far:<br>
>><br>
>> 1. It is difficult to navigate the 1900 line NEMSAppBuilder to<br>
figure<br>
>> out how to change the build commands.<br>
>><br>
>> 2. Some users want to be able to manually build the NEMS without<br>
>> running an overarching script.<br>
>><br>
>> 3. Some users want a simple graphical interface to select components<br>
>> and build the NEMS. (Yes, there are users that want this.)<br>
>><br>
>> 4. Sometimes, components compile with options that are incompatible<br>
>> with the linking options. This is because each component has<br>
its own<br>
>> configuration system. This causes problems, as we saw with FV3.<br>
>><br>
>> 5. The logic for building a component is in the NEMS framework<br>
level.<br>
>> Any time a component's build system changes, the NEMS framework<br>
has to<br>
>> be updated, breaking applications that use older versions of the<br>
>> component. This forces applications to use non-trunk versions of<br>
the NEMS.<br>
>><br>
>> 6. The NEMS/src/configure script contains application-specific<br>
>> logic. This also forces applications to use non-trunk versions<br>
of the<br>
>> NEMS.<br>
>><br>
>> Sincerely,<br>
>> Sam Trahan<br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Ncep.list.nems.announce mailing list<br>
>> <a href="mailto:Ncep.list.nems.announce@lstsrv.ncep.noaa.gov" target="_blank">Ncep.list.nems.announce@lstsrv<wbr>.ncep.noaa.gov</a><br></div></div>
<mailto:<a href="mailto:Ncep.list.nems.announce@lstsrv.ncep.noaa.gov" target="_blank">Ncep.list.nems.announc<wbr>e@lstsrv.ncep.noaa.gov</a>><br>
>><br>
<a href="https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce" rel="noreferrer" target="_blank">https://www.lstsrv.ncep.noaa.g<wbr>ov/mailman/listinfo/ncep.list.<wbr>nems.announce</a><span class=""><br>
<<a href="https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce" rel="noreferrer" target="_blank">https://www.lstsrv.ncep.noaa.<wbr>gov/mailman/listinfo/ncep.list<wbr>.nems.announce</a>><br>
><br>
><br>
> --<br>
> Dr. Shrinivas Moorthi<br>
> Research Meteorologist<br>
> Global Climate and Weather Modeling Branch<br>
> Environmental Modeling Center / National Centers for<br>
Environmental Prediction<br>
> 5830 University Research Court - (W/NP23), College Park MD 20740 USA<br>
> Tel:(301)683-3718<br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Ncep.list.nems.announce mailing list<br>
> <a href="mailto:Ncep.list.nems.announce@lstsrv.ncep.noaa.gov" target="_blank">Ncep.list.nems.announce@lstsrv<wbr>.ncep.noaa.gov</a><br></span>
<mailto:<a href="mailto:Ncep.list.nems.announce@lstsrv.ncep.noaa.gov" target="_blank">Ncep.list.nems.announc<wbr>e@lstsrv.ncep.noaa.gov</a>><br>
><br>
<a href="https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce" rel="noreferrer" target="_blank">https://www.lstsrv.ncep.noaa.g<wbr>ov/mailman/listinfo/ncep.list.<wbr>nems.announce</a><span class=""><br>
<<a href="https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce" rel="noreferrer" target="_blank">https://www.lstsrv.ncep.noaa.<wbr>gov/mailman/listinfo/ncep.list<wbr>.nems.announce</a>><br>
><br>
______________________________<wbr>_________________<br>
Ncep.list.nems.announce mailing list<br>
<a href="mailto:Ncep.list.nems.announce@lstsrv.ncep.noaa.gov" target="_blank">Ncep.list.nems.announce@lstsrv<wbr>.ncep.noaa.gov</a><br></span><span class="">
<mailto:<a href="mailto:Ncep.list.nems.announce@lstsrv.ncep.noaa.gov" target="_blank">Ncep.list.nems.announc<wbr>e@lstsrv.ncep.noaa.gov</a>><br>
<a href="https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce" rel="noreferrer" target="_blank">https://www.lstsrv.ncep.noaa.g<wbr>ov/mailman/listinfo/ncep.list.<wbr>nems.announce</a><br>
<<a href="https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce" rel="noreferrer" target="_blank">https://www.lstsrv.ncep.noaa.<wbr>gov/mailman/listinfo/ncep.list<wbr>.nems.announce</a>><br>
<br>
<br>
</span></blockquote>
</blockquote></div><br></div>