[mpas-developers] COMMIT CHECK: Branch Merge

Doug Jacobsen jacobsen.douglas at gmail.com
Tue Dec 4 15:22:26 MST 2012


Hi Michael,

Thanks for putting these together. I don't have any issues with using this
setup.

If no one else has any input on this topic I'll commit these two Makefiles
before the merge.

Thanks!
Doug


On Tue, Dec 4, 2012 at 3:03 PM, Michael Duda <duda at ucar.edu> wrote:

> Hi, Doug.
>
> Attached is an example of what I had in mind.  The Makefile and
> Makefile.in.CESM_OCN files contain very little overlap, which should
> relieve most of the burden of applying changes in multiple places.
> In general, I'm not sure we can ever escape the need for updating other
> files when one changes; for example, when changing the interfaces in a
> module, one necessarily has to update all other code that depends on
> that module interface.  However, I do appreciate that it would be much
> more difficult for developers to ensure that changes to the Makefile
> won't break the CESM build of MPAS-O.  We can also hope that at least
> one person will catch such problems at the time the changes are proposed
> for inclusion in the trunk.
>
> I think having Makefiles that are as transparent as possible (without
> multiple layers of "ifeq" statements to mentally apply) should reduce
> the chances of mistakes overall, especially when adding in changes for
> MPAS-A and CAM.
>
> Sticking with CESM, rather than COUPLED, would be fine for us,
> especially with include files used as in the attached makefiles.
>
> Of course, I'm open to other suggestions for dealing with different
> builds of MPAS-O and MPAS-A (stand-alone and coupled) from the same
> source.
>
> Regards,
> Michael
>
>
> On Tue, Dec 04, 2012 at 12:23:41PM -0700, Doug Jacobsen wrote:
> > Hey Michael,
> >
> > Just to clarify. Do you want to have a copy of the entire makefile in
> > Makefile.in.CESM_OCN, just without the ifeq's for CESM?
> >
> > The only problem I would have with this is the amount of effort to
> maintain
> > all of the makefile we would need. Even with two, I think it's going to
> be
> > difficult for developers to remember to updated both Makefile and
> > Makefile.in.CESM_OCN when they make some change to Makefile.
> >
> > Other than that issue, I don't see a reason that it couldn't happen like
> > that. I don't really have a strong preference either way.
> >
> > With regards to working with CAM, would you guys prefer to have the flag
> be
> > COUPLED rather than CESM?
> >
> > Thanks for the comments,
> > Doug
> >
> >
> > On Tue, Dec 4, 2012 at 12:04 PM, Michael Duda <duda at ucar.edu> wrote:
> >
> > > Hi, Doug.
> > >
> > > Since this will affect everyone, including our work here to implement
> > > MPAS-A as a dynamical core in CAM, I thought I'd bring this up with the
> > > larger group.  The Makefile in the src directory (i.e., src/Makefile)
> of
> > > the branch is looking a bit tangled to me with all of the "ifeq"
> > > statements.  As a potential solution, I'm wondering whether we could
> > > make use of include files, so src/Makefile looks something like:
> > >
> > >
> > > ifeq "$(CESM)" "true"
> > >
> > > include Makefile.in.CESM_OCN
> > >
> > > else
> > >
> > >    #
> > >    # Current contents of the Makefile
> > >    #
> > >
> > > endif
> > >
> > >
> > > This would allow us the flexibility to do whatever we need to for
> MPAS-O
> > > and MPAS-A, while still keeping the Makefile for a stand-alone build
> > > looking clean. I'd imagined that, when building the MPAS-A dycore
> within
> > > CAM, we could add a little extra logic:
> > >
> > >
> > > ifeq "$(CESM)" "true"
> > >
> > > ifeq "$(CORE)" "ocean"
> > > include Makefile.in.CESM_OCN
> > > endif
> > >
> > > ifeq "$(CORE)" "nhyd_atmos"
> > > include Makefile.in.CESM_ATM
> > > endif
> > >
> > > else
> > >
> > >    #
> > >    # Current contents of the Makefile
> > >    #
> > >
> > > endif
> > >
> > >
> > > Does this sound like a potentially viable approach? I think that
> > > splitting out the specifics for CESM and CAM builds could make it
> easier
> > > for other developers (and future users, potentially) to follow the
> build
> > > sequence and dependencies.
> > >
> > > Regards,
> > > Michael
> > >
> > >
> > > On Mon, Dec 03, 2012 at 01:25:19PM -0700, Doug Jacobsen wrote:
> > > > Hello All,
> > > >
> > > > I have been working recently on coupling MPAS-O to CESM. I currently
> have
> > > > it setup to where MPAS build's in a suitable method for CESM, and the
> > > Ocean
> > > > model can run within CESM (without being forced).
> > > >
> > > > Several changes were made that were needed to be able to have MPAS
> build
> > > > properly for inclusion in to CESM. I want to merge the branch I have
> been
> > > > working under to the trunk before putting more work on the forcing
> side.
> > > > This way, we have a checkpoint on the trunk of a working version of
> MPAS
> > > > with the CESM.
> > > >
> > > > Also, I think I won't need to make any more changes to the shared
> areas
> > > of
> > > > MPAS after this commit.
> > > >
> > > > The branch in question is branches/ocean_projects/cesm_coupling. I'll
> > > > commit it on Wednesday if I don't hear anything about it, but any
> > > questions
> > > > or comments are welcome.
> > > >
> > > > Thanks!
> > > > Doug
> > >
> > > > _______________________________________________
> > > > mpas-developers mailing list
> > > > mpas-developers at mailman.ucar.edu
> > > > http://mailman.ucar.edu/mailman/listinfo/mpas-developers
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20121204/41676d6a/attachment-0001.html 


More information about the mpas-developers mailing list