Skip to content

Conversation

@rouson
Copy link

@rouson rouson commented Nov 22, 2025

What type of PR is this? (check all applicable)

  • Refactor
  • Feature
  • Bug Fix
  • Optimization
  • Example
  • Documentation

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?

rouson added 30 commits October 3, 2025 17:06
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.
rouson and others added 13 commits October 12, 2025 23:21
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.
* 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
@rouson
Copy link
Author

rouson commented Dec 1, 2025

@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 laplacian branch on my fork that adds tests and adds the Laplacian mimetic operator. I'll be ready to submit a PR that includes those new tests and operator as soon as I can resolve some GitHub Actions glitches.

@joehellmersNOAA
Copy link
Collaborator

joehellmersNOAA commented Dec 2, 2025

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?

test/gradient_operator_test_m.F90:61:46:

   61 |         test_diagnosis = .all. (grad_f%values() .approximates. df_dx_exact .within. tolerance)
      |                                              1
Error: Component ‘values’ at (1) is a PRIVATE component of ‘__vtype_face_values_m_Gradient_t’
compilation terminated due to -fmax-errors=1.
<ERROR> Compilation failed for object " test_gradient_operator_test_m.F90.o "
<ERROR> stopping due to failed compilation
STOP 1
jlhellmers@dev-mole:~/github/csrc-sdsu/mole$ gfortran --version
GNU Fortran (Ubuntu 15.2.0-4ubuntu4) 15.2.0

@joehellmersNOAA
Copy link
Collaborator

nvm, I see the problem. I can't really try this until we merge from your fork.

@joehellmersNOAA joehellmersNOAA self-assigned this Dec 2, 2025
@joehellmersNOAA joehellmersNOAA merged commit f109f4c into csrc-sdsu:dev/fortran Dec 2, 2025
31 checks passed
@rouson
Copy link
Author

rouson commented Dec 2, 2025

@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.

@joehellmersNOAA
Copy link
Collaborator

@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.

@rouson rouson deleted the dev/fortran branch December 4, 2025 22:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants