Hi Michael,<div><br></div><div>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).</div>
<div><br></div><div>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.</div><div>module_OcnTracerHmix.F</div><div><br></div>
<div>Using your example, I could transform this to</div><div>module_ocn_tracer_hmix.F</div><div>or</div><div>mpas_ocn_tracer_hmix.F</div><div><br></div><div>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.</div>
<div><br></div><div>Do you have any preference in terms of format for filenames? We could use the examples above to say something like</div><div>[model]_[core_abbreviate]_[module_type].F</div><div>as a format, where the [module_type] field could be left ambiguous. </div>
<div><br></div><div>Thanks,</div><div>Doug</div><div><br><div class="gmail_quote">On Mon, Sep 19, 2011 at 3:54 PM, Michael Duda <span dir="ltr"><<a href="mailto:duda@ucar.edu">duda@ucar.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi, Doug.<br>
<br>
I'd certainly agree that adding the prefix 'mpas' to modules would be a<br>
good idea -- both to the module and file name -- especially as we begin to<br>
use the MPAS cores outside of the MPAS framework. On the topic of ensuring<br>
there are no namespace collisions between MPAS and other codes, perhaps we<br>
should also consider namespace collisions between different cores within<br>
MPAS itself; it seems at least within the realm of possibility that we'd<br>
like to couple the MPAS ocean and atmosphere cores with our own coupler at<br>
some point, in which case, we'd need to have distinct names for all modules<br>
in both cores. Should we consider adding some unique prefix to modules that<br>
are specific to one core, e.g., module_mpas_ocn_core and module_mpas_atm_nh_core?<br>
<br>
When it comes to the 'module_' prefix on file names, I'm not strongly<br>
opposed to removing this prefix; however, unless filenames become too long,<br>
I think retaining it doesn't cause undue burden. While our MPAS source<br>
files almost universally contain modules at present, I think it's a nice<br>
feature of a code to be able to tell which files contain modules and which<br>
don't just from a directory listing: I like that module_mpas_timekeeping.F<br>
contains the mpas_timekeeping module. Then again, I can't say that I've<br>
ever create a file named class_Foo.cxx in C++ for a class named Foo!<br>
The 'module_' prefix probably originated from my personal preference (shaped<br>
by WRF, no doubt), so I'd ultimately have no problem with removing the prefix<br>
if others have a distinct preference for doing so (and especially if we<br>
would end up with long filenames like module_mpas_ocn_time_integration.F).<br>
<br>
Cheers,<br>
Michael<br>
<div><div></div><div class="h5"><br>
<br>
On Wed, Sep 14, 2011 at 02:16:40PM -0600, Doug Jacobsen wrote:<br>
> Hello All,<br>
><br>
> While I am working on making the ocean core's module_time_integration.F more<br>
> modular another proposed change has come up that I wanted to get some<br>
> feedback from other developers on. We have discussed the naming of modules,<br>
> and come up with a proposal to change module names from having the prefix<br>
> module_ to having the prefix mpas_. There are two motivations to this<br>
> change, the first being that module_ doesn't really add any new information<br>
> since we already know that each file contains a module. The second<br>
> motivation is that the switch to mpas_ help reduce the potential of<br>
> namespace conflicts, since it doesn't make sense for other model to have the<br>
> mpas_ prefix.<br>
><br>
> I am bringing this proposal to all of the developers because it is a change<br>
> that we might want to have made across all mpas cores, and some people might<br>
> have comments or concerns on this change. So, please let me know if anyone<br>
> has any opinions on the issue.<br>
><br>
> Thanks!<br>
><br>
> Doug<br>
<br>
</div></div>> _______________________________________________<br>
> mpas-developers mailing list<br>
> <a href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br>
> <a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
<br>
</blockquote></div><br></div>