NCL executable missing

[bthrasher]

I installed the ncl package on a new MacBook Pro (Apple M1 Pro). The message says the conda-forge/osx-arm64::ncl-6.6.2-h5d9bed2_44 package will be installed, but the actual ncl executable is not in the bin directory or anywhere else from what I can tell. Can someone confirm?

[xylar]

@bthrasher, indeed, I downloaded the OSX-ARM package and the ncl executable seems to be missing. @zklaus, any thoughts? (I know you're busy at EGU...)

[douglowe]

I have the same problem too.

Unfortunately one of the dependencies (xorg-makedepend) is not yet available for OSX-arm64, so I can't build it locally either. Perhaps once that is available we can try a local build.

[bthrasher]

Hi, all. Is there any update on this? Thanks!

[douglowe]

The xorg-makedepend dependency is now sorted. However I haven't gone through the full local build yet.

[zklaus]

Just back from EGU and a bit of vacation. Sorry about this snafu. The ncl build system happily concludes the build as successful even when no binary was produced. For the other platforms we have tests, but on osx-arm64 they cannot be run, so this slipped us by. I am looking at it now in #135, starting with an added sanity check that hopefully will prevent this situation in the future.

[akrherz]

So we have bad news for NCL on arm64. Getting this to build on a cross-compiled Mac looks to be a near impossible task. I'd suggest looking elsewhere for a NCL binary on this platform, like macports

[zklaus]

Well, I, too, am rather pessimistic, but I haven't given up yet...

[bthrasher]

Hi! Checking in again. At this point it seems the solution (at least for me) is either:

1. Keep a non-arm64 MacBook around for running NCL, or
2. Finally break down and learn enough Python to move to GeoCAT.

Any other ideas?

[zklaus]

Hi @bthrasher, sorry for leaving this hanging a bit. Without the shadow of a doubt, your best option is to move to Python. Whether that's with GeoCAT, Iris, Xarray, or perhaps ESMValTool is up to you. Full disclaimer: I am a developer on ESMValTool and Iris.

NCL is not a viable option for new developments. The only reason to use this package is if you have to keep legacy code running in an operational setting for a transitional period.

If you do want to pursue getting this up and running on osx-arm64, you can see how far I got before giving up in #135. The basic problem is, that at the moment, on Conda-forge osx-arm64 packages are created via cross-compiling, i.e. a compiler that produces osx-arm64 binaries is run on osx64. For NCL this doesn't work out of the box, because NCL produces a bunch of tools it needs during its build process so if we switch to the cross-compiler, those tools cannot be run on the (osx64) build machine, but if we don't switch to the cross-compiler, the resulting binary won't run on the target (osx-arm64) machine.

The solution is to compile tools needed during the build process with the normal compiler (accessible as $CC_FOR_BUILD and friends) and the final binary with the cross-compiler (accessible as $CC). The issue is that sorting out what needs to be compiled with which compiler and how to patch the build system to make that happen is a rather large amount of work that I cannot justify to port such an outdated tool to a completely new architecture where it never was supported in the first place.

If you can and feel up for it, that would of course be awesome!

The situation might change if and when osx-arm64 machines become available in the CI. Then we don't need all the cross-compiling and can just try to make the normal build process work on osx-arm64 (which still might be some work).

So that's where we are. At the moment, the plan is quite clear, but nobody has the resources to carry it out and it is not clear that it will ever be economically feasible. At the same time, the ecosystem moves on, and maintaining NCL will only become harder as new versions of libraries such as Netcdf come around and Compilers become stricter etc.

[bthrasher]

Got it. I'm in the twilight of my career and have legacy code that I need to keep running for another couple years, so I'll probably take a pass on migrating it. I did try to write it in Python a long time ago, but I could never get anywhere near the efficiency of NCL. When you're creating dozens/hundreds of TB of output, wallclock time is a major factor.

Thank you all for all your work! It's a labor of love, I'm sure...

[Dave-Allured]

There is some partial success reported in https://github.com/NCAR/ncl/issues/187, for building NCL for M1. MacPorts builds are currently broken due to a dependency problem (hdfeos5). I am trying to work on that one, with limited time. @douglowe , @zklaus et al, thank you for reporting on progress with conda-feedstock.

[zklaus]

Thanks guys. @bthrasher, there is one other thing you could try, which is to run the osx64 binaries in rosetta emulation. There is a comment explaining how to do that at https://github.com/conda-forge/miniforge/issues/165#issuecomment-860233092. I don't have access to an osx-arm64 machine, so cannot test it myself, but maybe give it a try.

Re NCL v Python, I have to say that I cannot imagine NCL reaching the necessary performance for my TB of ESM data :) After all, with current architectures, one must use parallel programming techniques, which are a breeze with Dask and Distributed and the like and seem nigh impossible with NCL. But of course, to each their own.

[MicroTed]

I don't know about cross-compiling, but there is a native compile of ncl working for macos-arm64 after a couple fixes. See https://github.com/NCAR/ncl/pull/191

[zklaus]

Thanks for pointing this out, @MicroTed!

The tricky bit with cross-compiling is this: The NCL build process starts by building some tools that need to run during the rest of the build process. Only after that, it starts building the actual target binaries.

In cross-compiling, you usually use a compiler that runs on the host, i.e. the machine that does the compiling, but produces binaries that are compatible with the target, i.e. the machine that should run the final program at the end. That means that a binary that is produced with the cross-compiler can usually not be run on the host. To do successful cross-compiling for a project like NCL, one needs to use two different compilers and distinguish between the compiler that produces binaries that can be run on the host (but not on the target), and the compiler that produces binaries that can be run on the target (but not on the host).

In our case, the two compilers are readily available as ${CC_FOR_BUILD} and ${CC}, respectively, but the problem is that the NCL build system does not distinguish between the two and it would be significant work to figure out where the "normal" (target) compiler needs to be replaced with the host compiler. Given the abandoned status of NCL, I personally can't justify that effort.

Of course, PRs are welcome.