Upgraded Macbook-Pro operating system from Monterey to Ventura

With the introduction of MacOS15 Sequoia, the mavens at Apple dropped support for MacOS12 Monterey.  I held on for a month or so while two updates of the Microsoft Apps came and went without my laptop able to download them.  Yesterday I tried to edit a Word file sent to me by someone.  The older software was not working well in edit mode, so I decided to upgrade everything.  I do not want to scale the heights of MacOS15 Sequoia yet, because it may introduce a new wrinkle in my legacy Fortran codes.  Consulting the Apple help pages with the Google, I determined that one can upgrade to an older system through the App Store, so I followed the link to the latest version of MacOS13 Ventura, an operating system that Apple will probably support until Fall 2025.  By then I will have upgraded my laptop to an Apple M4 chip and be digesting Sequoia on it.  Both iMacs are currently running MacOS14 Sonoma without serious problems, but I havent been developing Fortran codes on them.  So Ventura was the upgrade.

The upgrade notes from May 2023 worked successfully, installing MacPorts and then using MacPorts to install gcc12 and its gfortran code.  The only wrinkle was the need to alter one of the MacPorts auxiliary files (sources.conf) to correct a misleading weblink for software tarballs.  This file proved challenging to find on my laptop -- I needed the Google to find the breadcrumbs left by previous programmers with the same installation bug.

My altered legacy codes from 2023, changed to accommodate the syntax rules of Fortran 2018, worked OK.  When compiled, there were many warnings about arrays out of bounds, owing to the past use of the old DIMENSION B(N,1) syntax that left the number of rows in an array open.  A warning, not an error, so the codes can be used without changing all the DIMENSION statements.

In other housekeeping, I upgraded the ObsPy39 environment in Anaconda to ObsPy 1.4.1.  Not tested yet.  Need to sync with the iMacs, probably.  Anaconda itself did not nudge me to upgrade the Navigator.

New M3 iMac Software Installs: MacPorts and the nedit text editor.

 Migrating from an Intel iMac running MacOS Ventura to an M3 iMac running MacOS Sonoma involves no short cuts.  The Migration Assistant copies over lots of executable files that dont work properly.  Worse, the file structures of Ventura do not all carry over into Sonoma.  I had to erase all older Anaconda environments and also physically delete files on /Users/jjpark/anaconda3/envs and re-create environments that the Sonoma version of Anaconda placed onto /opt/anaconda3/envs.  Otherwise I could make multiple environments in different locations with the same name.  Old non-functional environments from the earlier installations, and newer ones that worked.

MacPorts was similar.  I had to uninstall the MacPorts installation that had been migrated from the older Intel computer.  Then install a fresh version of MacPorts.  Unfortunately, there was a glitch in the library binary for the graphical text editor nedit, so that the executable would complain about a missing element in a dynamic library.  This is the glitch

--> nedit .cshrc 
 dyld[93664]: Symbol not found: _vendorShellWidgetClass
  Referenced from: <B0C176D5-4F1E-316E-A53A-2EA6B4F48FBA> /opt/local/bin/nedit
  Expected in:     <C5BDACE7-B18C-3905-8915-706615092114> /opt/local/lib/libXm.4.dylibTrying to use the nedit program on my new iMac M3, after installing MacPorts for Sonoma 

I went to MacPorts website and submitted a ticket with a query for the MacPorts programmer community.  I got a solution within the workday! Here it is:

I can reproduce the problem on my own (macOS 12 x86_64) system if I receive a binary of nedit compiled on our build servers last year. However if I rebuild it from source (sudo port -ns upgrade --force nedit) then it works. Does that work for you too?

It worked for me as well!

New M3 iMac Software Installs -- Obspy within Anaconda

For switching to Apple Silicon, the old Anaconda installation persisted after I transferred files from the old 2017-vintage iMac.  The location of the files was /Users/jjpark/opt/anaconda3, but there were also obsolete files in /Users/jjpark/anaconda3.  The New location for Anaconda files is the "shared" directory /opt/anaconda3.   The processing environments are located in /opt/anaconda3/envs.  To create these environments, I used the same commands as for the older computers

