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

Tue Feb 7 16:25:39 UTC 2017

Jun,

If we have a simple build system for the NEMS, like "configure" and "make,"
then it should be easy for users to:

1. take out the build commands they need, and create their own compile.sh,
and

2. put their modified compile.sh commands back in to the build system.

Sincerely,
Sam Trahan

On Tue, Feb 7, 2017 at 11:00 AM, Jun Wang - NOAA Affiliate <
jun.wang at noaa.gov> wrote:

> Hi,
>
> Here are my two cents.
>
> NEMS needs to have a unified build system, which is cross applications. It
> will be general and can be complicate as it has to cover many coupled
> applications with arbitrary components specified. I assume NEMSAppBuilder
> is currently the build system, and it needs to be simplified, the GUI
> system is not working for me in many platforms, I would suggest to use a
> non-GUI system.
>
> For some simple application, especially the standalone system such as fv3
> and gsm, developers should be given the flexibility to build their own
> applications without using the complicated NEMS build system. A simple
> compile.sh with 4 or 5 lines can work well for standalone system, but may
> not be suitable for the coupled system. Of course the compile.sh are using
> same module and configuration file as NEMSAppBuilder.
>
> Thanks.
>
>
> Jun
>
> On Tue, Feb 7, 2017 at 10:47 AM, Samuel Trahan - NOAA Affiliate <
> samuel.trahan at noaa.gov> wrote:
>
>> Let me send something that various people have suggested:
>>
>> cd NEMS/src
>> ./configure something.appBuilder
>> source conf/modules.nems.sh
>> make
>>
>> The configure script and makefile would be updated to know how to build
>> the components based on an appBuilder file.  The file would look slightly
>> different than it does now, but would specify the same information.
>>
>> If a GUI is built, it would be a wrapper around those three commands.
>> The internal logic in NEMSAppBuilder is just a wrapper around a far more
>> complex build process and a list of appBuilder files.  It should be
>> feasible to modify the script to use the new build system.  The only
>> complicated part is figuring out how to specify arbitrary sets of
>> components without an appBuilder file.  That feature of NEMSAppBuilder is
>> not fully maintained right now, since it is rarely used, but would be very
>> useful in the future.
>>
>> However, if we are to maintain a text-based GUI, it should be based on a
>> widget set that is always present, rather than having Gerhard install it on
>> each machine.  The python curses module is one option since it is part of
>> every Linux distribution and even OS/X.
>>
>> Sincerely,
>> Sam Trahan
>>
>> On Tue, Feb 7, 2017 at 10:41 AM, Patrick Tripp <patrick.tripp at noaa.gov>
>> wrote:
>>
>>> Sam,
>>>
>>> I don't really need a GUI build system although I do use the
>>> NEMSAppbuilder and never had any major problems with it. I prefer using the
>>> non-interactive capability now.
>>> A Cupid/Eclipse based GUI assumes these tools are installed on the
>>> systems and the needed network connections are available (e.g. NX, X11,
>>> etc.). This is something that has been problematic in the past. It also
>>> requires many of us to learn a new tool/build system if this is the only
>>> option. Do we really need all of the bells and whistles of Eclipse/Cupid,
>>> just to build? I think we should keep it as simple as possible. Whatever is
>>> used, it has to work with the coupled systems, multiple components. This
>>> was the reason for the NEMSAppbuilder in the first place.
>>>
>>> - Patrick
>>>
>>>
>>> On 2/7/17 9:25 AM, Samuel Trahan - NOAA Affiliate wrote:
>>>
>>> Anning,
>>>
>>> The "configure and gmake" no longer works after the atmos layer is
>>> removed.  Even while we had the atmos layer, "configure and gmake" only
>>> compiled with an atmosphere.  Each component has its own build system, and
>>> some of them are complicated to run.
>>>
>>> One option is to make the "configure and gmake" more capable so that it
>>> CAN build the entire coupled system.  As for the GUI, it would be easy to
>>> make one once we have a new way of building the NEMS.  We could even have
>>> the "NEMSAppBuilder" look exactly like it did before (but with changes to
>>> to the appBuilder files).
>>>
>>> However, I don't think a text-based GUI is the right way to implement
>>> that.  This is a project, Cupid, to make a graphical IDE for all of NEMS.
>>> It does more than just building the system.  It has is code analysis and
>>> code generation tools, as well as interactive profile analysis tools.
>>>
>>> I think it would be better to use Cupid to provide the graphical
>>> front-end.   The NEMS repository would provide the back-end as a simple,
>>> easy to maintain, non-interactive build system of a more traditional
>>> nature.  Users that want extra flexibility can use Cupid's more powerful
>>> user interface.  The Eclipse-based Cupid system will be far more powerful
>>> than anything we can hack together in a text-based world.
>>>
>>> Sincerely,
>>> Sam Trahan
>>>
>>> On Tue, Feb 7, 2017 at 9:17 AM, Anning Cheng - NOAA Affiliate <
>>> anning.cheng at noaa.gov> wrote:
>>>
>>>> I still like the old way, configure and gmake in NEMS/src. It is good
>>>> to have NEMSAppBuilder, but why not keep both? Is it possible?
>>>>
>>>> On Tue, Feb 7, 2017 at 9:07 AM, Samuel Trahan - NOAA Affiliate <
>>>> samuel.trahan at noaa.gov> wrote:
>>>>
>>>>> Moorthi,
>>>>>
>>>>> That is the most common complaint.  I tried to cover that in items #1
>>>>> and #2 of my "feedback thus far" list in the previous email.  There are
>>>>> really two aspects to the problem:
>>>>>
>>>>> 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.
>>>>>
>>>>> Ultimately, if there was a simpler "NEMSAppBuilder" (problem #1) it
>>>>> would be easy to pick out the few commands you need to run manually
>>>>> (problem #2).
>>>>>
>>>>> Sincerely,
>>>>> Sam Trahan
>>>>>
>>>>> On Tue, Feb 7, 2017 at 9:04 AM, Shrinivas Moorthi <
>>>>> shrinivas.moorthi at noaa.gov> 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 listNcep.list.nems.announce at lstsrv.ncep.noaa.govhttps://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 <%28301%29%20683-3718>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ncep.list.nems.announce mailing list Ncep.list.nems.announce at lstsrv
>>>>>> .ncep.noaa.gov https://www.lstsrv.ncep.noaa.g
>>>>>> ov/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.g
>>>>> ov/mailman/listinfo/ncep.list.nems.announce
>>>>
>>>> _______________________________________________
>>> Ncep.list.nems.announce mailing listNcep.list.nems.announce at lstsrv.ncep.noaa.govhttps://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
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.lstsrv.ncep.noaa.gov/pipermail/ncep.list.nems.announce/attachments/20170207/4e49de2a/attachment-0001.html 