I’m the author of a tensor toolbox adtzlr/ttb hosted on GitHub. It is designed to be used in FEA packages in their user material subroutine codes to make tensor operations easier.
The repo got some interest over the last few years. The thing is that my Fortran coding skills are limited by the usage inside these FEA subroutines (like most of the users of this toolbox).
I’d be happy if anyone with an interest in that topic could have a look at the code and give some feedback and/or small enhancements directly as issues / pull requests. I’m open to move the code to an organizational account on GitHub to make collaboration easier and to ensure future development.
In addition to @certik recommendations I would change the filename suffix of all the included files from .f to .finc to clarify they are INCLUDE files except for the one file defining the Tensor file.
Combining those suggestions into a pull request that demonstrates what that looks like…
The aux directory contains a single-file fpm.F90 file. Just use
cd aux/
gfortran fpm.F90 -o fpm
and move fpm to be in your command search path and you should be able to go to the head directory of the project and enter:
fpm build
or
cd src
make
I tried to make the Makefile fit a generic basic fpm(1) layout. If you put example programs into the example/ directory and tests into test/ it will hopefully automatically build the same files as fpm; but I did not add any tests or examples to try that. Do you use ford(1) or doxygen(1) for developer documentation (or user documentation)?
Use or discard as you please, but hopefully that will get you to a point where it is more easily used and maintained by your community.
If you like fpm the web page for fpm has instructions on full installs; after which you probably want to delete the aux/ directory.
I would suggest the module have a PRIVATE statement added, and then explicitly make the user API visible via adding PUBLIC statements and attributes as another change.
For maintainability, particularly if you want to attract contributions you want to add a set of test programs, as previously mentioned.
With a good set of tests in place you can just add a CD/CI script that does
an “fpm test” and you will get automatic unit testing, which is really nice when integrated with platforms like github.
I however have also moved all the routines into modules + moving things towards free form. I might add CMake so that this project can be built by cmake apps!
I see. You eliminated the use of INCLUDE, which is a nice approach but means the OPs current method of using an INCLUDE in the user-supplied code will not work, but makes for a cleaner approach when the code is used conventionally via the loader instead of by an INCLUDE and rebuild each time. Long-term that does seem like a good idea and makes it so the user code can be free or fixed form. Mine of course does not have to use the INCLUDE in the user code either, it just left it as an option for free-format user code. Probably better to get away from using INCLUDE altogether.
Although it goes against the initial design, this should make it nicer to interface with any library without having to think about free or fixed. Additionally, if we continue it should be very easy to include via fpm dependencies
I am currently fixing up some warnings from the compiler. I’ve added cmake now
@adtzlr my PR will introduce breaking changes to applications that use the library. Since I’ve moved from include files to modules for each portion of the library.
This should be nicer for software dev purposes, but users will need to change their recipes to use this new state of the library. In reality it should be pretty simple to do so but it is something that will happen. If you do releases, this would be a change in version number.
I mostly agree that removing the need for include is cleaner and seems like the sound approach. Now, there is a small caveat. As of now, Fortran does not have a native way of ensuring inlinement. If one wants to garantee procedure inlinement without using flags such as -flto or -ipo project-wide, the include approach is the only poor-mans option we are left with. There might be another way but I haven’t found it yet.
I agree. I should have indicated “in this case” with this code, as I use INCLUDE in maintaining some larger modules myself, although in some cases perhaps I should be using submodules instead.
Thank you all for your support! This is much much more than I expected! All comments, proposed code changes and discussions are very welcome! I’ll come back with a few question once I have gone through the pull requests (in a few days).
It seems I’ve found the right place to ask .
In a commercial FE-package (like Marc HYPELA2, Abaqus UMAT), a subroutine is added in the GUI. It then gets compiled before the simulation model is run. My naive question is: Does this work with free-form modules inside these subroutines? Or do these old-school Fortran codes require fixed-form source files? These packages also require some INCLUDE statements that can’t be avoided. If I get it right, I could avoid it in the tensor module?
.