Scientific Computing

If the man command on Linux isn’t working, check that the manual database is installed:

apt install man-db

matplotlib.ticker.ScalarFormatter configures the colorbar and axes labels to not have too many decimal places.

ScalarFormatter Problem

If I made a standard line plot using the ScalarFormatter passed into a function, then subsequently passed the ScalarFormatter into another function that used colorbar, the line plot y-axis would be reset to match the limits of the later figure’s colorbar.

I didn’t think the ScalarFormatter would be able to feedback like that.

Fix ScalarFormatter

Enclose ScalarFormatter in its own function, then call that function from each of the plotting functions, thereby creating a new/unique ScalarFormatter for each figure.

The Madrigal distributed database allows access to much of the high level AMISR (incoherent scatter radar) data and DMSP data. For lower level data (e.g. I/Q digitized samples) you need to approach the PI of the relevant instrument for data.

Madrigal Python examples

Note: This problem was fixed in Matlab ≥ R2015a.

Matlab R2013 cannot handle uint64 seek offsets. Octave ≥ 3.6 works with uint64 offsets.

offs = uint64(0); %or any number
fid = fopen(tempname);
fser = fseek(fid,offs,'bof');

• fser == -1 for Matlab R2013a/R2013b (error)
• fser == 0 for Octave (correct)

The venerable NRL Flux-Corrected Transport algorithm for Solving Generalized Continuity Equations has been cited in hundreds of publications.

Updated syntax of the original Fortran code slightly to fit with the FORTRAN 77 standard (not changing algorithm behavior, only syntactical correctness). Plotting code uses f2py to make the LCPFCT run from Python with 50x speedup overall since you don’t have to write output to disk and then read it back in via a custom parsing algorithm.

Cross-jurisdictional and intra-jurisdictional radio systems that are incompatible is a problem as old as public safety radio itself. It takes a major catastrophe to suddenly bring together diverse EMS and Police forces on a task needing common radio channels. Yes, preplanned events such as parades and national holiday celebrations also bring EMS and Police in large inter-jurisdictional efforts, but that can be solved with radio system patches or extra radios.

Firefighters mix and match other department resources frequently as big fires can happen anywhere, anytime. One typical solution is to have large numbers of adjoining Fire agencies on common radio technology, such as VHF analog, even when every other public safety resource might be on a P25 digital trunked network system. Another solution is for an incident response van to have a bank of radios that can be patched on-site. In major urban areas, city laws may require installation of distributed antenna systems for local public safety radio–a building-wide built in broadband repeater for public safety in effect.

VHF portable coverage is worse in general compared to higher frequency (shorter wavelength) radio bands due in large part to high on-body attenuation (up to factor of 100-1000 (20-30 dB)) and high noise levels on VHF, particularly in urban areas. Yet, vast swathes of American fire departments are stuck on VHF due to interoperability concerns and budget constraints. The high cost of the APX8000 won’t necessarily be a solution for rural fire departments, but the adjoining large tax base city might afford the APX8000, allowing the city fire department to upgrade to the regional P25 digital system. The APX8000 in that scenario purchased for the city fire department allows mutual aid from adjoining rural fire departments.

Motorola APX8000 cost/benefit breakdown

Of course the Motorola salesperson isn’t pitching the APX8000 to small budget fire departments. The APX8000 sale goes to the adjoining city fire department, who now doesn’t need a $5000 radio patch that might break down, making a single point of failure in the incident response van. Dispatch isn’t tying up repeaters with console patches.

A real value add of the APX8000 is the reduction of need for complex fireground or console patches that tie up channels and break down at the worst possible time. Will the whole city get APX8000? Maybe not, but it depends on the historical patterns. They might choose to only get enough APX8000 to cover say 95% of mutual aid needs, and let console patches handle the last 5%. Also, given noise on VHF and a large site to cover for fire, it’s well possible to get out of radio range of the incident response van with the patch (or the central repeater), leading to the constantly dreaded case where you can’t talk to the person next to you on the radio.

I had a micro SD card that would only mount read-only, in Gparted and everywhere else, even as root. I moved the SD adapter read-only switch to either position, tried it in different readers, different computers.

Then I tried a different SD adapter and read/write worked.  

I experienced an error upon any use of apt with a new Rev. C Beaglebone with the factory Debian install like:

insserv: Starting led_aging.sh depends on rc.local and therefore on system facility ‘$all’ which can not be true!

Fix apt failure by replacing /etc/init.d/led_aging.sh with:

#!/bin/sh -e
### BEGIN INIT INFO
# Provides: led_aging.sh
# Required-Start: $local_fs
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start LED aging
# Description: Starts LED aging (whatever that is)
### END INIT INFO

x=$(/bin/ps -ef | /bin/grep "[l]ed_acc")

if [ ! -n "$x" -a -x /usr/bin/led_acc ]; then
/usr/bin/led_acc &
fi

and then reboot.

Code demonstrating use of the Adafruit GPIO module for Python flashing LEDs on the Beaglebone Black

A large maximum dynamic disk size for a VirtualBox guest is problematic. Even if one uses a small portion of that maximum size, the guest OS (especially Windows) will spread itself out. A 10 GB Windows image will climb to the maximum size of the dynamic VDI file over time (say to 50 GB).

Here’s a fairly painless procedure to fix this, taking less than 1 hour on a modern PC. I assume your guest OS is Windows, and your host OS is Linux running VirtualBox.

BACKUP THE VDI FILE BEFORE DOING THIS PROCEDURE!

In guest Windows, run Disk Defragmenter. It’s also possible to zero free disk space with SDelete.

Shutdown guest Windows, and “insert” the Gparted ISO file by right-clicking the CD icon at the bottom of the guest OS VirtualBox window and selecting your ISO file.

Resize guest Windows partition so that you have only say 8 GB free (e.g. original partition 40 GB, only 10 GB used –> resize to 18 GB)

Reboot guest Windows, removing the Gparted ISO file from VirtualBox. You will see Windows automatically runs CheckDisk–this is normal. You will need to reboot guest Windows once more, then shutdown guest Windows

In host Linux Terminal:

vboxmanage modifyhd --compact MyFile.vdi

The VDI file size may shrink significantly.

Defragment in guest Windows can make host VDI file INCREASE in size by the amount of bytes that were moved to defragment. Repeat steps 1, 2, and 6 of the procedure above when VDI has again grown too large. Do not make excessively large maximum size Dynamic VDIs to start–this problem will only repeat itself over time.