precice
precice copied to clipboard
precice
Use unsigned sizes in SolverInterface
We currently use int to pass sizes to the SolverInterface.
This makes the interface tedious to use with size_t and thus with the C++ standard containers due to the narrowing conversion from int to size_t.
Also, moving to size_t should future-proof the library for bigger mesh and data sizes.
This requires to add size_t to the communication back-end.
Discussion results:
- We need this at some point
- Linked to #887
-
size_talso works in C -
Integer(C_SIZE_T)in Fortran - Need to implement size_t in Communication
These changes need to propagate down to the entire backend including the global ids, the partitioning, the communication, and possibly IO. They also need to be applied to the C and Fortran bindings.
We could migrate the API to size_t and internally still use int until we have time to extend the back-end.
Types are:
- C++
std::size_t - C
size_t - Fortran 2003
INTEGER(C_SIZE_T) - Python numpy
numpy.uintp
@MakisH Is it a problem to drop support for pre-2003 Fortran versions? Is there an alternative to C_SIZE_T?
@MakisH Is it a problem to drop support for pre-2003 Fortran versions?
On the one hand, codes using Fortran, typically use Fortran 90. On the other hand, I am not aware of any of our adapters or users currently using any Fortran bindings at all. I also don't use Fortran.
(maybe @gdenayer?)
Is there an alternative to C_SIZE_T?
I honestly don't know. It's been a while since the last time I used Fortran.
@MakisH Is it a problem to drop support for pre-2003 Fortran versions?
On the one hand, codes using Fortran, typically use Fortran 90. On the other hand, I am not aware of any of our adapters or users currently using any Fortran bindings at all. I also don't use Fortran.
Hi. You are totally right. Most of the codes using Fortran in mechanics are based on f77 or f90. I only know one team, who rewrite their code from scratch to use modern Fortran.
I started to couple our code (FASTEST but not the version listed in your overview) with preCICE last summer. If you have a version modified with C_SIZE_T I can try to compile and test.
Is there an alternative to C_SIZE_T?
I honestly don't know. It's been a while since the last time I used Fortran.
No idea about that.
The way we implement the Fortran bindings actually doesn't require us to annotate anything in the bindings. The calling code needs to use INTEGER(x) where x = sizeof(size_t).
In the Fortran 2003 module, we would just specify INTEGER(kind=c_size_t).
Meaning this only affects the f90 solverdummy in our repo.
We could use CMake to get the size information.
CHECK_TYPE_SIZE("std::size_t" PRECICE_SIZE_OF_SIZE_T LANGUAGE CXX)
On my system, this is 8.
We would then need to use this as INTEGER(x) size in the solverdummy.
Sadly type aliases are also a Fortran 2003 feature. :sweat_smile:
Discussing in person.
Working on this requires a lot of effort, as Eigen uses internally signed indices. If we find out later, that having this is very relevant, we can still implement it in a (backwards compatible) configurable way
#ifdef PRECICE_WITH_64_BITS
using precice::Index = std::size_t
#else
using precice::Index = Eigen::Index
#endif
or similar.
Postponing this and #887 due to high dev cost, more communication at no direct gain. We can implement this in a backwards-compatible way by duplicating id-specific functions.