Page-wide figures in two-column articles

Here's the problem I had:

I was writing an article for Phys. Rev. Lett. using APS' RevTeX 4.1 package.
I needed to include a figure that required the full two-column space.

Solution:

I used the \begin{figure*} ... \end{figure*} environment.
The other possibility is to enclose the standard figure environment into the widetext one.
The latter is usually adopted for including math environments with very long equations that
cannot be contained in a single column space, unless being cut.
The disadvantage of the widetext environment is that it breaks the two-column layout with a couple of horizontal lines showing where the full page part begins and ends.

Better to use the figure* environment.

Install RevTex 4.1 into MikTeX 2.8

RevTeX's latest version is 4.1 up to today.
If you want to install it under MikTeX 2.8, here there's the recipe as found from RevTeX 4.1
README file:

Installation ------------ You already started the installation process by unzipping revtex4-1.zip. As you will have seen, it created a directory revtex4.1
containing this file README, the file DOWNLOAD, and the file revtex4-1-tds.zip, which contains the bulk of the installation.  To install this software
into a TDS-compliant TeX installation, like TeX Live, working as root, issue a shell command like

unzip revtex4-1-tds.zip -d /usr/local/texlive/texmf-local/

where the destination for the unzipped files is, in this example, appropriate for a local modification of a sufficiently recent distribution of TeX Live.
You may of course choose a different destination depending  on your particular requirements. After installation, files will be located as per the
Manifest above. Run the appropriate update command (mktexlsr, initexmf -u, etc.); under TeX Live that would be (as root)

mktexlsr /usr/local/texlive/texmf-local

Install required packages (AMS-LaTeX, natbib, textcase, and bm).
Please consult the documentaton for your local TeX package for more information.
MikTeX users should use a recent version (see http://miktex.org/) and consult the documentation there. There are several steps you will have to do.
Please note that the steps given here may change with future versions of MikTeX, but the basic steps should be quite similar.

1) Create a texmf-local directory if needed. For example, you might create a directory such as C:\local\miktex\texmf-local.

2) Tell MikTeX where your texmf-local directory is. Find the MikTeX Options window and look for the "Roots" tab. If your texmf-local directory
is not listed, click "Add" and add it.

3) Unzip the revtex4-1-tds.zip (part of the REVTeX distribtution) in your texmf-local directory.

4) Update the "File Name Database (FNDB)." This step is essential and it registers all of the files in your texmf-local directory with MikTeX.
Do this by clicking on "Refresh FNDB" in the General tab of the MikTeX Options window.

MikTex also comes with a package manager. This can be an easier way to maintain the packages installed on your system.
However, please note that the packages available may not be the most current version of the packages.

Some remarks:

MikTex Options window can be opened by Start -> Programs -> MikTex 2.8 -> Maintenance -> Settings
and choosing the Roots tab.

How to change font size in PuTTY

PuTTY is one of the most known telnet/SSH clients for the MS Windows environment.

I use it on a daily basis for connecting, via the SSH protocol, to the compute clusters I use for my job, from my (unfortunately) MS Windows desktop computer.

One trivial but highly frequent configuration issue happening when installing PuTTY on a new machine consists in how to setup the wanted font size for your SSH terminal, such that you do not get blind trying to read what's on your remote machine screen.

Here there are the simple instructions for such configuration:

http://www.cam.ac.uk/cs/docs/faq/q3.html

Current work directory in Matlab at startup time

I use Matlab on a daily basis for the post-processing and preliminary visualization of my simulation datasets.

Every time I upgrade Matlab to a newer version I face the following issue:

when Matlab starts, the current work directory is set to a default value, inside Matlab directory tree itself.

This default directory is of no use for me. Usually, I prefer to have as current work directory at startup time the one with which I've been working most recently.

To setup your preferred current work directory at startup time, you just need to run once the command

userpath('my preferred current work directory')

Next time you run Matlab, it will automatically setup your chosen directory as the current work one.

If you run Matlab via an shortcut icon on your desktop, under MS Windows, just be sure that the "Start in" field of the shortcut is empty (see image below) otherwise the directory you chose and setup via the userpath(...) command will be overwritten by the one inserted in the shortcut's "Start in" field.

Visualizing force chains out of ESyS-Particle simulations: fcconv

I report here my initial experience in visualizing force chains out of numerical simulations of sheared granular layers using ESyS-Particle.
In ESyS-Particle 2.0, there is a post-processing tool called fcconv that can help you with doing that. Its logic is similar to dump2vtk's one.

Let's start with the basics.

Where can you find fcconv ?
The program itself is in ESyS-Particle's binary directory. Its source code is in

<ESyS-Particle source tree>/Tools/ForceChains .

What's its command line ?

fcconv -i < input filename > -o < ouput filename >

-vvf -vtk ,

where <

input filename

> is the input filename,

<

output filename

> is the output filename, the option -vvf is used if you want an output file in a format readable with Itasca's PFC2D(3D) DEM software while -vtk it's used if you want an output file in VTK-XML format.
You can use either -vvf or -vtk or both.

