Converting Basemap to Cartopy within ObsPy Jupyter Notebooks

 So far my trick is to replace the statement 

from mpl_toolkits.basemap import Basemap

with

import cartopy.crs as ccrs

and this seems to work in the first notebook I tried  (QLove notebook for SNZO)

Upgrading the Python Version within Anaconda

 The upgrading of Python within Anaconda is complicated by the planned obsolescence of Python versions in the Anaconda software.  As of 02/16/2023, Anaconda has support for Python 3.7 and higher.  As a result, simply upgrading

conda install python=3.9

might work if you have 3.7 or 3.8 already installed.  However, I had my obspy environment set up with Python 3.6, and the version would not update automatically.  This prevented me from updating obspy and many other packages.  My solution is to create a new environment for the upgrade, and install Python 3.9 directly into it.  From the webpage:

https://www.geophysik.uni-muenchen.de/~megies/installation2.pdf

Create a new environment within Anaconda

conda create -n obspy39 python=3.9

conda activate obspy39

conda info --envs

assuming that you are in the obspy39 environment . . .

conda install -c conda-forge obspy

conda install jupyter

conda install cartopy

Note that I installed cartopy, rather than basemap.  The latter would not install properly, and it is the older version anyway.  At the end of this exercise, I had two obspy environments, obspy and obspy39.  One can delete the older creakier version once you are certain that the new one works.

Updating Anaconda Navigator from Version 1.x to Version 2.x

 Once Anaconda sits on your computer, the updates start to annoy you.  If you ignore them long enough, however, they don't go away.  Eventually, the upgrades will no longer be simple.  For three of my MacOS computers, I first installed Anaconda 1.x, and for the home iMac I basically tore out my original installation in order to upgrade to Anaconda 2.x.  Upgrading from 1.x to 2.x need not be that drastic.  I discovered a procedure that works at a website

https://appdividend.com/2022/01/19/how-to-update-anaconda-upgrade-anaconda-navigator/

This procedure relies on entering line-commands in a terminal window, which you open within Anaconda Navigator.  Just go to the base environment and open a Terminal, rather than search for a Jupyter Notebook or a Python window.  In this Terminal, you might need to first update the conda app to its latest version

conda update conda

or

conda update -n base -c defaults conda

Then update Anaconda itself to a specific version, tied to a year and month, e.g., 

conda update anaconda=2022.10

or  

conda install anaconda=2022.10

In one case I installed the new Anaconda first, because the condo update hung the computer.

That metapackage represents the pinned state that has undergone testing as a collection.
If you want to update all the packages under conda distribution, you can use the following command.
conda update --all
The conda update –all will upgrade everything. This updates all packages in the current environment to the latest version.

Endless Upgrade Notes for MacOS 10.15.6 Catalina: making gfortran work

 From August 18, 2020

I was using the Anaconda version of gfortran, and encountering problems with runtime libraries.  I had used the standard MacOS C-compiler clang as an alias for my gcc, and clang lacks fortran support.   

I switched to gcc-10 and gfortran-10, as of this date.  The runtime library problems I had yesterday afternoon induced me to install a fresh compiler via the Fink project.  http://www.finkproject.org   I am still checking that things are working correctly -- Catalina messed up more of my computing environment than I knew.

some info on this issue from a real programmer is here

https://solarianprogrammer.com/2019/10/12/compiling-gcc-macos/

And my commands were

fink selfupdate

fink install gcc10

The fink command compiled the compilers from scratch, so it too a few hours on a 2019 MacBook Pro.  Dont try this just before you need to carry your laptop someplace.

Upgrade to MacOS 10.15.6 Catalina, Even More Bookkeeping Notes

When trying to install SAC, the Seismic Analysis Code, in MacOS 10.15.6 Catalina, I encountered some problems.  The MacOS upgrade fences off a number of legacy libraries and tools into the Relocated Items folder on the Desktop.  If something stopped working after the upgrade, I discovered that some essential file had been "relocated" to a place on my disk where the application or compiler could not find it.  For SAC, the executable could not find X11 runtime libraries for plotting.  Rather than re-request the software package from IRIS, I decided to recompile the application from the sac-101.6a-source.tar file that I had thankfully never deleted from my Utilities folder.  It is the same version of SAC that I have had from 2018, but I desired a clean (or cleaner) install.  

