I'm interested in getting system information through Fortran - categories may include:
Operating system name
Operating system version
CPU architecture (32/64-bit)
Number of cores
It's my understanding that you can get basic OS information through preprocessing directives, such as
#ifdef _WIN32
print *,'Windows'
#ifdef _APPLE_
print *,'macOS'
#ifdef __linux
print *,'Linux'
#endif
This is a working solution for category 1, but still leaves 2 - 4.
Thanks!
You can kinda do all that stuff in Fortran, except not really. The COMPILER_VERSION() string from the ISO_FORTRAN_ENV module should provide the name of the OS at least. From that you know what procedures to invoke to get further information.
program test
use ISO_C_BINDING
use ISO_FORTRAN_ENV
implicit none
integer, parameter :: bitness = bit_size(0_C_INTPTR_T)
write(*,'(*(g0))') 'This is a ',bitness,'-bit system.'
write(*,'(*(g0))') COMPILER_VERSION()
end program test
Here's my output with gfortran:
This is a 64-bit system.
GCC version 7.2.0
So gfortran isn't very helpful. I consider that to be a bug. ifort doesn't have COMPILER_VERSION() at all; maybe that's just because I have old versions of both compilers. Anyway, if you could get the OS from the COMPILER_VERSION() string, you would know how to load useful functions like LoadLibrary and GetProcAddress in Windows. Then you create parameters that have the names of the OS procedures you want if you have the right OS and the name of a stub procedure if not.
logical, parameter :: v0 = index(v5,'WINDOWS') /= 0
character(*), parameter :: v6 = merge('LoadLibraryA','Stub12345678',v0)
interface
function LoadLibrary(lpFileName) bind(C,name=v6)
import
implicit none
!DEC$ ATTRIBUTES STDCALL :: LoadLibrary
!GCC$ ATTRIBUTES STDCALL :: LoadLibrary
integer(C_INTPTR_T) LoadLibrary
character(kind=C_CHAR) lpFileName(*)
end function LoadLibrary
end interface
That way you can access LoadLibrary if you're in Windows and not cause an unsatisfied external reference if not. Unfortunately gfortran doesn't think having a named constant rather than a character literal for the binding name is valid.
But in principle you can use the compiler to tell you the OS name and set up a few critical functions you need to beg the OS for the rest of the stuff, but it needs a more advanced compiler than I've got. If you have a better compiler I could edit in more stuff and you could see if it crashes on your end.
Once you finished point 1 in the way you showed in the question you can go on for the other points.
In POSIX systems (including Linux) you can execute
uname -a
to get the OS name and version information like
Linux meop37 4.4.104-18.44-default #1 SMP Thu Jan 4 08:07:55 UTC 2018 (05a9de6) x86_64 x86_64 x86_64 GNU/Linux
you can store this in a file and read the file Fortran (just redirect stdout).
In Linux you can read /etc/os-release to find out the OS version.
In my case it includes:
NAME="openSUSE Leap"
VERSION="42.2"
ID=opensuse
...
In Linux you can read /proc/cpuinfo to get a lot information about the CPU (including those you request). It is your responsibility to parse it somehow in Fortran.
In my case it contains:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3770 CPU # 3.40GHz
stepping : 9
microcode : 0x1c
cpu MHz : 1693.800
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
...
I have zero knowledge about MS Windows. Your question is very (too?) broad so I think answering just a part of it is acceptable.
I give answer for architecture and detail system information in Windows 10. (maybe it can work in other Windows systems.)
program info
implicit none
print*,'detail system information: (on Windows 10)'
call system('SystemInfo')
print*
read(*,*)
print*,'system architecture:'
call system('wmic OS get OSArchitecture')
print*
end program
I used help from to obtain architecture. Generally subroutine call system(String_variable) starts up cmd line and get system commands. Similar way it starts up terminal in Ubuntu and get shell commands. (System commands are obviously different for different operation systems.)
Related
Is there any possibility to launch an external program from Fortran and write something to this programs standard input?
I know e.g. of gfortran's SYSTEM but there is no such option.
As you have noticed, GFortran does not have anything like the pipe()/fork()/exec() functions builtin.
If you're on Linux or some other Unix-like system you could do something like
execute_command_line("mkfifo /path/to/fifo")
The mkfifo command creates a named pipe, that is, a pipe that also has a name in the filesystem.
open(newunit=plot_unit, file="/path/to/fifo", access="stream", format="formatted")
execute_command_line("gnuplot < /path/to/fifo")
So the idea is that you can then open the FIFO like a normal external unit in GFortran, then execute gnuplot with standard input connected to the FIFO.
You might need to exchange the order of #2 and #3 in case this deadlocks. But some minor variation of the above should work (I've used it to connect to one Fortran program from another).
Firstly, if you're using a relatively recent compiler you should be able to use execute_command_line (part of the f2008 spec) instead of system (compiler extension). This launches a command using the C library's system call which uses the sh shell on nix and cmd.exe on Windows (see here). As such you can use standard input redirection type approaches to connect to stdin of the launched program, but it may not be suitable for more complicated use.
The following example shows a simple example
program stdIn
implicit none
character(len=20) :: cmd, args
character(len=50) :: fullcmd
cmd = "bc"
args = "1+2"
fullcmd = cmd//" <<< "//args
print*,"Running ",fullcmd
call execute_command_line(fullcmd)
end program stdIn
Which should output
Running bc <<< 1+2
3
This one's going to take a bit of explaining. Please bear with me.
What I Have
I have in my possession some Fortran source code and some binaries that have been compiled from that code. I did not do the compilation, but there is a build script that suggests G77 was used to do it.
As well as the Fortran stuff, there is also some Java code that provides users with a GUI "wrapper" around the binaries. It passes information between itself and the binaries via their input/output/error pipes. The Java code is very messy, and this way of doing things adds a lot of boilerplate and redundancy, but it does the job and I know it works.
What I Need
Unfortunately, I'd like to make some changes:
I want to create a new Python wrapper for the binaries (or, more precisely, extend an existing Python program to become the new wrapper).
I want to be able to compile the Fortran code as part of this existing program's build process. I would like to use gfortran for this, since MinGW is used elsewhere in the build and so it will be readily available.
The Problem
When I compile the Fortran code myself using gfortran, I cannot get the resulting binaries to "talk" to either the current Java wrapper or my new Python wrapper.
Here are the various ways of printing to the console that I have tried in the Fortran code:
subroutine printA(message)
write(6,*) message
end
subroutine printB(message)
write(*,*) message
end
subroutine printC(message)
use iso_fortran_env
write(output_unit,*) message
end
There are also read commands as well, but the code doesn't even get a change to execute that part so I'm not worrying about it yet.
Extra Info
I have to call gfortran with the -ffixed-line-length-132 flag so that the code compiles, but apart from that I don't use anything else. I have tried using the -ff2c flag in the vague hope that it will make a difference. It doesn't.
This stackoverflow post is informative, but doesn't offer me anything that works.
The relavant manual page suggests that printA should work just fine.
I'm working on Windows, but will need this to be multi-platform.
Juse in case you're intested, the Java code uses Runtime.getRuntime().exec("prog.exe") to call the binaries and then the various "stream" methods of the resulting Process object to communicate with them. The Python code uses equivalents of this provided by the Popen object of the subprocess module.
I should also say that I am aware there are alternatives. Rewriting the code in Python (or something else like C++), or making amendments so that is it can be called via F2Py have been ruled out as options. Using g77 is also a no-go; we have enough dependencies as it is. I'd like to be able to write to / read from the console properly with gfortran, or know that it's just not possible.
Hard to say without seeing more details from your Fortran and Python codes. The following pair of code works for me (at least under Linux):
Fortran program repeating its input line by line prefixed with line number:
program test_communication
use iso_fortran_env, stdout => output_unit, stdin => input_unit
implicit none
character(100) :: buffer
integer :: ii
ii = 1
do while (.true.)
read(stdin, *) buffer
write(stdout, "(I0,A,A)") ii, "|", trim(buffer)
flush(stdout)
ii = ii + 1
end do
end program test_communication
Python program invoking the Fortran binary. You can feed it with arbitrary strings from the console.
import subprocess as sub
print "Starting child"
proc = sub.Popen("./a.out", stdin=sub.PIPE, stdout=sub.PIPE)
while True:
send = raw_input("Enter a string: ")
if not send:
print "Exiting loop"
break
proc.stdin.write(send)
proc.stdin.write("\n")
proc.stdin.flush()
print "Sent:", send
recv = proc.stdout.readline()
print "Received:", recv.rstrip()
print "Killing child"
proc.kill()
I'm in the process of adding an option to a Fortran program to run it using multiple processors using MPI. If the user is going to run it in parallel, the user needs to specify different input files---one file for each domain (processor) of the problem. The program will look for a specific filename by default (a file called "serial.inp"). So I need the program to know when it is being run in parallel so that it can instead look for the other filenames instead (e.g. "parallel_1.inp", "parallel_2.inp", "parallel_3.inp", etc.). My first thought is to have the user pass an argument to the program when they execute it, e.g.:
mpiexec -n 4 myprogram.exe -parallel
This way, it will look for the parallel files when that argument is present. But it seems kind of redundant. If the program is being called with mpiexec, there is no question that the user is attempting to run it in parallel. Is there any way that my program will know it was started using mpiexec? Or is the command line argument my best bet?
Alex Leach is right in that you can do this with MPI-implementation-specific environment variable lookups, but there's no portable way to do this.
But as I understand, I don't think you really need to; you can get most of what you want with just checking to see if it was run with one rank:
program filenames
use mpi
implicit none
integer :: comsize, rank, ierr
character(len=128) :: inputfilename
call MPI_Init(ierr)
call MPI_Comm_size(MPI_COMM_WORLD,comsize,ierr)
call MPI_Comm_rank(MPI_COMM_WORLD,rank,ierr)
if (comsize == 1) then
inputfilename = 'serial.inp'
else
write(inputfilename, '(A,I0,A)'), 'parallel_',rank,'.imp'
endif
write(*,'(I,1X,A)'), rank, trim(inputfilename)
call MPI_Finalize(ierr)
end program filenames
Running gives
$ mpirun -np 4 ./filenames
0 parallel_0.imp
1 parallel_1.imp
2 parallel_2.imp
3 parallel_3.imp
$ ./filenames
0 serial.inp
That's not perfect; it'll give the serial result if you run using mpirun -np 1 filenames, but depending on your use case that may not be a terrible thing in exchange for having something portable.
Processes run with mpiexec will have various environment variables set, indicating to the subprocesses whether they are the master process or slaves, amongst other things.
Look in your mpiexec's documentation for specific details. Microsoft have some documentation online too.
Why not do it programmatically? This is how I do it in my program:
#ifdef MPI
CALL MPI_Init(ierr) ! Initialize MPI
CALL MPI_Comm_rank(mpicomm,nproc,ierr) ! Who am I?
CALL MPI_Comm_size(mpicomm,size,ierr) ! How many processes?
#else
nproc = 0
size = 1
#endif
After this point in the program, you can inquire whether the program is serial or parallel by inquiring the value of size.
I want machine unique id such as processor id, hdd id, uuid of MAC PC through c++ program.
Can anyone please tell me how it implements?
Thanks.
only about 7 years later, but here's an answer to those stumbling across this that we've been using.
It uses the IOPlatformExpertDevice class to access the Mac Serial number/hardware uuid
There are two ways to do this, the first uses C++, the second python. I have personally used the second way, and can verify it fetches the hardware uuid as given by System Information.
First method, not tested by myself, but uses the same class so has at least the potential to work, see https://gist.github.com/tmiz/1294978 for a routine in C++ on how to retrieve the "serial number" which is not be the same as the hardware uuid from system information, but from some tweaking, you should be able to get the hardware uuid.
Second method (see python code below), in python, which uses the ioreg command, which is executed via a separate process, then the results processed with a regular expression to get the uuid. This method definitely retrieves the hardware uuid as I've checked it with the System Information app in macos 10.14 and previous versions of 10.13 and 10.12.
May these methods serve you well, they do not return the mac address and as such should function well as a uuid for the machine, not just the network interface.
Finally you can read about ioreg here -> http://www.manpagez.com/man/8/ioreg/ and the I/O Kit more generally here -> https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Families_Ref/Families_Ref.html#//apple_ref/doc/uid/TP0000021-BABHIGFE
import platform, re, os
os_type = platform.system()
if os_type == 'Darwin':
machine_uuid_str = ''
p = os.popen('ioreg -rd1 -c IOPlatformExpertDevice | grep -E \'(UUID)\'', "r")
while 1:
line = p.readline()
if not line: break
machine_uuid_str += line
match_obj = re.compile('[A-Z,0-9]{8,8}-' +\
'[A-Z,0-9]{4,4}-' +\
'[A-Z,0-9]{4,4}-' +\
'[A-Z,0-9]{4,4}-' +\
'[A-Z,0-9]{12,12}')
results = match_obj.findall(machine_uuid_str)
return results[0]
Outside of a few ancient processors, x86 CPUs do not have software-visible serial numbers.
Apple recommends that you use the MAC address of the computer's primary network interface (i.e, the onboard Ethernet controller if present, or the wireless interface otherwise) as a unique identifier for the system. Sample code for doing this is available in Apple's Validating Mac App Store Receipts documentation (under "Get the Computer's GUID").
Using the ICU library with C++ I'm doing:
char const *lang = Locale::getDefault().getLanguage();
If I write a small test program and run it on my Mac system, I get en for lang. However, inside a larger group project I'm working on, I get root. Anybody have any idea why? I did find this:
http://userguide.icu-project.org/locale/resources
so my guess is that, when running under the larger system, some ICU resources aren't being found, but I don't know what resources, why they're not being found, or how to fix it.
Additional Information
/usr/bin/locale returns:
LANG="en_US.ISO8859-1"
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL="C"
If I write a small C program:
char const *lang = setlocale( LC_ALL, "" ):
I get en_US.ISO8859-1.
OS: Mac OS X 10.6.4 (Snow Leopard)
ICU version: 4.3.4 (latest available via MacPorts).
A little help? Thanks.
root is surely an odd default locale - you don't see many native root-speakers these days.
But seriously, is it safe to assume on the larger system that someone hasn't called one of the variants of setDefault("root")?
What does something like /usr/bin/locale return on this system (if you can run that)?
ICU 4.4 now has a test program called 'icuinfo', does it also return root as the default locale?
What OS/platform is this on, and which version of ICU?