-
Notifications
You must be signed in to change notification settings - Fork 63
Dev/fortran #238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dev/fortran #238
Conversation
This commit 1. Synchronizes a conditionally compiled gfortran workaround to match the updated alternative block. 2. Updates the unit test to work around a gfortran issue with `associate`.
This commit fixes issues with the matrix-vector multiplication function "matvec" to ensure infers the loop limits and array section bounds from the dimensions of the arrays accessed by the loop or array section.
This commit adds the ability to convert a mimetic matrix to a
Julienne file_t object so that the matrix elements can be printed
with code like the following
type(mimetic_matrix_t) mimetic_matrix
! define matrix here
associate(file => mimetic_matrix%to_file_t())
call file%write_lines()
end associate
Now all tests pass for computing 1D gradients of 0th, 1st, & 2nd-order polynomials, each with mimetic discretizations of 2nd- and 4th-order accuracy.
This commit adds tests of the ratio of the log of the maximum absolute error for gradients of a sinusoidal function. The tests verify that 2nd- and 4th-order mimetic discretizations converge to the expected gradient values at a rate proportional to dx raised to the 2nd and 4th powers of the error within a tolerance of 5%.
To work around gfortran-14 not supporting `do concurrent` locality specifiers, this commit removes specifiers conditionally via a new macro: HAVE_LOCALITY_SPECIFIER_SUPPORT defined in include/mole-language-support.F90.
Also, always use setup-fpm
This is complicated by the need for a compatible C++ compiler.
Intel provides two docker packages with Intel Fortran:
1. The first is very compact, but lacks Intel C++.
This can be used with GNU C/C++. This *probably* works in
most cases, but might lead to subtle issues if there are
ever ABI differences between the two tool-chains.
2. The second includes Intel C++ and tons of other stuff,
hence is much larger and can lead to slower container load.
However it provides a "pure" Intel toolchain.
The CI scripts are adjusted to allow for either possibility.
Add a few configs of each type.
Gradient operator
* Add the new macos-26 runner * Add a workaround needed for recent snowstep/llvm containers
CI: Fix macos-15-intel, add GFortran-15 coverage on Linux, add macos-26
|
@joehellmers let me know if you'd like to review this or whether it's ok for me to merge it. In addition to the divergence operators implemented and tested in this PR, I now have a downstream |
|
Hey @rouson , sorry the delay. When running on Ubuntu 25.10, GFortran 15.2 I'm getting the message below. I know at one point we talked about using GFortran 14.x, or Flang. Should I be using a different compiler? |
|
nvm, I see the problem. I can't really try this until we merge from your fork. |
|
@joehellmersNOAA sorry about that. Hopefully the merge did the trick for you. I see that all 31 checks in the PR passed, including tests with the referenced compiler versions. For future reference, it should also be possible to fetch the branch from my fork and test that without merging. I'm happy to help with that if you like. |
No need for that. As long as we have a separate branch for Fortran development we should be fine. I just forgot you are operating on your own fork. I usually do the same. |
What type of PR is this? (check all applicable)
Description
CI: Fix macos-15-intel and add GFortran-15 coverage on Linux
[optional] What gif best describes this PR or how it makes you feel?