The SAC compilation is guided by the file Readme.buildsac within the sac-101.6a tarfile, a file unchanged from 2013, but two hurdles were not anticipated in this file.  First, the *.h header files for compilation are placed by Catalina in an obscure place, 

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include

which I had placed into my CPATH environmental variable, and 

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib

which I had placed into my LIBRARY_PATH environmental variable.  The compilation later halted when it could not find the X11 libraries.  The X11 libraries were actually sitting at several locations in my computer, but not where the  SAC Makefile looked for them.  Many software packages install their own versions of X11.  Rather that setting up some Rube-Goldberg linkages that could be broken later inadvertently, I decided to re-install the X11 libraries from scratch by downloading XQuartz, even though I had the latest version already installed, and I could already use XQuartz to open and execute command lines within X-windows.  This gambit succeeded, and the SAC makefile could advance beyond its loading of the X11 libraries.

There was one more Red Sea to part before I could reach the promised land of SAC functionality.  An obscure command within a header file crashed the makefile. The error was

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/AvailabilityInternal.h:33:18: error: missing binary operator before token "("

 The offending passage looked like this:

# if __has_include (<AvailabilityInternalPrivate.h>) # include <AvailabilityInternalPrivate.h> # endif

This code snippet looks for an auxiliary header file, and inserts it, if it can find it. Easy, right? Not easy. Some Google-sleuthing on the command "__has_include" revealed that not all versions of the gcc compiler have this command in their toolbox. My SAC makefile was crashing on not finding "__has_include"! The solution was to wrap the existing code with another IF statement:

#if defined __has_include # if __has_include (< AvailabilityInternalPrivate.h >) # include < AvailabilityInternalPrivate.h > # endif #endif

This way the Apple SDK checks to see if the C-preprocessor command actually exists before it tries to use it. Thankfully, my SDK does not have AvailabilityInternalPrivate.h, so I am not missing it.

I had to make this correction twice, in SDK files that could only be edited by root.

Upgrade to MacOS 10.15.6 Catalina, More Bookkeeping Notes

./configure --prefix=/opt/sac

On MacOS Catalina 10.15.6, with Xcode Version 11.6  I also needed to update the library path in my .zshrc (the MacOSX.sdk paths are new):

export CPATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/opt/local/include'

export LIBRARY_PATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib:/opt/local/lib'

in the  .cshrc file, I added 

setenv CPATH /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/opt/local/include

setenv LIBRARY_PATH /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib:/opt/local/lib

but there are more things to change, before sac will compile and run ., . .. 

Upgrade to MacOS 10.15.6 (Catalina), Some Bookkeeping Notes

Sportsfans,

After upgrading my Macs to MacOS X 10.15.6 Catalina last weekend, a number of compiling links broke and also some third-party software was "relocated".  Because I had delayed upgrading the MacOS from Mojave for over 9 months, the third-party software had adjusted to the new situation.  I downloaded a fresh version of "fink" (rev 0.45.1)   and installed it in the directory /opt/sw, because its old location /sw had been expunged by Apple's update.  This required some changes in my .cshrc file, so that I could point to the correct directories.  I had to upgrade XCode upward three versions, from 10.3 to 10.6, install the Xcode command tools, selfupdate fink, and then run an endless installation procedure to install my favorite X11 text editor nedit.    Took some time, but it all worked.

The older gcc5 compilers in fink were relocated by the MacOS upgrade and had been upgraded to gcc10 in fink.  However, I discovered that my fortran codes were compiling just fine, which meant that they were not using the gfortran compiler in fink.  I found the working gfortran compiler in Anaconda, /Users/jjpark/anaconda/bin/gfortran, so I dropped my .cshrc  pointers to the fink directories for gcc and let them utilize the Anaconda gcc compiler.  The X11 libraries also moved, into /opt, but changing the links fixed that.

So far, so good.  Crossed fingers.

Fearless Leader