[mpas-developers] Proposed change on module names

[Doug Jacobsen]

Hi Michael,

Thanks for the response. I agree with both of the two additions you
mentioned, both using mpas and the core (abbreviation) to avoid potential
namespace conflicts. Perhaps we could come up with a unified name scheme the
name all files similar across all cores, something like all files should
have lowercase names and use underscores (as in the examples you provided).

Currently in my performance branch I have already started implementing the
core addition to the file names, as an example I have files similar to this.
module_OcnTracerHmix.F

Using your example, I could transform this to
module_ocn_tracer_hmix.F
or
mpas_ocn_tracer_hmix.F

I think I would push to remove module_, because it doesn't really tell
anyone anything very useful about the file, aside from it having a module
inside of it and making the name longer. But every file is already a module
so it's nothing really new. I know a few people in the ocean group would
like to remove module_ in favor of the more useful mpas_ as well.

Do you have any preference in terms of format for filenames? We could use
the examples above to say something like
[model]_[core_abbreviate]_[module_type].F
as a format, where the [module_type] field could be left ambiguous.

Thanks,
Doug

On Mon, Sep 19, 2011 at 3:54 PM, Michael Duda <duda at ucar.edu> wrote:

> Hi, Doug.
>
> I'd certainly agree that adding the prefix 'mpas' to modules would be a
> good idea -- both to the module and file name -- especially as we begin to
> use the MPAS cores outside of the MPAS framework. On the topic of ensuring
> there are no namespace collisions between MPAS and other codes, perhaps we
> should also consider namespace collisions between different cores within
> MPAS itself; it seems at least within the realm of possibility that we'd
> like to couple the MPAS ocean and atmosphere cores with our own coupler at
> some point, in which case, we'd need to have distinct names for all modules
> in both cores. Should we consider adding some unique prefix to modules that
> are specific to one core, e.g., module_mpas_ocn_core and
> module_mpas_atm_nh_core?
>
> When it comes to the 'module_' prefix on file names, I'm not strongly
> opposed to removing this prefix; however, unless filenames become too long,
> I think retaining it doesn't cause undue burden. While our MPAS source
> files almost universally contain modules at present, I think it's a nice
> feature of a code to be able to tell which files contain modules and which
> don't just from a directory listing: I like that module_mpas_timekeeping.F
> contains the mpas_timekeeping module. Then again, I can't say that I've
> ever create a file named class_Foo.cxx in C++ for a class named Foo!
> The 'module_' prefix probably originated from my personal preference
> (shaped
> by WRF, no doubt), so I'd ultimately have no problem with removing the
> prefix
> if others have a distinct preference for doing so (and especially if we
> would end up with long filenames like module_mpas_ocn_time_integration.F).
>
> Cheers,
> Michael
>
>
> On Wed, Sep 14, 2011 at 02:16:40PM -0600, Doug Jacobsen wrote:
> > Hello All,
> >
> > While I am working on making the ocean core's module_time_integration.F
> more
> > modular another proposed change has come up that I wanted to get some
> > feedback from other developers on. We have discussed the naming of
> modules,
> > and come up with a proposal to change module names from having the prefix
> > module_ to having the prefix mpas_. There are two motivations to this
> > change, the first being that module_ doesn't really add any new
> information
> > since we already know that each file contains a module. The second
> > motivation is that the switch to mpas_ help reduce the potential of
> > namespace conflicts, since it doesn't make sense for other model to have
> the
> > mpas_ prefix.
> >
> > I am bringing this proposal to all of the developers because it is a
> change
> > that we might want to have made across all mpas cores, and some people
> might
> > have comments or concerns on this change. So, please let me know if
> anyone
> > has any opinions on the issue.
> >
> > 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/20110919/2a056a9f/attachment.html