Compatibility with ARM

[aedandan]

I am working on a project for a distributed systems course and intend to use a supercomputer that is built using ARM as its instruction set. Has there been any testing on whether CCTools (particularly Makeflow and Work Queue) can work successfully in that environment?

[dthain]

Howdy, which machine are you targeting? cctools currently builds and runs fine on M1 Macs, which are also ARM based, so I don't forsee any fundamental problems. Suggest that you have a look at the Build From Source instructions. On any new machine with different compilers etc, there are always some odds and ends that crop up in the build process, so let us know if you run into any trouble.

[aedandan]

Thank you for the answer! My project is intended to use the Ookami supercomputer provided by Stony Brook University. I believe there are enough resources built into that system to allow for compiling CCTools to go smoothly, based on this response.

[aniquaTabassum]

Hello Dr. @dthain! I am working in the same team with @aedandan, and we are trying to make cctools work on Ookami supercomputer, which is using Linux aarch64 architecture. We were able to use cctools using command line, but are having a hard time to make the Python API work. To be more specific, if we try to install ndcctools from Miniconda using this command:

conda create -n cctools-env -y -c conda-forge --strict-channel-priority python ndcctools

And we are running into this error:

PackagesNotFoundError: The following packages are not available from current channels

Upon checking Miniconda's website, we found out that ndcctools does not have any support for Linux aarch64. It has support for OSX arm64 though. We found this information here.

I guess our question is, is it possible to make the Python API work in the Ookami supercomputer that has Linux aarch64 architecture? Or should we continue with the command line commands for cctools? Thank you!

[dthain]

Right, I am sure that we don't have conda packages for aarch64 on Linux.

But I think if you check out the cctools source from GitHub and build it on the machine, there is a reasonable chance it will work. (Assuming there is some kind of Python installed there.). Please try the (Build From Source) https://github.com/cooperative-computing-lab/cctools?tab=readme-ov-file#build-from-source) instructions.

[aniquaTabassum]

Hello Dr. @dthain, thanks for the response! As of now, we have successfully downloaded cctools source from the Github page, as mentioned in your reply. Upon doing that, we were able to run the commands such as makeflow -v, work_queue_worker -v and so on. But we are still unable to directly use the python API. To be more specific, we cannot do this like the following:

import work_queue as wq; try: q = wq.WorkQueue(name="wq_name") except: print("Could not do it")
We get the error No module named 'work_queue'

We have tried to make some modifications to make this error go away, but ultimately couldn't on our Linux aarch64 supercomputer. We were able to import the work_queue module and use it in our Python code as intended in OSG that uses x86_64 architecture, by downloading ndcctools through Miniconda. I am guessing it is because the ndcctools that is available through Miniconda provides Python files such as work_queue.py, but cctools source from Github does not have such Python files? So for the Linux aarch64 supercomputer, we have to stick with using the command line options such as makeflow -v, work_queue_worker -v?

[dthain]

So if you are compiling and installing cctools from source (make and make install) then you need to set PYTHONPATH so that Python knows where to look to find the modules.

If you installed cctools in $HOME/cctools then you need to do something like this:

$ export PYTHONPATH=$HOME/cctools/lib/python3.11/site-packages:${PYTHONPATH}

(and note that you should use the proper version number of python.)

[aniquaTabassum]

Hello Dr. @dthain, setting the PYTHONPATH worked! We were having some issues even after setting the PYTHONPATH before we started this discussion. Turns out, even though the supercomputer has Python 3.12, the lib folder in cctools had somehow Python6. After reinstalling cctools, the Python versions matched and we are able to run the Python API properly. Thank you so much for your continuous help!

[dthain]

You are welcome, have fun!