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

[Michael Duda]

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
>