My solution is to create a new environment for the new obspy environment, and install Python 3.9 directly into it.  First, open a terminal window within Anaconda.  From the webpage:

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

Create a new environment within Anaconda by typing commands into the terminal window"

conda create -n obspy python=3.9

conda activate obspy

conda info --envs

assuming that you are in the obspy environment . . .

conda install -c conda-forge obspy

conda install jupyter

conda install cartopy

Note that I installed cartopy, rather than basemap.  

How to fix a split Fusion Drive (May 2023)

 

This page helped me to resuscitate an ailing iMac in my office.  It was while executing this fix that I upgraded MacOS to Ventura and broke my Fortran computing environment.  Still, it was worth it.

https://support.apple.com/en-us/HT207584

If your Fusion Drive appears as two drives instead of one in the Finder, it's no longer working as a Fusion Drive. Here's how to fix it.

Fusion Drive, a storage option on some iMac and Mac mini computers, combines a hard drive and flash storage in a single volume for improved performance and storage capacity. If your Fusion Drive appears as two drives instead of one in the Finder, it's no longer working as a Fusion Drive. This can happen after replacing either drive of your Fusion Drive, or using software to intentionally split them into separate volumes. 

You can continue using the two drives independently, or follow these steps to regain the benefits of having the single logical volume of a Fusion Drive.

. . . .  see the support page at Apple

Adjusting to MacOS Ventura and gcc12 and Fortran 2018 syntax rules: Various Subroutines

 Sportsfans,

The upgrade to MacOS Ventura has broken my Fortran programming environment, mainly by moving the directories of the operating system around so that older versions of gfortran and gcc cannot find their proper libraries.  Rather than spend hours recreating the original file structures and libraries from old backups and the Relocated Items folders, I decided to level up to the latest GNU C and Fortran compilers as maintained by MacPorts.  These are gcc12 -- version 12 of the venerable GNU freeware package.  The old Fortran programmers must have retired, because these new compilers have discarded several aspects of Fortran 66 syntax that I learned as a teenager.  I don't write code with this older syntax, having transitioned to the Fortran 77 syntax of do/end do loops and if/then/else branches while in graduate school.  Nevertheless, there is plenty of legacy code in my toolboxes, and some of these subroutines have do loops that end on an executable statement, and others contain nested loops that terminate on the same numbered statements.  The new Fortran boffins outlawed these syntaxes, along with the arithmetic IF statement, in Fortran 2018.  My legacy codes have plenty of arithmetic IF statements, so all of these had to be reprogrammed to comply with gcc12.

This post is the third of a handful of posts that will provide these upgraded codes.  Here are a collection of subroutines that resided in my subdirectory Ritz for inclusion in various codes.  I scrubbed my Real*4 C-language FFT subroutine refft.c from my old codes a few years ago, in favor of the Real*8 Fortran routine fft2.f.  Some codes are free-oscillation subroutines that date from Freeman Gilbert, Ray Buland and/or John Woodhouse, all of whom wrote many legacy codes before the advent of Fortran 77.  All codes are contained in a zipfile codes_jlib_fort18.zip on the Google Drive subdirectory.

gfortran -c subroutine.f 

gfortran -o PROGRAM PROGRAM.f subroutine.o

subroutines include 

cossin.f

csolve.f

fft2.f

gxfcn.f

qromb.f

qtrap.f

rspln.f

solve.f

splneq.f

splnsm.f

svd.f

https://drive.google.com/drive/folders/0B5cfVtTS8QXZTGc1WnViSE5RWjA?resourcekey=0-YidcAd0wJGPRR1PhAyUYNA&usp=sharing

Adjusting to GCC12 upgrade in MacOS Ventura. Updated version of the EISPACK package.

  Sportsfans,

