OSX conda support

[brey]

Dear All,

I have tried to compile the osx conda package based on the recipe in the repo. I have an issue with the following

Unsatisfiable dependencies for platform osx-64: {'aed2-otm', 'gotm-otm', 'med-otm'}

The gotm=6.0.6 package is available, assuming it is the same as gotm-otm but the rest can't be found even for linux. I am curious how it worked with linux.

ping @tomsail

[nicogodet]

These packages are on @tomsail conda repo for linux and mine for windows.

I'm strongly thinking to bundle all vendors inside opentelemac conda package instead of relying on bugged dependencies (libmed is bugged on all plateform, I fail to build with gotm on windows, same for MUMPS etc etc)

[brey]

In my view maintaining a bundle package is not very future proof. Making the whole installation modular with upstream dependencies provided by the original authors themselves is hard work in the beginning (especially convincing/supporting them to do it) but easier to support in the long run.

[tomsail]

100% in line with this @brey. I will open tickets/issues in the respective repos in order to get official support from them.

In the meantime, please remove these 3 packages {'aed2-otm', 'gotm-otm', 'med-otm'} from the meta.yaml and try if the macOS version compiles.

It should be ok, I have kept the minimal version for macOS (without the extra libraries).

[nicogodet]

For MED there is ongoing work.
The main issue is windows support (MPI for MUMPS, Fortran for others).

[nicogodet]

It will be quite easy to have a full build with dependencies on Linux and Intel Mac.

As Telemac does not compile on ARM, new Mac are not supported.

Lot of work for windows.

[tomsail]

Sorry to hear Nicolas. My experience with compiling TELEMAC on Windows is really limited.

Because of mac's new arch and the work needed for Windows, I am thinking that we could wrap this up and have at least a minimal working version of TELEMAC on conda-forge.

Pros:

• TELEMAC package will be fully available and rely only on official dependencies

Cons:

• the full working Linux/Windows versions would still be on our conda-forge channel

(So far this option works for us, as we just need to run Telemac on Linux cluster and Azure droplets, I'll also add custom versions to run TELEMAC on global models)

Then if there is indeed lots of work needed building on Windows dynamically with all extra libraries, I suggest we wait maybe to get support from TELEMAC's main developers. If EDF justifies there is a need for this package, we'll get help from them.

In the meantime we can still provide them a proof-of-concept and justify this need for them.. simply by multiplying the use of it.

ping @sebourban

[sebourban]

In fact TELEMAC compiles on ARM - the chineese have done it. I believe there is just an issue with one of the lib of MASCARET, but we can take it out of that compilation through the config

[nicogodet]

I initiate the work to push on conda-forge https://github.com/nicogodet/staged-recipes/tree/add-opentelemac
https://conda-forge.org/docs/maintainer/adding_pkgs.html#

[tomsail]

Thanks Nico, I'll have a look into the documentation you've sent.
There is quite some work to be done in "matrixing" the opentelemac package so it can be cross-compatible with a lot of other packages.

The more we can make opentelemac cross-compatible, the easier it'll be to download it and use it.

Did we have any news from boris basic and the numpy=1.22 issue?

[sebourban]

The bug on numpy is with numpy (f2py) and not with TELEMAC. Luckily, it now works again on the lastest few version 1.24 or 1.25 and above

[tomsail]

Thanks Seb. I saw the problem (reported here in the forum).
I will try to matrix the versions on linux and give a report if the package compiles < builds < works (API)

I know I already did something similar in the past, but doing it automatically using conda build will give us more traces and help to have a clearer picture of what works and what does not

[sebourban]

https://gitlab.pam-retd.fr/otm/telemac-mascaret/-/compare/7a03aa2af5d39b459c650103cc0ccea95f439c6d...0898127ca26c7961cd75a55c6a0f8ac82ce769b9 for the fix on numpy

[sebourban]

Did you manage to build MED (and HDF5) ?

[tomsail]

No it didn't work.

checking absolute name of <H5public.h>... checking for H5public.h... yes
//$BUILD_PREFIX/include/H5public.h
expr: non-integer argument
configure: error: 
This HDF5 version #define H5_VERS_MAJOR 1.#define H5_VERS_MINOR 14.#define H5_VERS_RELEASE 2 must not be used with med-fichier4.1.1.
The HDF5 library version used by med-fichier4.y.z MUST NOT be > 1.10 and have to be at least HDF5-1.10.2.
DO NOT TRY TO COMPILE med-fichier4.1.1 version with an HDF5 library which would generate an hdf5 file not compliant with HDF5-1.10.z library.
This would BREAK med-fichier compatibility between files with the same revision number !

If you want to reproduce : I implemented a hdf5 branch mirroring from their official repository.

Another problem / limitation that I see with MED is that it adds another constraint on the build i.e. HDF5 < 1.11
which is another obstacle to make the library cross-compatible with other libraries (like eccodes for instance)

[nicogodet]

@tomsail Could you retry with latest libmed from Conda ?
Ref. conda-forge/libmed-feedstock#50

[tomsail]

Tried it, didn't work.. I will open another issue on MED and print the results there.
We are mixing up topics

[tomsail]

@brey I have added a osx branch for you to test.
I'll push more commits in meta.yaml in the coming days for the matrix builds and the cross-compatibility of the package.

So I'd rather keep the version we had before these commits as I know it should compile on macOs.