[Ncep.list.nems.announce] Standalone version of NMMB code
eugene.mirvis at noaa.gov
Fri May 27 15:19:53 UTC 2016
Thanks. It's shouldn't be too complicated for nmm team to sync for phys,
if you target to secure that nmm coupling will use exactly the same
physics modules (I'm unsure how nmm outsiders can easily verify that).
But what about the nems superstructure? How do you want to get in-sync?
On 5/27/2016 9:54 AM, Dusan Jovic wrote:
> 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).
> 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
>> On 5/26/2016 4:28 PM, Dusan Jovic wrote:
>>> 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.
>>> 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?
>>>> On 5/26/2016 3:18 PM, Dusan Jovic wrote:
>>>>> As you are all aware, after the Gerhard's 'big merge' commit
>>>>> 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
>>>>> 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
>>>>> current top of the nmmb trunk. Which means we do not have a way of
>>>>> testing the nmmb top of trunk.
Senior Computational Scientist, IMSG @
Global Climate & Weather Modeling Branch of
NOAA/NCEP Environmental Modeling Center
NCWCP, rm 2183
5830 University Research Ct.
College Park, MD 20740
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ncep.list.nems.announce