[mpas-developers] request to merge lateral_boundary branch to the trunk

Tue May 4 14:43:23 MDT 2010

Hi Michael,

After the merge of the trunk to the lateral_boundary_conditions  
branch, I went to the trunk and issued the command

svn merge --dry-run -r 160:HEAD https://svn-mpas-model.cgd.ucar.edu/branches/lateral_boundary_conditions

that resulted in the following:

--- Merging r161 through r243 into '.':
U    src/core_hyd_atmos/module_advection.F
U    src/core_hyd_atmos/module_time_integration.F
U    src/core_sw/Registry
U    src/core_sw/module_time_integration.F
    C src/core_sw/module_vector_reconstruction.F
U    src/registry/gen_inc.c
C    src/core_ocean/module_test_cases.F
C    src/core_ocean/Registry
C    src/core_ocean/module_time_integration.F
    C src/core_ocean/module_vector_reconstruction.F
U    src/framework/module_io_input.F
U    src/framework/module_io_output.F
U    src/framework/module_block_decomp.F
U    src/framework/module_dmpar.F
    C src/operators
C    namelist.input.ocean
Summary of conflicts:
   Text conflicts: 4
   Tree conflicts: 3

There are no conflicts within the framework or within the hyd_atmos.  
The conflicts in the sw model are due to issues with the  
reconstruction being moved into the operators directory (these account  
for all three tree conflicts) -- this is easily fixed. The text  
conflicts in the ocean core are by design, we made some changes to the  
solver.

Mark Petersen will now do the evaluation of the branch code. I expect  
bit-for-bit in the shallow-water model and the hydrostatic core and  
will verify this. I will also clean up the minor conflicts.

Assuming that Mark's evaluation is positive and that I can verify bit- 
for-bit in the sw and hyd cores, is there any reason to delay  
committing this to the trunk sometime later this week?

Cheers,
Todd

On May 4, 2010, at 11:47 AM, Michael Duda wrote:

> Hi, Todd.
>
> On the topic of merging, I think I've learned something here. I had
> been using a tool developed by someone in CGD (at the time) that is
> used by several of the WRF developers, but it's good to know more  
> about
> the merge built into svn.
>
> Your plan sounds good to me -- once you've committed the updates to  
> the
> branch, it should be much simpler to see the differences before  
> merging
> the branch back to the trunk.
>
> Cheers,
> Michael
>
>
> On Tue, May 04, 2010 at 11:31:46AM -0600, Todd Ringler wrote:
>>
>> Hi Michael,
>>
>> Based on some tips from Mark Petersen, I have done an svn merge from
>> the trunk to the lateral boundary branch as
>>
>> svn merge --dry-run -r 160:240
>> https://svn-mpas-model.cgd.ucar.edu/trunk/mpas .     (see what would
>> change)
>> svn merge -r   60:240 https://svn-mpas-model.cgd.ucar.edu/trunk/
>> mpas .  (merge trunk onto branch)
>>
>> (supposedly) this merges the repository at .../trunk/mpas at rev 240
>> (which is the head) onto the branch that was created at rev 160. I am
>> testing this code right now. Note that the "dry-run" option tells us
>> what changes without actually doing the merge.
>>
>> Having not done this before, I am learning as I go -- so suggestions
>> are welcome.
>>
>> Once I think I have the merge done correctly, I will commit the
>> changes to the branch -- at that point we should be able to identify
>> the changes that would occur by merging the branch to the trunk.
>>
>> Cheers,
>> Todd
>>
>>
>>
>> On May 4, 2010, at 11:05 AM, Michael Duda wrote:
>>
>>> Hi, Todd.
>>>
>>> Actually, I've only made minimal changes to the hydrostatic
>>> atmosphere core to handle the 'garbage' cell nCells+1; but, those
>>> changes don't appear to have any negative effects.
>>>
>>> I think one step that could help us in testing would be to bring
>>> the lateral_boundary_conditions up to date with respect to the
>>> trunk, so that the differences in the branch are exactly those we
>>> will be proposing to make to the trunk. I've just started
>>> experimenting with a diff tool yesterday evening, so I could try
>>> to produce a set up updates to the branch that would bring it up
>>> to date, and I could place those updates somewhere accessible to
>>> other developers; if those updates pass inspection, I could commit
>>> them. Does this sound like a reasonable approach?
>>>
>>> Cheers,
>>> Michael
>>>
>>>
>>> On Mon, May 03, 2010 at 04:38:44PM -0600, Todd Ringler wrote:
>>>>
>>>> Hi All,
>>>>
>>>> We have been working on a clean implementation of lateral boundary
>>>> conditions for a while now. Michael and I put together a design and
>>>> requirement document on the top that was circulated for comments.
>>>>
>>>> As near I can tell, we have successfully implemented this design in
>>>> the shallow-water model and in the ocean model. Changes committed  
>>>> by
>>>> Michael lead me to think that the design has also been pushed into
>>>> the
>>>> hydrostatic atmosphere model.
>>>>
>>>> Over the next couple of days Mark Petersen will be doing a review  
>>>> and
>>>> testing of the code under the lateral_boundary_conditions. His  
>>>> focus
>>>> will be on the ocean model component. Over the last couple of weeks
>>>> Mat Maltrud has been testing the shallow-water core with realistic
>>>> boundaries. All of this testing has occurred in "MPI-mode" on
>>>> numerous
>>>> different platforms.
>>>>
>>>> Some of the changes in this design occur under frameworks, so the
>>>> push
>>>> back to the trunk will impact all model components when rebuilt. As
>>>> far as we can tell, these changes are innocuous to those not
>>>> enforcing
>>>> lateral boundary conditions.
>>>>
>>>> A quick comparison of the shallow-water models in the branch and in
>>>> the trunk show agreement out to ~12 digits  after 500 time steps in
>>>> test case #5.
>>>>
>>>> I am asking for suggestions in terms of testing and evaluation. We
>>>> would like to merge this branch with the trunk very soon, but we  
>>>> want
>>>> to be careful not to adversely impact the broader development  
>>>> effort.
>>>>
>>>> Cheers,
>>>> Todd
>>>>
>>>> _______________________________________________
>>>> mpas-developers mailing list
>>>> mpas-developers at mailman.ucar.edu
>>>> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>>> _______________________________________________
>>> mpas-developers mailing list
>>> mpas-developers at mailman.ucar.edu
>>> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>>
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers