Rename module names, e.g. "precision_module" -> "precision"

[certik]

I think the _module in all modules name is redundant. I propose to rename:
solution_module -> solution
solver_module -> solver
precision_module -> precision
controller_module -> controller
geometry_module -> geometry

It's easier to type and consistent with other module names. Just like in Python, you also don't append _module to Python module names.

If you agree, I'll send a PR.

[mandli]

Although it is verbose, I usually try to do this for two reasons (really one):

1. The source files are named *_module.f90 to distinguish these from source files that do not contain modules
2. Since it seems good practice to enforce the source file name and the actual module name to match, item 1 implies that these should remain as they are.

[certik]

I agree that files + module names must agree. My proposal is to rename both modules and the files.

As far as your point 1., there really should not be any files that are not modules in modern Fortran. As such, until we fix this problem, maybe we can rename files that only contain a raw subroutine to something like evolve_to_time_func.f90. If it doesn't have _func then it is a Fortran module. That way, the correct usage is naturally encouraged, and eventually we'll get rid of all files that have _func in their name.

[ketch]

I vote for removing _module and not adding _func. It will be more consistent with the python code and easier to see what's in a directory. Is there really a reason why one needs to know without opening the file whether it is a module or just a subroutine?

On Mon, Jul 15, 2013 at 8:05 PM, Ondøej Èertík <notifications@github.commailto:notifications@github.com> wrote:

I agree that files + module names must agree. My proposal is to rename both modules and the files.

As far as your point 1., there really should not be any files that are not modules in modern Fortran. As such, until we fix this problem, maybe we can rename files that only contain a raw subroutine to something like evolve_to_time_func.f90. If it doesn't have _func then it is a Fortran module. That way, the correct usage is naturally encouraged, and eventually we'll get rid of all files that have _func in their name.

Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-20984157.

---

This message and its contents including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email.

[certik]

If my vote counts, I also vote for @ketch's proposal.

[mandli]

Good point on the "everything in modules". I say we adopt @ketch's proposal as well.

[rjleveque]

This may the right way to go for the future, but I'll note that in amrclaw and geoclaw there are many files and only a few modules, and this probably won't change right away.

Also, in the Makefiles we added a MODULES list of modules from the libraries that have to be compiled before other routines, the ones that are "used" in various other routines. Most of the other files, if turned into modules, would not have this property. I recall we had major problems with getting the code to use the .mod file from the right directory and to store it in the library if the code was compiled from an application directory.

How do you propose handling this in the future?

[certik]

@rjleveque --- I think a major part of your comment is how to handle dependency issues of Fortran modules. This is handled automatically by CMake, so I have contributed optional CMake build system (#6). It also handles using the right .mod files and so on. So as far as I know, there is no issue when using CMake, and my recommendation would be to simply use it (it's a widely used and supported build system).

However, I understand that maybe you might not want to use CMake. Then you have to handle the module dependencies yourself. The method that I use is to tell Makefile the dependencies, and then just compile things together. Here is an example of what I used in the past:

https://github.com/certik/dftatom/blob/master/src/Makefile.manual

as you can see, the makefile is really simple. The dependencies at the bottom were generated automatically, though I forgot at how I did it, but we can write a simple script to do that. Btw, this particular project also uses CMake (e.g. https://github.com/certik/dftatom/blob/master/src/CMakeLists.txt), so the user can use both.

Given this, I think that can be a solution to all points that you raised.

[rjleveque]

Sorry, I wasn't following the CMake thread... I'll take a look at this.

Thanks!

[certik]

There is not much in that thread --- I just persuaded Kyle to put CMake in, as I think it's a good solution. But it's completely optional, you can simply ignore the CMake files.

[mjberger]

I'll have to look at cmake too to see if that solves the module issue, but I vote for keeping module in the names. The usual make system often fails with modules in the wrong place, made by a different compiler, etc. so pointing them out explicitly is 'very' useful.

How common is cmake right now? Do all users have it? By the way, consistency with python is also an issue. I have 3 python installations on my desktop, some work, some don't.

[mandli]

My experience is that CMake has not become ubiquitous as in that every user has it on their machine but it is easy to install via package managers or by installer. CMake is one of the best (and only) build tools that I have seen that understands Fortran module files.

The Python compatibility is not really an issue in regards to the Fortran. The multiple versions problem has a variety of good solutions at this point that we can maybe put some documentation together on.

[certik]

Just a note to @rjleveque's remark about currently having lots of global subroutines (outside of modules), the PR #16 is adding interfaces to all global subroutines, so that there are no more implicit interfaces and thus no more compiler warnings. Every single subroutine then must be imported (=used using Fortran terminology) from somewhere and the compiler checks types. Later, as global subroutines are put into modules, then just the import is changed to whatever module it ends up in.