Archive for April, 2010


In a set of posts, I plan to show the activity level of Perseids and Leonids meteor showers in past ten years. I start this series with Perseids 2000. All data were taken from IMO webpage. I try to provide a short description of event if available.

Apart from the traditional maximum at a solar longitude of 140.0 degrees, a pre-maximum peak has been observed for more than 10 years with variable strength. For the first time after the return of the parent comet 109P/Swift-Tuttle, the 2000 Perseids do not show this early peak. The traditional maximum of the Perseids was well pronounced in 2000.  A rough estimate of the Zenith Hourly Rate (ZHR)  is about ZHR=110-120.

Read Full Post »


Subversion (SVN) is a version-control system. Developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. As a Linux user, I try to present my (limited) experience in constructing a repositoty and using subversion.

Installation: as trivial as you can imaging; go to synaptic in Debian/Ubuntu or your favorite package manager and search for svn. Alternatively, you can use apt-get to find it.

Create a svn repository

$svnadmin create –fs-type fsfs /home/user/svn

use absolute path.

Import an existing directory into the repository?

Assume we have an existing project in /your_home/project/

$svn import /your_home/project/ file:///home/user/svn/project/trunk -m ‘Initial import’
-m stand for log message, the first revision was created with log as “Initial import”. You need to specified URL for the repo, URL is the standard argument for svn. Therefore for local file, you need to specified with file://

Checking out a project

$cd /path/to/project
$cd ..
$rm -rf project
$svn checkout file:///home/user/svn/project

After that command, a version-controlled copy of the project is now available in /path/to/project. This can be verified by the presence of a .svn directory in there.

This can also be checked by the command svn info
$svn info

Working with the project (part 1: editing and adding files)
Now that our project is safely under version controlled, we can start making it evolve. First, we add another two files defining a class. Then we change main.cpp to use that class and Makefile to compile them. Use your favorite editor (no flame here). After that, we can check the status of our project :
$cd /path/to/project/trunk/
$svn status
?      src/class.cpp
M      src/main.cpp

Note first that the output of Svn status is very human readable (CVS users know what I mean). We can clearly see that there are 3 unknown files (?) and two modified files (M). Let’s add the two files that we indeed want to version control :
$cd /path/to/project/trunk/
$svn add src/class.h src/class.cpp
A         src/class.h

You can redo a svn status if you want but I am sure you already know what the output will look like. For the two files we added, the question mark will now be a A. Now that you have done these modifications, that you have checked everyting compiles, you decide to commit these changes :
$svn commit -m ‘Use a class to print hello world’
Sending        trunk/src/Makefile
Adding         trunk/src/class.cpp
Adding         trunk/src/class.h

Note the clarity and conciseness of the output. New files have been added, modified files have been send.

I am going to checkout to the same folder. For security, you may want to backup the directory first.

$mv programming programming-a

Now checkout to programming, mkdir is not needed, as svn will create the directory for you if it is doesn’t exist.

svn co file:///home/mysurface/repo/programming_repo programming

co is the shortform of checkout.

How to see what is inside the repo?

$svn list file:///home/mysurface/repo/programming_repo


$svnlook tree programming_repo

The difference between svn list and svnlook tree is one expect URL another one do not.

Single file can’t be checkout like directories, but you can extract them from repository by svn export

$svn export file:///home/mysurface/repo/programming_repo/c/curses/matrix.cc
How to track the changes before commit to repo?
First of all, you track what files had changed,

$svn status

How to update the working directory into the latest revision?

svn update

Update to specific revision?

svn update -r 3

go to a working directory:

micropore@home:~/prog>svn status

M file1 — File was modified
? file2 — File not under version control
! file3 — File is missing
A file4 — File is scheduled to addition
D file5 — File is scheduled for deletion
R file6 — File is scheduled for replacement
C file7 — File has conflicts

Note : svn status produces no report for unchanged files.

The command svn status has several command switches. Probably the most usefull is

svn status -u

which compares the content of the directory (and its sub-directories) with the current content of the
repository. Files that where changed in the repository since your last checkout or update operation are
reported with an asterisk:
M * file1 — File was modified in the repository and your dirctory
M   file2 — File was modified in your dirctory only
* file3 — File was modified in the repository only

In effect, all files marked with an asterisk will be affected by a following svn update.

To update a complete directory and its sub-directories, go to the dirctory and type :

$svn update

this will check for commited updates on the Subversion server and merge them to your local files. On the
command output you have a quick look on what has been done to your files:
U file1 — existing file was updated from repository
A file2 — non-existing file was added from repository
D file3 — existing file was deleted, because not longer in repository
R file4 — existing file replaced by different file with the same name
G file5 — changes from repository where successfilly merged into existing modified file
C file6 — changes from repository could not be merged into existing modified file

You can also update a single file or group of file using

$svn update [filename]

Editing a file

Before editing a file, you should be sure to work on an updated version. Edit the file with your favorite

At this stage, you can use

$svn status

to check the status of all files in a directory. {{svn status}} reports for all modified files a status
code, the most important are:
A file1 — file was added
C file2 — file is in conflict with repository
D file3 — file was deleted
M file4 — file was modified
R file5 — file was replaced
? file6 — file is not under version control
Once you have finish editing, you can send your changes to the repository using