The output file is an unstructured grid constituted by points and cells.
The points are centers of particles belonging to couples of interacting particles, where the interaction is of a specific type (see below). The cells are type=3 VTK cells, i.e., lines, connecting these couples of particles. Associated to the cells there is a DataArray attribute, as it is called in VTK language, specifically, a scalar. This scalar variable corresponds, in the simulation, to the norm of the interaction force acting on one of the two particles, for each couple of interacting particles.
If you wanted the output files in VTK-XML format, such that you could read them in with Paraview, it would be useful to define the file name suffix as .vtu, to remind Paraview that it is a VTK unstructured grid dataset file in XML format. Otherwise you have to specify to Paraview which type of dataset you are importing.

The input file is the output of a specific FieldSaver used inside your ESyS-Particle simulation script. This output refers to a specific time step of the simulation.
That means that, contrary to dump2vtk which manages multiple snapshots in time, you have to use fcconv inside a for loop to convert multiple snapshots in time into the corresponding VTK unstructured grid datasets.

Each input file is an ASCII file and contains the following information (for a specific time step) :

• each line corresponds to a couple of particles interacting with each other according to a specific interaction type, whose name is specified as a member of the FieldSaver object; this interaction shall be either RotFriction or NRotFriction, so a pure frictional, repulsive, contact force;
  

• each line contains 14 fields, each one separated by a blank space from the following one.

The fields (observables) are the following:

1. particle #1's X coordinate
2. particle #1's Y coordinate
3. particle #1's Z coordinate
4. particle #1's radius
5. particle #2's X coordinate
6. particle #2's Y coordinate
7. particle #2's Z coordinate
8. particle #2's radius
9. contact point between particle #1 and particle #2, X coordinate
10. contact point between particle #1 and particle #2, Y coordinate
11. contact point between particle #1 and particle #2, Z coordinate
12. contact force's X component
13. contact force's Y component
14. contact force's Z component

The FieldSaver that produces such files is the following one:

InteractionVectorFieldSaverPrms(
interactionName = "friction",
fieldName = "force",
fileName = "/pool2/grm118/ShearFaultGouge2DEx3_33/ContactForce",
fileFormat = "RAW2",
beginTimeStep = 0,
endTimeStep = nt,
timeStepIncr = 500
)

In this example, friction is the name of an interaction group of type RotFriction.
The fieldName indicates that we want to record the full interaction force for each couple of particles subject to this type of interaction. You can choose also fieldName = normal_force and only the projection of the interaction force along the direction passing through the two particles' centers will be recorded.
fileFormat has to be = RAW2 if you are using ESyS-Particle 2.0. I tried to use

fileFormat = RAW_SERIES, like for other FieldSavers, but it did not work. Maybe it's something related to ESyS-Particle's previous versions.
timeStepIncr indicates the time step in between two successive files. It's the sampling time step.
fileName is the FieldSaver's output filename prefix. The program actually add to that prefix a .n.dat suffix, where n is a increasing counter numbering the files (n = 0,1,2,...).
This means that each output filename does not track the simulation time step it refers to.

The VTK-XML unstructured grid dataset files (one for each recording time step) allows you to visualize the contact force network as a network of solid "beams", each one with the same thickness, but with different color scaled according to the scalar attribute, the norm of the contact force.
This contact force network visualization is not the best one: in the literature, you can find several simulation works showing force chains represented as cylindrical beams of different colors AND thicknesses, both scaled according to the value of the norm of the contact force.
However, it's still a useful pictorial representation of contact forces.

For more information, see threads #91547 and #92702 at ESyS-Particle launchpad Web site.

-------------------------------------------------------------------------------------------------
Disclaimer

This post is based on the author's personal experience in using the ESyS-Particle Discrete Element Method code.
This post should not be considered as an official document about the code itself.
This post does not come with any warranty about the correctness of its content.
If you find any error in the content, please write to the author.
-------------------------------------------------------------------------------------------------

SSH login welcome message

Here there is a very simple tip for changing the initial message appearing on the shell terminal of a user connecting via SSH to the front-end node of a Linux cluster.

• Modify with whatever text editor you prefer the /etc/motd file
  

Simple ASCII text files: from MS Windows to Linux

Here there is something so trivial that it'll be considered too much trivial for a real Linux geek.
However, since I'm not a Linux hyper-geek, I like to report the following. I think it'll turn out to be useful for not wasting time around for such a small detail.

State of the problem:

• I edit a simple ASCII text file under MS Windows, for example a PBS script to run a parallel job on a compute cluster.

• I move the file to the cluster, which, of course, runs Linux

• I submit the script, via the qsub command. Bash is the shell interpreter in this case. It gives me the following error: ^m command not found

What the hell is going on ?
You may say: "of course, buddy, you're trying to mess up editing files in one environment and running them in another". Well, when your institution makes you use MS Windows for simple desktop computing, there is nothing you can.

Actually, you can do the following:

when the file is on the Linux machine (the front-end node of the cluster, for example), before running it pass it through the dos2unix command. It's a very nice program for converting a text file formatted under DOS/MAC into a text file format for the Unix environment.