Hi all,
As discussed earlier (and originally proposed by @xevra if memory serves), it would be a worthwhile effort to update evolv2 to use modern Fortran. This is a nontrivial effort due to the size & complexity of the file, but the potential to save developer time in debugging / crashes could be huge. I'd like to coordinate this with @xevra and other people who are interested.
I am currently trying this on my fork and will push some commits soon. Ideally I'd like to select a bunch of binaries and test by being able to reproduce them with the rewritten subroutine. This would not necessarily require rewriting the other (hrdiag/comenv/etc.) subroutines, but they will have to be updated to get state from the new module rather than a common block.
This would ameliorate the following issues:
- The odds of getting stuck in GOTO loops will be reduced (but a few might remain in other subroutines)
- common blocks will be obsoleted and replaced with the module system
- code will become much more readable, with longer line lengths
- potential for better logging capability
Other potential advantages that come to mind:
- Using constants to denote flags for better readability (e.g.
kickflag == disberg_25 instead of kickflag == 5)
- standardized variable names (e.g. clear core mass names
massc_he / massc_co )
- we can probably make the file shorter!
Hi all,
As discussed earlier (and originally proposed by @xevra if memory serves), it would be a worthwhile effort to update
evolv2to use modern Fortran. This is a nontrivial effort due to the size & complexity of the file, but the potential to save developer time in debugging / crashes could be huge. I'd like to coordinate this with @xevra and other people who are interested.I am currently trying this on my fork and will push some commits soon. Ideally I'd like to select a bunch of binaries and test by being able to reproduce them with the rewritten subroutine. This would not necessarily require rewriting the other (
hrdiag/comenv/etc.) subroutines, but they will have to be updated to get state from the new module rather than a common block.This would ameliorate the following issues:
Other potential advantages that come to mind:
kickflag == disberg_25instead ofkickflag == 5)massc_he/massc_co)