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

[Eugene Mirvis]

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.
>>
>>
>