to add a file:

$svn add filename[s]

$svn commit –message “YourMessage”

If you want to revert to the version in the repository, thereby loosing your changes, use

$svn revert [filename]

In the context of Subversion, conflict means that a file’s version in your working directory and the
version in the repository have both been changed since the last update and that these changes overlap.
Such a conflict has to be resolved manually before the file can be comitted to the repository.

When a conflict occurs, the following things will happen during an update:

*The update command will print a C close to the filename.

* Subversion will place conflict markers in the working copy of the file to highlight the conflicting
parts of the file.

* Subversion will place a file [filename].mine in your working directory that is a copy of filename
before you issued the update command.

* Subversion will place two additional file [filename].r[oldrev] and [filename].r[newrev] in your
working directory. These files are copies of the file in the repository that you received with your last
update command and of the current version in the repository.

These copies are meant to assist you in resolving the conflict.

After you have resolved the conflict, let Subversion know it by typing

$svn resolve [filename]

This will delete the three temporary files. After that, you can commit your changes as usual:

$svn commit [filename]

Adding, deleting, copying, and moving files

Shortlist of  commands
svn add [filename]
svn delete [filename]
svn copy [filename] [newFilename]
svn move [filename] [newFilename]
and commit the new file(s).

a cheat-sheet svn-ref

Read Full Post »

The Fortran compiler supports several kinds of floating-point exceptions; a summary of their masked (or default) responses is given below:

The -fpen option allows some control over the results of floating-point exceptions.

-fpe0 restricts floating-point exceptions as follows:

  • Enables the overflow, the divide-by-zero, and the invalid floating-point exceptions. The program will print an error message and abort if any of these exceptions occurs. If a floating-point underflow occurs, the result is set to zero and execution continues. This is called flush-to-zero. This option sets -IPF_fp_speculationstrict  if no specific -IPF_fp_speculation option is specified.  The -fpe0 option sets -ftz. To get more detailed location information about where the exception occurred, use -traceback.

-fpe1 restricts only floating-point underflow:

  • Floating-point overflow, floating-point divide-by-zero, and floating-point invalid produce exceptional values (NaN and signed Infinities) and execution continues. If a floating-point underflow occurs, the result is set to zero and execution continues. The -fpe1 option sets -ftz.

-fpe3, the default, allows full floating-point exception behavior:

  • Floating overflow, floating divide-by-zero, and floating invalid produce exceptional values (NaN and signed Infinities) and execution continues. Floating underflow is gradual:  denormalized values are produced until the result becomes 0.

The -fpe option affects the Fortran main program only.  The floating-point exception behavior set by the Fortran main program remains in effect throughout the execution of the entire program unless changed by the programmer. If the main program is not Fortran, the user can use the Fortran intrinsic FOR_SET_FPE to set the floating-point exception behavior.

When compiling different routines in a program separately, you should use the same value of n in -fpen.

An example follows:


real*4 res_uflow, res_oflow

real*4 res_dbyz, res_inv

real*4 small, big, zero, scale

small = 1.0e-30

big   = 1.0e30

zero  = 0.0

scale = 1.0e-10

!      IEEE underflow condition (Underflow Raised)

res_uflow = small * scale

write(6,100)”Underflow: “,small, ” *”, scale, ” = “, res_uflow

!      IEEE overflow condition (Overflow Raised)

res_oflow = big * big

write(6,100)”Overflow: “, big, ” *”, big, ” = “, res_oflow

!      IEEE divide-by-zero condition (Divide by Zero Raised)

res_dbyz = -big / zero

write(6,100)”Div-by-zero: “, -big, ” /”, zero, ” = “, res_dbyz

!      IEEE invalid condition (Invalid Raised)

res_inv = zero / zero

write(6,100)”Invalid: “, zero, ” /”, zero, ” = “, res_inv

100   format(A14,E8.1,A2,E8.1,A2,E10.1)


Consider the following command line:

$ ifort fpe.f -fpe0 -g

The following output is produced:


Underflow:  0.1E-29 * 0.1E-09 =   0.0E+00

forrtl: error (72): floating overflow

Image       PC        Routine     Line        Source

a.out       0804A063  Unknown     Unknown  Unknown

a.out       08049E78  Unknown     Unknown  Unknown

Unknown     B746B748  Unknown     Unknown  Unknown

a.out       08049D31  Unknown     Unknown  Unknown


The following command line uses -fpe1:

$ifort fpe.f -fpe1 -g

The following output is produced:


Underflow:  0.1E-29 * 0.1E-09 =   0.0E+00

Overflow:  0.1E+31 * 0.1E+31 = Infinity

Div-by-zero: -0.1E+31 / 0.0E+00 = -Infinity

Invalid:  0.0E+00 / 0.0E+00 = NaN

The following command line uses -fpe3:

$ifort fpe.f -fpe3 -g

The following output is produced:


Underflow:  0.1E-29 * 0.1E-09 =   0.1E-39

Overflow:  0.1E+31 * 0.1E+31 = Infinity

Div-by-zero: -0.1E+31 / 0.0E+00 = -Infinity

Invalid:  0.0E+00 / 0.0E+00 = NaN

see also

Read Full Post »