[mpas-developers] Restructuring high-level MPAS driver

[Michael Duda]

Hi, Phil.

Points well taken, and I'd agree that it would be much better to
avoid generic names to begin with. I suppose my point regarding
the "use, only" clause is that we probably don't need to worry
about having lower-level infrastructure routines (e.g.,
dmpar_bcast_int) conflict with routines from outside MPAS, since
code that uses the top-level MPAS routines should never have
inherited access to lower-level routines to begin with. 

I'd also agree that it would be best to come up with a set of
guidelines now and adhere to them from the start rather than have
to re-work large amounts of code later.

With the way that our current build system links MPAS cores in
with the framework and driver, I think we'd need to more carefully
consider renaming the core-specific init/run/finalize routines (as
well as the main core module itself). I'd have no objection to
renaming the init, run, and finalize routines for the framework,
core, and subdriver modules now in my set of proposed changes,
though I'd also not feel uncomfortable in commiting the changes as
they are and addressing the naming convention in the near future.

All: What do you think of renaming init, run, and finalize
routines in the main framwork, core, and subdriver modules?

Cheers,
Michael


On Fri, Oct 29, 2010 at 12:50:27PM -0600, Jones, Philip W wrote:
> 
> Michael,
> 
> The use...only approach is ok and I think CAM/CCSM uses this a lot, but in my experience it often results in cluttered code and can confuse automated dependency generators.
> 
> In POP, we always used the private statement at the top of every module to enforce encapsulation and that worked pretty well.  That also helped in making, say, generic routine interfaces public, while the specific instantiations remained private.  And we had to add the POP_ prefix when CCSM went from a multiple executable model to a subroutinized coupler, so I've been through that before.
> 
> I guess I'm not a huge fan of the renaming/aliasing on the use...only line, again because it often causes confusion when you're trying to track something down.
> 
> However, I'm not a hard-core advocate of any particular approach and there are always exceptions to every rule.  If we can come up with good design practices or guidelines for these issues, I think we're fine.  Just pointing out that we will encounter some of these in the not-so-distant future and it might be good to come up with some of these guidelines now so that we can implement as we go rather than coming into a coupler and having to rewrite it all in a painful, tedious transition later.
> 
> Phil
> 
> On 10/29/10 12:08 PM, "Michael Duda" <duda at ucar.edu> wrote:
> 
> On the issue of naming conflicts, I can certainly see the
> advantage of longer routine names. Another way we might consider
> to address this issue, too, would be to make use of the 'only'
> clause in Fortran use statements to limit the symbols imported by
> a module to just what is needed; in cases of unavoidable conflict,
> there is always the option to do something like
> 
>    use subdriver, only : mpas_model_init => init, mpas_model_run => run
> 
> Another language feature that I've not used much to date, but that
> I've noticed others have begun using, is the 'private' clause;
> this seems like good practice to me, too.
> 
> Cheers,
> Michael
> 
> 
> On Fri, Oct 29, 2010 at 11:40:55AM -0600, Jones, Philip W wrote:
> >
> > Folks,
> >
> > A couple of quick comments.
> >
> > The structure:
> >    call init()
> >     call run()
> >     call finalize()
> >
> > Is certainly consistent with all other component and coupling frameworks, so should ease compatibility.  At some point, you'll probably need to specify arguments for input state, output state, some sort of time interval (for the run method) and returned error codes.
> >
> > Another comment, that I think I've brought up previously, is that the generic names init, run, finalize (and probably others throughout mpas) are at risk for creating namespace conflicts in other components.  It'll be safer in the long run if mpas modules, public variables and public routine names add an mpas_ prefix or other string to reduce the possibility of conflict.  Similarly, there will be cases even within the framework where we will need to distinguish between component models, like MPAS_OcnInit  and MPAS_AtmInit, or something similar.
> >
> > Finally, now that I've recommended making all the names longer with prefixes, I have run into compilers already (Absoft) that are having trouble with some of the long routine names (esp. Xylar's ;^) ).  We will probably need to deal with this at some point for portability.
> >
> > Phil, engaging in drive-by software engineering...
> >
> >
> > ---
> > Correspondence/TSPA/DUSA EARTH
> > ------------------------------------------------------------
> > Philip Jones                                pwjones at lanl.gov
> > Climate, Ocean and Sea Ice Modeling
> > Los Alamos National Laboratory
> > T-3 MS B216                                 Ph: 505-500-2699
> > PO Box 1663                                Fax: 505-665-5926
> > Los Alamos, NM 87545-1663
> >
> >
> >
> > _______________________________________________
> > 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
> 
> 
> Thanks,
> 
> Phil
> 
> ---
> Correspondence/TSPA/DUSA EARTH
> ------------------------------------------------------------
> Philip Jones                                pwjones at lanl.gov
> Climate, Ocean and Sea Ice Modeling
> Los Alamos National Laboratory
> T-3 MS B216                                 Ph: 505-500-2699
> PO Box 1663                                Fax: 505-665-5926
> Los Alamos, NM 87545-1663
> 
> 
> 
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers