The extremely high number of applicants, more than 1,800, coupled with the difficulty in satisfying the extensive vetting requirements to control the public distribution of the software made it unlikely they would achieve the challenge’s original objectives in a timely manner.
NASA looked at several alternatives to keep the challenge design intact – things like significantly extending the challenge performance period, and offering a much smaller portion of the code. Neither were considered viable options.
For a one-of-a-kind competition, 1800 participants is a large number, considering the need to verify US citizenship and that the work was done on a personal PC.
As a comparison, the notable
ACM ICPC
competition has several thousand participants each year in teams of three.
I was surprised to see 1800 entries.
It may be that a substantial proportion of HPFCC entrants were new to Fortran but experienced with HPC.
It would be interesting to get demographic info on the HPFCC entrants as a snapshot of the future of the Fortran language.
We encourage amateur radio operators and citizen scientists to
save raw WSPR data
in the form of two-minute long .wav files.
Load each WAV file into Python like:
fromscipy.ioimport wavfile
fn = '170620_1652.wav'# naming convention is YYMMDD_HHMM.wavfs, data = wavfile.read(fn)
This will result in fs=12000 Hz and data a 1440000 element 1-D vector of numpy.ndarray.
The WSPR baseband signals are user-selected in the 1400 .. 1600 Hz range.
Other signals within the audio passband are useful as reference, for example JT65, FT4, and FT8 for additional paths to analyze.
With Ubuntu at the remote and local ends, if unable to type anything into the Spyder IDE when connecting remotely over VNC, try TurboVNC on the laptop.
Download the latest
TurboVNC .deb file
and Install the .deb file
gdebi turbovnc*.deb
Now, the command vncviewer maps to the more advanced TurboVNC instead of TightVNC.
Before using TurboVNC, errors included
Qt: XKEYBOARD extension not present on the X server.
I tried putting in the remote system’s ~/.profile the line
Some Fortran code used proprietary modules from Visual Fortran and the like for among other things, playing back sound from Fortran on Windows.
I believe a more reliable and platform-independent way to playback sound from Fortran is to use an external application like ffplay, included with
FFmpeg.
FFplay will play prerecorded audio files.
Playback particular sounds based on filename.
This technique is not good for background music in a game, but is good for short sound effects to let you know your processing is done or for game sound effects in Fortran.
NOTE: use all lowercase filename, and don’t use spaces in names for best cross-platform compatibility and reliability.
Fortran program with sound example: use / as a file/directory separator on Fortran.
// concatenates strings in Fortran.
programmysounduseiso_fortran_env,only:input_unitimplicitnone! configure ffplay -- could make if/else to allow other players
character(*),parameter::playexe='ffplay'character(*),parameter::cmdopts='-autoexit -loglevel quiet -nodisp'character(1000)::fn,cmdprint*,'input sound filename to play'read(input_unit,'(A)')fn! must be (A) and not *
cmd=playexe//' '//cmdopts//' '//trim(fn)print*,trim(cmd)! for debugging
! exitstat only works for wait=.true. by Fortran standard.
callexecute_command_line(cmd,wait=.false.)endprogram
More Fortran sound playback examples: robust Fortran sound playback example
play_sound.f90
or implemented as a Fortran game with sound
sound.f90.
iso_fortran_env is respected by all common Fortran compilers, as implied by its name.
iso_fortran_env is part of the Fortran 2003 specification and popular Fortran compilers added it a decade ago (Gfortran since at least GCC 4.3).
Why use iso_fortran_env terminal I/O: legacy programs written before Fortran 2003 often write to terminal with:
write(*,*)'The value of X is ',x
or
write(6,*)'The value of X is ',x
This is a problem when trying to debug with text output to terminal, especially where someone has used “6” for file I/O unit by mistake.
Or, if trying to write to a file with an uninitialized unit number, stderr gets redirected to file fort.0.
Print repeatedly to the same line, and combine prompt text on the same line with input.
iso_fortran_env terminal I/O: example prints to stdout, then stderr and finally asks for user input with a prompt on the same line.
programmytermuseiso_fortran_envimplicitnone(type,external)character(1000)::usertxt! 1000 is an arbitrarily large number
integer::ios! could also just use print *,'printed to stdout'
write(output_unit,*)'Printed to stdout'write(error_unit,*)'printed to stderr'! prompt with caret on same line as input, here using a greater than sign >
write(output_unit,'(A)',advance='no')' >'flush(output_unit)read(input_unit,"(A)",iostat=ios)usertxt! trap Ctrl-D EOF on Unix-like systems to avoid crashing program
if(ios/=0)backspace(input_unit)! ctrl D gobble
write(output_unit,*)usertxtendprogram
If stderr from error_unit gets written to a file fort.0 instead of being printed to screen, this is an indication of open(u)ing a file without first setting a value for u, which might default to 0.
Unless needing to persist a file opening between calls of a function/subroutine, normally open a file with newunit.
programmyfileuseiso_fortran_envimplicitnone(type,external)integer::u,ioscharacter(1000)::fn! 1000 is an arbitrarily large number
character(1000)::datprint*,"please input file to open"read(input_unit,'(a)',iostat=ios)fnif(is_iostat_end(ios))stop! open file, using better to ask forgiveness than permission principle
! status='old' means generate error if file doesn't exist
open(newunit=u,file=fn,status='old',action='read',iostat=ios)if(ios/=0)thenwrite(error_unit,*)'could not open file ',trim(fn)error stop'file IO error'endifread(u,'(A)')datprint*,'first two lines of ',trim(fn),' are:'print*,trim(dat)read(u,'(A)')datprint*,trim(dat)close(u)! implicitly closed at end of program, but as good practice...
endprogram
A new PC with different username cause two issues for WINE when copying old PC user files to a new PC.
If the Linux username changed, you have to update the “exec” lines of the .desktop files that reside in ~/.local/share/applications/wine/Programs/ (or create softlinks).
Sometimes the drive links in ~/.wine/dosdevices differ after copying.
Update your shortcuts/softlinks as necessary.
To use Z38XX GPS logging program on Linux via WINE, first
identify
which serial port the GPS is on.
Identify the WINE virtual serial port corresponding to the Linux serial port:
ls -l ~/.wine/dosdevices
if necessary
change WINE serial port mapping.
Start Z38XX.EXE and set Parameters → Serial Port to the port noted above.
Set baud rate–Jackson Labs GPS typically use 115200 baud by default.
Ulrich and Ina Bangert sadly have both passed away, and the website is maintained by a friend.
Regrettably, the source code for Z38XX is not known to be available, and so people have resorted to hex-editing the binary to adapt for new devices that would not otherwise work.
We are thankful for Ulrich’s service to the GPS/TimeNut/Amateur Radio/Radio Science community, and hope that other authors will consider open-sourcing their code to help the community even more.
Z38XX 2013-04-23 is the last known version from Ulrich.
A Windows PC that hasn’t been booted for months may get a black or blue error screen:
A component of your operating system has expired winload.efi
You will need to update to the latest version of Windows, after backing up your files.
In BIOS/UEFI, set the date to about the time your PC last worked.
If you’re not sure, set the date roughly 6-12 months into the past.
Reboot and Windows should start, but will note an expired version of Windows.
Windows will set the correct date automatically.
Copy off all your data to an external drive.
Don’t reboot!
Do the “force upgrade” below.
If this fails, you can recover non-encrypted (non-Bitlocker) data by copying your data off to USB or network drive with an
Ubuntu live USB stick
or pull the hard drive and copy files.