[Ncep.list.nems.announce] Standalone version of NMMB code

[Dusan Jovic]

Eugene,

  All of the files we are going to move from phys and share directories 
to nmmb project are specific to nmmb and are only used by nmmb. So other 
components (including gfs) will not be impacted at all. There are small 
number of files that are shared between nmmb and gfs and those dozen or 
so files will be copied and we will keep them synchronized with the 
NEMSLegacy trunk. Those files are not changed that often anyway. As soon 
as you make physics project we'll delete these files and start to use 
other means of linking NMMB executable with them, either via 
svn:external link if the future physics project provides convenient way 
of incorporating it's build system with our configure/compile scripts or 
via pre-build library archive (.a).

Dusan



On 05/26/2016 08:37 PM, Eugene Mirvis wrote:
> Hi Dusan,
>
> Yes, I do. You just said : " ... Which means we do not have a way of 
> testing the nmmb top of trunk..."  - that's what I've commented on, 
> that it is a way.
> Now you're saying:"... By using specific revision we can have more 
> frequent commits to the nmmb trunk...". OK. This is a way of the 
> current layout.  Isn't it?
> Nevertheless, it would make no difference  what kind or shape the 
> NEMS/component code is restructured (libs or source)- we'll always 
> have a dilemma with multi-project trunk gaps.
>
> Now, I had a chance to look at your "standalone" set. Of course, if 
> the NMMB team has decided to take from the current NEMS structure a 
> subset of  ~55 files and 2 dirs:
> inside of the NMM directory ("standalone") and to build an executable 
> based on NMMB.F90 we'll need to know Mark's take on that.  I think, 
> temporary, it's OK, if it's more convenient for your development (BTW, 
> I can see some disadvantages too). But if you want to have NEMS users 
> community to refer to this extended NMM set during other NEMS 
> components/framework development process, that's different.  Please 
> clarify.
>
> -Eugene
>
>
>
> On 5/26/2016 4:28 PM, Dusan Jovic wrote:
>> Eugine,
>>
>>  Yes, that's possible. But that will require us to run full NEMS 
>> regression test (with potentially many coupled runs) every time we 
>> want to make commit to the nmmb trunk. By using specific revision we 
>> can have more frequent commits to the nmmb trunk and then once in a 
>> while make sure NEMSLegacy is working (passes full regression test) 
>> and reset svn:external pointer to a newer nmmb revision, which, I 
>> hope you agree, is much more flexible and easier way to work with 
>> multiple repositories.
>>
>> Dusan
>>
>>
>> On 05/26/2016 04:18 PM, Eugene Mirvis wrote:
>>> Hi Dusan,
>>>
>>> If you will checkout top-of-nmmb_trunk & edit external prop @ 
>>> nems/src/atmos to appoint to the top nmmb trunk you should be able 
>>> to test that revision.
>>> Any time you want. Why not?
>>>
>>> -Eugene
>>>
>>> On 5/26/2016 3:18 PM, Dusan Jovic wrote:
>>>>    As you are all aware, after the Gerhard's 'big merge' commit 
>>>> recently,
>>>> the nmmb code is now located in separate subversion project on emc's
>>>> server. It contains what used to be located in src/atmos/nmm directory
>>>> before the merge. The svn external property has been added to the
>>>> NEMSLegacy to checkout nmmb trunk (specific revision number not the 
>>>> top
>>>> of the trunk) under src/atmos/nmmb directory. As a consequence, the
>>>> regression test in NEMSLegacy will never run regression test using the
>>>> current top of the nmmb trunk. Which means we do not have a way of
>>>> testing the nmmb top of trunk.
>>>
>>>
>>
>
>