Trixi.jl icon indicating copy to clipboard operation
Trixi.jl copied to clipboard

Published 20 hours ago • verified publisher icon trixi-framework

Parallelization docs should mention specific versions of P4est/T8code

Open jlchan opened this issue 1 year ago • 4 comments

When building P4est/T8code against system MPI, we should probably suggest building the specific versions of each library which are built by Yggdrasil. We ran into some issues related to the C/C++ interface being inconsistent with the interfaces used by T8code.jl.

jlchan avatar Oct 16 '23 22:10 jlchan

Good point! However, I don't understand how the C++ interface being inconsistent plays a role here, since Julia should only be using the C interface.

Futhermore, do you have a specific example of where the t8code API changed in a non-backwards compatible way? If yes, we should report this upstream and inform them that this is not in line with semantic versioning - i.e., a public API function should not change in an incompatible way unless the major version is increased.

sloede avatar Oct 17 '23 12:10 sloede

I forgot that Julia only uses the C interface - thanks!

I can't remember precisely which function changed, but I think it had to do with a function definition that was moved to header files...and that maybe messed things up? @apey236 do you and Raj have a recording of our debugging session with @jmark? We could look it up then.

jlchan avatar Oct 17 '23 12:10 jlchan

t8code did not break with the semantic versioning convention. I think, what happened here is that Jesse's folks tried to link T8code.jl with an externally compiled t8code library. While the former is still "stuck" with t8code version 1.2 the latter was compiled with the latest pull from the repo and/or the latest t8code release tarball (v1.5). The interface from v1.2 to v1.5 changed considerably.

jmark avatar Oct 17 '23 13:10 jmark

Hm, maybe I don't fully understand the root cause then. I thought that since T8code.jl provides Julia bindings to a given C API version of t8code, it should be compatible with later, non-breaking versions of this C API. Since you said that the interface chaged from v1.2 to v1.5, isn't that then a non-backwards compatible change?

Anyhow, I am just wondering. It does not change the fact that adding a statement to the docs that makes people aware of this issue would be helpful 👍

sloede avatar Oct 18 '23 13:10 sloede