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

Michael Duda duda at ucar.edu
Tue May 4 15:35:28 MDT 2010


Hi, Todd.

Nice work on the branch update. I checked out the new
lateral_boundary_conditions branch and compared with with the copy
that I had merged using the tool from CGD, and everything matches
except for the top-level Makefile (EXPAND_LEVELS is commented) and
the namelist.input.ocean file. The new experience with merging
branches should certainly make our lives easier in future.

I think we may need to use the svn option --reintegrate when
adding changes from a branch back into the trunk, according to the
svn documentation at the bottom of p.93 here:
http://svnbook.red-bean.com/en/1.5/svn-book.pdf Perhaps that
option would resolve some of the tree conflicts, which aren't
actually conflicts?

In any case, assuming we get identical results from the sw and
hyd_atmos cores, I'd be fine with merging the branch changes back
into the trunk.

Cheers,
Michael


On Tue, May 04, 2010 at 02:43:23PM -0600, Todd Ringler wrote:
> 
> 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
> 


More information about the mpas-developers mailing list