# A modernized SPLPAK

**URL:** <https://fortran-lang.discourse.group/t/a-modernized-splpak/5084>\
**Category:** Announcements\
**Created:** [January 26, 2023, 4:44am UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084 "2023-01-26T04:44:20Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\
**Post date:** [January 26, 2023, 4:44am UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/1 "2023-01-26T04:44:20Z")

</div>

[This post](https://fortran-lang.discourse.group/t/emulators-and-interpreters-in-fortran/5042/5) brought [NCL](https://github.com/NCAR/ncl) to my attention, which I’d not heard of before. In the [ngmath folder](https://github.com/NCAR/ncl/tree/develop/ngmath/src/lib/gridpack) you can find a lot of old Fortran code for interpolation. See [here](https://ngwww.ucar.edu/ngmath/) for an ngmath overview. I guess at one point it was a standalone library. It looks like development of this code stopped decades ago (some of it looks like Fortran 66). But, there are some nice routines in there. I noticed some that indicated they were from something called SPLPAK (a [Pack](https://degenerateconic.com/packs.html) I had never heard of before). It has code for computing N-D cubic spline fitting using a least squares method. The comments indicate it was started in 1972.

So, I present a [modernized SPLPAK](https://github.com/jacobwilliams/splpak). Improvements include:

- Converted the Fortran 66 code to modern Fortran. Eliminated all GOTOs and other ancient nonsense. The code is now much more readable.
- Eliminated the hard-coded limit of only 4 dimensions. Now it will work with any number of dimensions. This may now be the only publicly-available least squares cubic spline Fortran code that has this (does anybody know of another?)
- You can now specify the `real` kind using a compiler directive. So, if you want `real128`, you got it.
- Made it threadsafe. The original code was not, since it included `save` statements and `common` blocks. There are no more global variables, and all data is stored in a `splpak_type`, which includes `initialize` and `evaluate` methods for computing and evaluating the splines.
- It can be used with the Fortran Package Manager.
- [Documentation](https://jacobwilliams.github.io/splpak/index.html) is now auto generated from the code using FORD.

It’s great to see this code polished up and ready for another 50 years of service, rather than hidden away in a deep subdirectory of a mostly-abandoned software package.

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [January 26, 2023, 7:31am UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/2 "2023-01-26T07:31:26Z")

</div>

> [@jacobwilliams](#):
>
> (does anybody know of another?)

[fitpack](https://github.com/perazz/fitpack/blob/750ced0e696aca900cd6b2ed40f8fe063d57a7a6/src/fitpack_core.f90#L86) does have a hardcoded limit of 10 dimensions. Extending it too is actually a great idea!

---

<div class="post-metadata">

**Author:** ![conradoat](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/conradoat/32/1537_2.png) [@conradoat](https://fortran-lang.discourse.group/u/conradoat)\
**Post date:** [January 26, 2023, 9:47am UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/3 "2023-01-26T09:47:48Z")

</div>

I was considering in approaching this problem myself. I think it was necessary.

Many thanks!

---

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [January 26, 2023, 2:11pm UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/4 "2023-01-26T14:11:28Z")

</div>

Nice work Jacob. Looking through the NCL code there appears to be some of the old NCAR graphics routines (in Fortran) that might be useful. I’m retireing in a few months so maybe I’ll give it a look (can only play so much golf and catch so many fish).

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [January 26, 2023, 2:28pm UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/5 "2023-01-26T14:28:46Z")

</div>

Fantastic.

This supersedes it beautifully, but for reference the abstract (1991 version) of the previous SPLPAK read …

```plaintext

SPLPAK - Carl deBoor's cubic spline package.

Splines are functions used to represent user data. Typically
the spline will be built up out of polynomial "pieces", with some of
the higher derivatives not continuous at the "joins". The most common
spline used is the piecewise cubic. Splines are efficient and accurate.
In particular, they are far better than using high order polynomial
approximation.  

Applications included in the package will handle two-dimensional data, 
two-point boundary value problems, least squares approximation, integration, 
differentiation, smoothing, and other topics.
 
Reference: Carl de Boor, 
              A Practical Guide to Splines, 
              Springer Verlag
              ISBN: 0-387-90356-9

```

I would have thought it deserved a new name like SPLINEPAK to avoid confusion with the original but looking around that does not seem to be an issue, so I welcome back SPLPAK, new and improved.

---

<div class="post-metadata">

**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\
**Post date:** [January 26, 2023, 2:50pm UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/6 "2023-01-26T14:50:43Z")

</div>

I think that SPLPAK is different from this one. This one’s says it’s from Dave Fulker at NCAR.

NCAR seems to have once had a lot of Fortran libraries. There are traces of them on the internet but also a lot of dead links. So it’s hard to know the provenance of this.

---

<div class="post-metadata">

**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\
**Post date:** [January 30, 2023, 7:39pm UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/7 "2023-01-30T19:39:22Z")

</div>

The NCL [git history](https://github.com/NCAR/ncl/commits/develop) is fascinating. It has all the commits all the way back to 1990 (looks like it went through cvs/svn/git conversion over the years). It predates the first release of Python. In all that time, there was Fortran code in there, totally unchanged. SPLPAK is even older, from 1972. When FORTRAN 77 came along and added `if/else/endif` constructs, it was not updated. When Fortran 90/95 came along and added free-form source, it was not updated. When Fortran 2003 came along and added classes, it was not updated. The same story we have seen for many classic Fortran codes.

If it ain’t broke, don’t fix it?

And now they are throwing it all in the trash and replacing it with Python.

It took me a few days to do all the upgrades that could have been done over the course of 40 years if this code had been properly maintained. Not really a lot of work actually. The new version still works great, and now has features available that were not possible in the old version. The code is also no longer a scene of ancient horrors that would scare away a potential Fortran users. 🙂

---

<div class="post-metadata">

**Author:** ![milancurcic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/milancurcic/32/2_2.png) [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)\
**Post date:** [January 30, 2023, 8:03pm UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/8 "2023-01-30T20:03:56Z")

</div>

NCL was used (and still is by some) a lot in my field, including my old PhD lab. When I came in as a student I replaced a MATLAB-based graphics pipeline that was running operationally during hurricane seasons. The pipeline was both slow and producing ugly plots–I replaced it with a set of Fortran programs and GrADS scripts that were glued with shell. This ran very fast and was a bit less ugly. However GrADS is quite minimal feature-wise and takes a lot of work/code to make plots look good. Next year a student in the lab volunteered (to my dismay) to implement the graphics pipeline in NCL. It was slower than GrADS, faster than MATLAB, and the plots looked OK (still not great). A few years later I re-implemented the operational system in Python and replaced some of the NCL graphics with Matplotlib. Some, but not all. For NCL had one feature that no other graphics software that I know of had–curly vectors. Curly vectors are streamlines with arrowheads whose length and density was scaled by the magnitude of the vector field. I implemented these in Matplotlib once but couldn’t nearly meet the speed of NCL.

NCL was terrible and wonderful. It’s the kind of software that people either loved or hated. I didn’t love it but know many who did. It sure had its time and place.

---

<div class="post-metadata">

**Author:** ![egio](https://avatars.discourse-cdn.com/v4/letter/e/dbc845/32.png) [@egio](https://fortran-lang.discourse.group/u/egio)\
**Post date:** [January 30, 2023, 8:32pm UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/9 "2023-01-30T20:32:12Z")

</div>

For fast Python graph, typically in user interfaces, I use pyqtgraph that’s much faster than matplotlib.

---

<div class="post-metadata">

**Author:** ![DavidB](https://avatars.discourse-cdn.com/v4/letter/d/76d3ee/32.png) [@DavidB](https://fortran-lang.discourse.group/u/DavidB)\
**Post date:** [June 5, 2025, 7:14am UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/10 "2025-06-05T07:14:39Z")

</div>

> [@urbanjost](#):
>
> `Carl deBoor's cubic spline package.`

I have de Boor’s book and went looking for the code.

The book points to Fortran77 code at [https://www.netlib.org/pppack/](https://www.netlib.org/pppack/). It is still there.

There is a Fortran90 version on John Burkardt’s [site](https://people.math.sc.edu/Burkardt/f_src/pppack/pppack.html)

---

<div class="post-metadata">

**Author:** ![fxm](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/fxm/32/5726_2.png) [@fxm](https://fortran-lang.discourse.group/u/fxm)\
**Post date:** [June 5, 2025, 7:27am UTC](https://fortran-lang.discourse.group/t/a-modernized-splpak/5084/11 "2025-06-05T07:27:11Z")

</div>

I wrote a lot of NCL scripts in the past. A lot is in Fortran and C. IIRC, the idea was to have a scripting language for typical calculations and processing needed in atmospheric and oceanographic science (with lots of Fortran under the hood) combined with a way to create nice plots easily/quickly (I think thats where you then found most of C). Aspects of its syntax (esp. array stuff) was a little reminiscent of Fortran, too. It had its strengths, but I always found plotting tedious and mostly used GMT instead.

Never got used to it, but objectively speaking, it did have many positive sides.

The project was abandoned as they migrated to Python … _sigh_
