search

msg-byu / enumlib

Derivative structure enumeration library
MIT License
59 stars 34 forks source link

Is it possible to tell which version of enumlib a given enum.x binary is? #89

Closed mkhorton closed 5 years ago

mkhorton commented 5 years ago

Something along the lines of enum.x --version for example.

Thank you!

glwhart commented 5 years ago

I don't know a proper way to do this in fortran. Do you? We could have enum print a version number in the output, but that is not bulletproof either, as it relies on the programmer to remember to update a hardwired version number.

glwhart commented 5 years ago

I'm going to close this. Let me know if you have input though and we can look at it again.

mkhorton commented 5 years ago

I'm not a Fortran developer myself but I have been asking around. I see two options:

  1. Either use an argument parser library (several exist, as far as I can tell in-built support didn't happen until Fortran 2003 so a library would be necessary)

  2. Do as you suggest and add it to the output file, or even write a custom input file to request the version

The latter seems easiest to implement to me. Either way, the programmer would have to remember to update the version number on a new release, but this seems no more of a burden than updating the HISTORY.md file.

To clarify why this is important, we're potentially running tens of thousands of calculations using enumlib (thank you for making this possible!) but if we can't store which version of enumlib we're using it becomes difficult to store calculation provenance, to make sure we can reproduce exactly the output of an old calculation. Given that we often use shared resources, and the version of enumlib installed might not have been compiled by the person using it, it's not always clear what version we're using.

glwhart commented 5 years ago

OK, would you be OK if the version number was a separate file? (I don't really want to mess with the format of the output file. That could potentially break too many things.)

We used to do this back in the day when the code was on svn instead of github. The makefile would automatically write out a version number file.

mkhorton commented 5 years ago

Absolutely, I think putting it as a separate file makes a lot of sense. I also would prefer not to change our code that parses the outputs.

On the svn topic, I think it's possible to add a file to the Makefile that would get the current git commit as the version number, for example see https://stackoverflow.com/a/12368262

glwhart commented 5 years ago

Matthew, I've been looking into a good way (meaning a way that reflects good software engineering practice) to do this. Modern fortran (say 2003 standard) has plenty of ways to access command line arguments, environmental variables, etc. Also, the makefile could automatically run git to get a string that reflects the current version, etc.

But none of this does any good unless 1) the version that is written truly reflects the version that is being run (this is an argument against relying on the developer to remember to update a version number in the source code, say), and 2) the person running enum.x remembers to pass the --version flag when running the code (maybe this is easy if you always run in a script but...).

It seems to me that the best thing would be this. Everytime the subroutine gen_multilattice_derivatives is called, a file is written (e.g., VERSION.enum or something). The content of this file is a single line reflecting the output of something like git describe --tags --dirty --abbrev=4. In order for this to work, the makefile needs to dynamically change the f90 file at compile time. I'm (pretty) sure I could figure out a sed command or something that could run inside the makefile to do this.

Does this sound kludgy? Any better ideas? I think this is basically what we were doing years ago with the svn repo but I don't remember completely.

glwhart commented 5 years ago

I've push a proposed solution to my own branch glwhart. Can you take a look and give feedback?

mkhorton commented 5 years ago

Hi Gus, happy to take a look but I can't find that branch, either on this repository or on your fork? Was it pushed remotely?

glwhart commented 5 years ago

@mkhorton Sorry. Apparently I never pushed. Try it now. My fork is at https://github.com/glwhart/enumlib

mkhorton commented 5 years ago

This seems perfect! Can confirm it works, and seems to be a good solution.

glwhart commented 5 years ago

Super. If you have suggestions for improvements as you start to rely on this new functionality, please let me know. This version stamping will be useful for us too.

Closing this until you have further suggestions. Thanks for your patience. Getting the compare code to work was a monumental effort, not the software part but developing the right mathematics. Glad Rod and I figured it out. To a while though.