Xarray can write and load netCDF4 files into datasets.
Warning messages may appear when using older netCDF4 files with newer versions of Xarray or NumPy like:
RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility. Expected 16 from C header, got 96 from PyObject
This may indicate underlying incompatibilities between the versions of Xarray, Pandas, NumPy, and the netCDF4 library.
Conda
channel priority order
is ordered by which channel appears first (highest) in .condarc.
We generally recommend adding per-environment channels rather than modifying the global configuration to avoid corrupting multiple environments with incompatible packages`.
In general “strict” channel priority is
recommended
to mitigate compatibility problems.
Like the Numpy helper function
numpy.testing.assert_allclose(),
the Xarray helper function
xarray.testing
module compares floating point arrays within a specified tolerance.
Example:
importxarrayimportxarray.testing# code under testdat = myfunc(...)
# load the reference Dataset to compare againstref = xarray.open_dataset("ref.nc")
xarray.testing.assert_allclose(ref, dat)
dat.equals(ref)
is generally inappropriate to directly compare floating point numbers.
Clive Moler’s
article
address the topic of floating point comparisons succinctly.
Floating point comparison algorithm: across computing languages, an algorithm suitable for comparing floating point numbers “actual, desired” to absolute tolerance “atol” and relative tolerance “rtol” is:
Projects using GCC, G++, and Gfortran compilers often set the -Wall option as default.
The intent of -Wall is to enable a common subset of warnings that are generally useful for catching potential issues in your code.
However, new warnings may be
buggy
to the point of breaking builds on valid code, or cause false warnings.
It may be beneficial to not enable -Wall by default for end-user builds, but only for development builds.
GCC does not appear to have a way to tell what warnings are enabled by -Wall programmatically.
Instead, one must refer to the GCC
documentation
or even the GCC source code to see which warning flags are included in -Wall.
For example, in Gfortran 15.1, the -Wall option includes the -Wexternal-argument-mismatch warning, which was broke builds on valid code, and was fixed in Gfortran 15.2.
Gfortran 15.1 has a
bug
with the -Wexternal-argument-mismatch flag.
This flag is implicitly included in the -Wall option.
In Gfortran 15.1–fixed in Gfortran 15.2–the
-Wexternal-argument-mismatch warning causes compilation to fail on
correct code.
To work around this bug, suggest in the build system such as CMake to detect GCC 15.1 and disable the -Wexternal-argument-mismatch warning.
It’s also relevant to consider if -Wall is a flag one wants to automatically set for the default end-user build, as such a bug could happen for future versions of GCC as well.
In CMake, detect GCC 15.1 and disable the problem flag:
Fortran bind(C) allows Fortran to call C functions and vice versa.
However, Fortran arrays are one-based by default, while C arrays are zero-based.
This can lead to confusion when passing arrays between Fortran and C.
Adding to the confusion is multiple GCC Gfortran versions have
known bugs
that were not fixed as of their final release.
Specifically, the versions of Gfortran known to be
working correctly
are Gfortran ≤ 8.5 and Gfortran ≥ 12.
Known broken GFortran versions are 9.x, 10.x, 11.x.
Some code may have integer declarations like u_int, u_long, etc.
These types are not part of the C or C++ standard and may not be portable across different platforms.
Instead, it’s recommended to use the standard integer types, including those defined in <stdint.h> (C) or <cstdint> (C++).
For example, replace “u_int” with
unsigned int
or a fixed-width type appropriate for the use case.
“u_int” is from header <sys/types.h> and is not part of the C standard, and it may not be available on systems like Windows.
GDB debugger is not yet readily available for macOS with Apple Silicon CPU.
GDB is installable on Apple Silicon Macs via
Homebrew,
but it is
not functional
on Apple Silicon Macs for local executables.
It has long been possible to use a virtual machine with Linux for ARM64 to run GDB within the VM.
When trying to use GDB on Apple Silicon for local executables, it doesn’t work:
gdb ./myexe
r
Don’t know how to run. Try “help target”.
To use GDB on an Apple Silicon Mac for local executables, it seems a Linux VM is the best option.
The Mathworks experienced a major outage starting on
May 18, 2025
due to a ransomware attack.
The Mathworks’ license servers have been effectively required by default for Matlab for ~ five years.
Virtually all Mathworks services were down initially for about a week, and then services are gradually being restored.
The outage affects users worldwide regarding ability to start Matlab or install toolboxes.
Trying to access Mathworks services results in a 503 return code or “no healthy upstream” or similar.
Previously, external institutions
cited
a
cyberattack.
Internet discussions have been peppered with recommendations to switch to GNU Octave, which is a free and open-source alternative to Matlab.
However, the proprietary toolboxes that add so much value and functionality to Matlab are often not available for GNU Octave.
Examine the
GNU Octave Help forum
to assess issues facing Octave users vs.
Matlab Answers forum.
It behooves instructors to consider avoiding proprietary toolboxes except where essential to the learning goals.
Note that Python packages (and libraries in just about every programming language) have also experienced cyberattacks.
Matlab adds serious value to many research and development projects, but the reliance on a single vendor for such a critical tool is a risk that should be considered.
Transitioning to open-source alternatives like GNU Octave or Python take considerable effort.
Using the
Matlab Engine for Python
can help incrementally transition Matlab projects to Python.
Apple has
adaptive impedance
for the TRRS connector on MacBook.
Windows Logo certified computers likewise have standards for voltage levels and impedance for audio input and output.
Instead of the built-in computer audio interface, we generally recommend using an external USB sound card to reduce risk of damage to the computer in case of voltage surges.
Consider two 3.5mm TRS cables (one each for input and output) to the radio connector (typically the microphone connector that also has fixed level audio output) and a USB sound card.
The USB sound card can be used on different computers once it’s known to work with the radio audio interface.
At a minimum, a grounded coaxial surge protector should be used in the antenna feedline along with a fused, surge-protected power supply.
Consider using an older laptop that still runs a currently supported operating system as a dedicated radio computer.
This avoids risking an expensive laptop when an older laptop is often more than adequate for digital ham radio modes.