The upgrade to MacOS Ventura has broken my Fortran programming environment, mainly by moving the directories of the operating system around so that older versions of gfortran and gcc cannot find their proper libraries.  Rather than spend hours recreating the original file structures and libraries from old backups and the Relocated Items folders, I decided to level up to the latest GNU C and Fortran compilers as maintained by MacPorts.  These are gcc12 -- version 12 of the venerable GNU freeware package.  The old Fortran programmers must have retired, because these new compilers have discarded several aspects of Fortran 66 syntax that I learned as a teenager.  I don't write code with this older syntax, having transitioned to the Fortran 77 syntax of do/end do loops and if/then/else branches while in graduate school.  Nevertheless, there is plenty of legacy code in my toolboxes, and some of these subroutines have do loops that end on an executable statement, and others contain nested loops that terminate on the same numbered statements.  The new Fortran boffins outlawed these syntaxes, along with the arithmetic IF statement, in Fortran 2018.  My legacy codes have plenty of arithmetic IF statements, so all of these had to be reprogrammed to comply with gcc12.

This post is the second of a handful of posts that will provide these upgraded codes.  Here is the venerable EISPACK package of linear-algebra subroutines for inclusion within a Fortran program.   

gfortran -c eispack_fort18.for  

ar r eislib.a eispack.o

ranlib eislib.a

gfortran -o PROGRAM PROGRAM.f eislib.a

https://drive.google.com/drive/folders/0B5cfVtTS8QXZTGc1WnViSE5RWjA?resourcekey=0-YidcAd0wJGPRR1PhAyUYNA&usp=sharing

Adjusting to MacOS Ventura and gcc12: plotit software changes

 Sportsfans,

The upgrade to MacOS Ventura has broken my Fortran programming environment, mainly by moving the directories of the operating system around so that older versions of gfortran and gcc cannot find their proper libraries.  Rather than spend hours recreating the original file structures and libraries from old backups and the Relocated Items folders, I decided to level up to the latest GNU C and Fortran compilers as maintained by MacPorts.  These are gcc12 -- version 12 of the venerable GNU freeware package.  The old Fortran programmers must have retired, because these new compilers have discarded several aspects of Fortran 66 syntax that I learned as a teenager.  I don't write code with this older syntax, having transitioned to the Fortran 77 syntax of do/end do loops and if/then/else branches while in graduate school.  Nevertheless, there is plenty of legacy code in my toolboxes, and some of these subroutines have do loops that end on an executable statement, and others contain nested loops that terminate on the same numbered statements.  The new Fortran boffins outlawed these syntaxes, along with the arithmetic IF statement, in Fortran 2018.  My legacy codes have plenty of arithmetic IF statements, so all of these had to be reprogrammed to comply with gcc12.

This post is the first of a handful of posts that will provide these upgraded codes.  The first is the venerable, and oft-hated, plotit subroutine for on-the-fly XY-plotting within a Fortran program.  I include versions of plotit.f 

gfortran -c plotit.f  -L/usr/X11/lib -I/usr/X11/include -lX11

gcc -c xlplotit.c -L/usr/X11/lib -I/usr/X11/include -lX11

ar r plotlib.a plotit.o xlplotit.o

ranlib plotlib.a

gfortran -o PROGRAM PROGRAM.f plotlib.a -L/usr/X11/lib -I/usr/X11/include -lX11

I keep the compiled plotit object code in a signature directory for adding to my codes:

 /Users/jjpark/Plotxy/plotlib.a

In the zipfile Plotlib_fort18.zip I include updated versions of contour.f and makedat.f for similar on-the-fly plotting of a contour plot, and test-plotting with plotit.  I haven't tested these, so shoot me an email if they crash.

https://drive.google.com/drive/folders/0B5cfVtTS8QXZTGc1WnViSE5RWjA?resourcekey=0-YidcAd0wJGPRR1PhAyUYNA&usp=sharing