Scientific Computing

The Jetson Nano board has gone through several generations. Older Jetson Nano boards may be stuck on an older unsupported OS. If compatible with the specific Nano version hardware, the NVIDIA Jetpack SDK may be used to install a newer OS. Select a Jetson container suitable for the desired task and hardware.

Operating systems require a certain minimum ISA microarchitecture level to run for each CPU vendor family. The levels are arbitrarily defined by the vendor as a collection of features, for example AVX2 or AVX512.

A C++-based cpuid library can detect across operating systems if the Intel CPU supports a certain ISA level.

On macOS, Terminal commands can be specified to run with Rosetta using the arch command. This is useful for running or testing x86_64 software on Apple Silicon Macs. See “man arch” for more details.

arch -x86_64 <command>

For example to run cmake with Rosetta:

arch -x86_64 cmake -B build

The CMake variable CMAKE_SYSTEM_PROCESSOR or simply

arch -x86_64 uname -m

can be used to check the architecture of the current process.

A Fortran submodule may be defined in the same file or a different file than the Fortran module that uses the submodule. Meta-build systems such as CMake and Meson are aware that each Fortran compiler has distinct Fortran submodule naming conventions. Fortran module and submodule interface files are like generated header files.

The order of the commands for each compiler is significant and handled by the meta build system. The Fortran module must be built before the Fortran submodule to generate the necessary module interface files BEFORE compiling the submodule. Each compiler creates corresponding basic.o and basic_sub.o object files.

1. gfortran -c basic.90 creates object and module files: basic.o demo.mod demo.smod
2. gfortran -c basic_sub.f90 -o basic_sub.o creates object and submodule files: basic_sub.o demo@hi.smod
3. gfortran basic.o basic_sub.o -o basic creates executable basic

“module” are the files generated by step #1, building the file containing the Fortran module. “submodule” are the files generated by step #2, building the containing the Fortran submodule.

GCC Gfortran module and submodule naming convention is defined in module.cc by definintions “MODULE_EXTENSION” and “SUBMODULE_EXTENSION”. LLVM Flang module and submodule naming convention is defined in Semantics.

Example program

The table above is derived from the two-file example program:

file basic.f90

module demo
real, parameter :: pi = 4.*atan(1.)
real :: tau

interface
  module subroutine hello(pi,tau)
    real, intent(in) :: pi
    real, intent(out) :: tau
  end subroutine hello
end interface
contains
end module demo

program sm
use demo
call hello(pi, tau)
print *,'pi=',pi, 'tau=', tau
end program

file basic_sub.f90

submodule (demo) hi
contains
module procedure hello
  tau = 2*pi
end procedure hello
end submodule hi

Related:

• Fortran submodule reference
• Fortran module file format

The Fortran standard does not define a specific Fortran module file format. Each compiler vendor has a unique incompatible Fortran module file format. Fortran module files are not portable between different compilers or even different versions of the same compiler.

The per-compiler examples below assume Fortran source file “example.f90”:

module dummy

real, parameter :: pi = 4*atan(1.0)

contains

real function tau()
  tau = 2*pi
end function tau

end module dummy

LLVM Flang

The LLVM Flang .mod files generated are legal Fortran syntax – they are text files. The .mod format gives the version number.

Build:

gfortran -c example.f90

This generates Fortran module file “dummy.mod” and object file “example.o”.

Get the .mod file header:

head -n1 dummy.mod

The output starts like:

!mod$ v1

GNU Fortran (GFortran)

The GFortran header version is defined in module.cc as variable “MOD_VERSION”. GNU Fortran “gfortran” .mod files are GZIP and is not documented

Build a Fortran module source file like:

gfortran -c example.f90

This generates Fortran module file “dummy.mod” and object file “example.o”.

Extract the .mod file header like:

gunzip -c dummy.mod | head -n1

The output starts like:

GFORTRAN module version ‘15’ created from …

If you get:

gzip: not in gzip format

the .mod file is probably from another compiler vendor e.g. Intel oneAPI.

Intel oneAPI (ifx)

Intel oneAPI .mod files are a proprietary binary format. It is possible to determine the version of the .mod file by using od to look at the first 2 bytes of the .mod file.

