Add Fortran elastic-tube-1d solvers (precice Fortran module) #607
Conversation
…nsistent precision
There was a problem hiding this comment.
Hi @YonatanGM,
wearing my preCICE hat here 🤠 (it is a bit unfortunate that I am also supervising your SSE project, maybe @fsimonis can control my conflict of interest).
With a first look, I think we could keep both contributions, since we support both ways of using preCICE via Fortran. Let's start with this one, and at the same time port any changes to the other one as well (should not be too many). Not sure yet how we could reduce duplication, but I have the impression the simplest would be to keep both, in different directories (fluid-fortran and fluid-fortran-module).
I had a first look and I ran the code, mixing languages to check for potential incompatibilities. I arrive at the same results.
In terms of the solver source code, I have only reviewed the FluidComputeSolution.f90 so far, as well as the shell scripts and CMakeLists.txt. I will check the rest of the Fortran files during the day.
| @@ -0,0 +1,30 @@ | |||
| cmake_minimum_required(VERSION 3.10) | |||
| project(ElasticTube LANGUAGES Fortran C) | |||
There was a problem hiding this comment.
Just curious (I don't know): why is the C required here?
| cmake_minimum_required(VERSION 3.10) | ||
| project(ElasticTube LANGUAGES Fortran C) | ||
|
|
||
| set(CMAKE_Fortran_STANDARD 2003) |
There was a problem hiding this comment.
Does the variable CMAKE_Fortran_STANDARD exist or do anything?
From this CMake issue, I understand that setting Fortran standards is not intrinsically supported by CMake at the moment.
If removed, don't forget to also apply this (and any further changes) to the solid-fortran/CMakeLists.txt and in the other PR.
| if [ ! -f src/precice.f90 ]; then | ||
| echo "Fetching precice.f90 (Module for Fortran bindings of preCICE)..." | ||
| curl -o src/precice.f90 https://raw.githubusercontent.com/precice/fortran-module/master/precice.f90 | ||
| fi |
There was a problem hiding this comment.
I think this step is fine, given that it first checks if the file exists, so one could skip it (we need to document this in a fluid-fortran/README.md, though).
However, what was your motivation for getting the source file, instead of linking to the module, as we do in the example? It is definitely easier for the user, I am just wondering if there are further reasons.
| L = 10.0 | ||
| dx = L/kappa !1.0 / (N * kappa); | ||
|
|
||
| ! result variable |
There was a problem hiding this comment.
Since this info is now (in the Fortran version) far away from where it is used, we need a more descriptive comment.
I would argue that we need a better name in all versions, but let's keep it as-is now, for consistency and to keep things simple.
| ! Compute residuals | ||
| do i = 2, N ! Adjusted for 1-based indexing |
There was a problem hiding this comment.
I have not checked all the indices here, but I looked at several, and it looks consistent with the C++ version. The bounds make sense.
| real(dp), allocatable :: lhs(:, :) | ||
| integer, allocatable :: ipiv(:) | ||
|
|
||
| nlhs = 2*N + 2 |
There was a problem hiding this comment.
There seems to be a mix-up between n and N. Let's use one of the two forms, as at least it helps text finding. The C++ version uses N.
Same with res/Res, lhs/LHS and maybe more.
(Remember: in Fortran, these two are the same variable)
This PR adds Fortran solvers for the elastic-tube-1d case using the fortran module (precice.f90). I also opened PR #606 that doesn't rely on this module.
The
run.shscript downloads precice.f90 from the Fortran module repository to get the latest version and the file gets compiled with the solvers source files using CMake. Since the module is just a wrapper around the precicef functions in the library, which are updated with preCICE release, I imagine it will stay compatible with the precice version used in the solvers (as long as the function names stay consistent)LAPACK is needed for the fluid solver (same as the C++ case). Just run ./run.sh to build and execute via CMake. The plotting scripts (plot-diameter.sh and plot-all.sh) are updated to show results for the Fortran case. The precommit yaml didnt have hooks for Fortran files, so I maunally formatted them using fprettify.
Results look consistent with the other solvers. I checked the VTK output, and the numbers match up to 5 decimal places on the last timestep. Also tested running the fortran case against the other solves and that seems to work fine too.
Checklist:
changelog-entries/<PRnumber>.md.