Introduction

This note exists to get you started if you want to write new code for ATLAS, or if you want to modify ATLAS source. It is not for kernel contribution, which is what most people do when contributing to ATLAS. Kernel contribution is much simpler, and is explained in ATLAS/doc/atlas_contrib.pdf or in html format at:

   http://math-atlas.sourceforge.net/devel/atlas_contrib/

So what is the difference between development and kernel contribution? In kernel contribution, you write a kernel to be used by ATLAS, using the provided ATLAS testers and timers to verify it, and when you are satisfied with its performance and reliability, you submit your kernel to the ATLAS team, and they accept it or not, and you are done.

Doing actual core development is quite a bit more complex. Probably the biggest change is that you will need to write your own tester and timer for your new code. No code will be accepted into the ATLAS code base without a tester which can be used to verify it. Since writing a decent tester is usually at least as hard as writing the code it tests, and is always a whole lot less enjoyable, the author must bear the pain of producing it along with the pride of producing the code. As a developer, you will be responsible for testing such new code on several platforms as well.

If you are instead hoping to modify some of the existing code base, remember that for non-kernel operations, portability and robustness must be the primary goal. There are many sections of ATLAS that we know to be second rate on a certain platform, but we also know that it works on the twenty or so architectures that ATLAS is routinely compiled for, so we leave it that way. This means that when a modification is made to a previously existing routine, the modifying author must have good evidence that the new code is as portable as the old. In short, the barrier to replacing tested code is high.

It is possible that users want access to the git repository even though they do not plan on doing development, mainly I'd guess so they can get access to the newest stuff without waiting for developer releases. Also, kernel contributors who make subsequent changes to their routines can speed up their adoption by submitting them as patches on the basefiles, or through a pull request.