Closed rs028 closed 1 year ago
Merging #466 (3773227) into master (276a826) will increase coverage by
1.27%
. The diff coverage isn/a
.
@spco Any comments? The idea is to work towards more consistency of the various tools, as well as naming and formatting. I am going to merge this and leave further updates to the manual and readme file for another time.
PS: can the trigger_action_on_PR_merge
branch be deleted?
@spco Any comments? The idea is to work towards more consistency of the various tools, as well as naming and formatting. I am going to merge this and leave further updates to the manual and readme file for another time.
PS: can the
trigger_action_on_PR_merge
branch be deleted?
I've now deleted this too.
Looks like macos
is now up and running again - I've made it a bit more robust in its handling of matrix.os
so we don't have to remember to change it in multiple places.
You're right that macos-12
only supplies gfortran-11
out of the box. My concern is that our GH Actions may swiftly outpace the likely target machine for users - and HPC is far more likely to have gfortran-8 than 11! Perhaps we could consider reinstating the brew install
workaround for macos-12 to install gfortran-9 and gfortran-10? TBH I think brew install
ing gfortran-8
on both would also be quite desirable.
Looks like
macos
is now up and running again - I've made it a bit more robust in its handling ofmatrix.os
so we don't have to remember to change it in multiple places.You're right that
macos-12
only suppliesgfortran-11
out of the box. My concern is that our GH Actions may swiftly outpace the likely target machine for users - and HPC is far more likely to have gfortran-8 than 11! Perhaps we could consider reinstating thebrew install
workaround for macos-12 to install gfortran-9 and gfortran-10? TBH I thinkbrew install
inggfortran-8
on both would also be quite desirable.
this is my concern, and also to keep backwards compatibility but within reason, otherwise it becomes a nightmare to maintain.
I'll have a play around to see what we can do without it indeed becoming a maintenance nightmare!
Ok, I'm going to revert the last few commits and abandon gfortran-8 on either platform for now. The reasons:
(1) on ubuntu, gfortran-8 is no longer in the package managers (minimum supported is 9). The only alternative is to compile from source, which is possible but will take a few minutes of compute time, and I don't have time to get that working right now.
(2) on macOS, for some reason the CVODE install insists that gfortran-8 is not a functioning fortran compiler. It then deactivates the FCMIX
flag, which means that the *_fcvode.a
libraries are not built. It then fails later at the stage of running the atchem2
executable as it can't link to the nonexistent libraries. I'm not sure what would be required to make CVODE think gfortran-8 is functional, so I'll drop that for now too due to time.
So we should end up with ubuntu-22.04, macos-11 and macos-12, all running gfortran-9, 10 and 11.
It would still be desirable to get gfortran-8 running on at least one architecture in future, but not crucial.
Sounds reasonable. And thanks for sorting this out. I will now try to push my last changes and (if you are done) merge this branch.
Yep, I'm all done.
This branch includes a number of minor updates, fixes, tweaks, and corrections made while working on the new Test Suite:
*.md
files..gitignore
files.mcm/mechanism_test.fac
to themodel/
directory and rename it tomechanism.fac
. This seems a more logical location for an example mechanism.version.sh
script toupdate_version_number.sh
.