od -N4 -d dummy.mod

The first number is like “13” and is the module format version. This version may change over time as oneAPI internals change. The second number is the update version, which is fixed at “1”.

NVHPC and AOCC

NVIDIA HPC SDK (NVHPC) and AOCC compilers generate .mod files that are text files. The format for legacy Flang module files is distinct from LLVMFlang Fortran module files.

Create the .mod file like:

nvfortran -c example.f90

# or

flang -c example.f90

generates a text file, beginning with the version number.

head -n1 dummy.mod

the output is like:

V34 :0x24 dummy

Cray Fortran

By default, Cray Fortran stores uppercase DUMMY.mod filenames. This can be made lowercase witht the ftn -ef flag. The Cray Fortran .mod format is proprietary, but the version number might be seen like:

ftn -c example.f90

head -n2 DUMMY.mod

Related: Fortran submodule file naming

Matlab function arguments since R2021a can use name-value pairs. GNU Octave already supported this syntax. This is a convenient way to pass optional parameters to functions. The syntax is:

myfun(Name1=Value1, Name2=Value2, ...)

where Name1, Name2, … are the names of the parameters and Value1, Value2, … are the corresponding values.

The previous syntax for optional parameters is still supported:

myfun("Name1", Value1, "Name2", Value2, ...)

The Pacman package manager by default says “checking available disk space” before installing or upgrading packages. This can take an excessively long time (especially on Windows with MSYS2) when a large number of packages are being installed or upgraded. To disable this behavior, edit the /etc/pacman.conf file and find and comment out:

#CheckSpace

In general for narrowband FM two-way PTT radio systems including amateur radio, FRS, GMRS, MURS and CB radio, using CTCSS / DCS is a means to allow a group or subgroup to communicate while not bothering others on a different squelch code. Coded squelch has the side effects of slightly reducing communication range and adding a slight delay to unmuting audio at the beginning of a transmission while the receivers decode the squelch code.

Coded squelch does NOT make communications private, as anyone without coded squelch can hear the audio–the subaudible tone is added to the voice audio, but does not scramble the audio.

Unless there is a specific need, users should generally use CTCSS to avoid unmuting delays and range loss that are noticeably worse with DCS. DCS is for crowded areas where range loss isn’t important, and where the user wants to avoid CTCSS interference from other users. By default use CTCSS unless you are really having a problem with not enough tones to pick from. DCS is a last resort.

Historically, lower frequency CTCSS tones had a longer unmute delay, but modern radios minimize this impact. Avoid tones that are near harmonics of the AC mains frequency in the area (50 Hz or 60 Hz typically).

In particular, CB Radio use among family groups and convoys is dramatically improved by using CTCSS to avoid interference from other users and “skip” on the 27 MHz band from users hundreds or thousands of miles away. CTCSS also avoids nuisance opening of squelch from power lines, computers, etc.

Particular to CB radio, the receiver may have an RF gain control that can be used to reduce the sensitivity of the receiver to avoid interference from strong signals. With CTCSS, one might leave the RF Gain on “auto” or maximum (“off” on Anytone family of radios) and use auto noise squelch “ASQ” to maximum communication range while protected from noise by coded squelch.

Sub-$100 CB radios that have CTCSS include the Radioddity CB-500 and the Radioddity CS-27. Anyone buying CB radio for family, group, or convoy use should strongly consider a CB radio with CTCSS.

Reference: very detailed history of subaudible squelch by Repeater Builder.

Intel oneAPI LLVM sanitizers complement tools like Valgrind.

A CMake CTest script like memcheck.cmake can be used with oneAPI or Valgrind to run sanitizers on projects.

For example:

ctest -DCTEST_MEMORYCHECK_TYPE=AddressSanitizer -S memcheck.cmake -V

Matlab buildtool has become a capable build system for tasks including MEX targets and tests with incremental progress, which avoids the need rerun already completed tasks. A standalone buildtool example illustrates the basic use of Matlab buildtool.

Run the build and test tasks:

buildtool mex

buildtool test

See several additional examples of more advanced Mex and Matlab Engine tasks. Matlab-stdlib is another substantial example of buildfile.m usage.