1 Troubleshooting / Frequently Asked Questions
1.1 Download and setup
1.1.1 Download forbidden
A: Both Google Code and SourceForge are banned from countries on the United
States Office of Foreign Assets Control sanction list, including Cuba, Iran, Libya,
North Korea, Sudan and Syria; see http://en.wikipedia.org/wiki/Google_Code and
http://en.wikipedia.org/wiki/SourceForge. As a remedy, you might download a tarball from
http://pencil-code.nordita.org/; see also Section ??.
1.1.2 When sourcing the ‘sourceme.sh’/‘sourceme.csh’ file or running pc_setupsrc, I get error
messages from the shell, like ‘if: Expression Syntax.’ or ‘set: Variable name must begin with a
A: This sounds like a buggy shell setup, either by yourself or your system administrator
— or a shell that is even more idiosyncratic than the ones we have been working
To better diagnose the problem, collect the following information before filing a bug report to
- uname -a
- /bin/csh -v
- echo $version
- echo $SHELL
- ps -p $$
- If you have problems while sourcing the ‘sourceme’ script,
- unset the PENCIL_HOME variable:
for csh and similar:
- unsetenv PENCIL_HOME
for bash and similar:
- unexport PENCIL_HOME; unset PENCIL_HOME
- switch your shell in verbose mode,
for csh and similar:
- set verbose; set echo
for bash and similar:
- set -v; set -x
- then source again.
- If you have problems with pc_setupsrc, run it with csh in verbose mode:
/bin/csh -v -x $PENCIL_HOME/bin/pc_setupsrc
1.2.1 Linker can’t find the syscalls functions:
ld: 0711-317 ERROR: Undefined symbol: .is_nan_c
ld: 0711-317 ERROR: Undefined symbol: .sizeof_real_c
ld: 0711-317 ERROR: Undefined symbol: .system_c
ld: 0711-317 ERROR: Undefined symbol: .get_env_var_c
ld: 0711-317 ERROR: Undefined symbol: .get_pid_c
ld: 0711-317 ERROR: Undefined symbol: .file_size_c
A: The Pencil Code needs a working combination of a Fortran- and a C-compiler. If this is not
correctly set up, usually the linker won’t find the functions inside the syscalls module. If that
happens, either the combination of C- and Fortran-compiler is inappropriate (e.g. ifort
needs icc), or the compiler needs additional flags, like g95 might need the option
‘-fno-second-underscore’ and xlf might need the option ‘-qextname’. Please refer to Sect. ??,
1.2.2 Make gives the following error now:
PGF90-S-0017-Unable to open include file: chemistry.h (nochemistry.f90: 43)
0 inform, 0 warnings, 1 severes, 0 fatal for chemistry
Line 43 of the nochemistry routine, only has ’contains’.
A: This is because somebody added a new module (together with a corresponding
nomodule.f90 and a module.h file (chemistry in this case). These files didn’t exist before, so
you need to say:
If this does not help, say first make clean and then pc_setupsrc.
1.2.3 How do I compile the Pencil Code with the Intel (ifc) compiler under Linux?
A: The Pencil Code should compile successfully with ifc 6.x, ifc 7.0, sufficiently recent
versions of ifc 7.1 (you should get the latest version; if yours is too old, you will typically get an
‘internal compiler error’ during compilation of ‘src/hydro.f90’), as well as with recent versions
of ifort 8.1 (8.0 may also work).
You can find the ifort compiler at ftp://download.intel.com/software/products/compilers/downloads.
On many current (as of November 2003) Linux systems, there is a mismatch between the glibc
versions used by the compiler and the linker. To work around this, use the following flag for
and set the environment variable
LD_ASSUME_KERNEL=2.4.1; export LD_ASSUME_KERNEL
setenv LD_ASSUME_KERNEL 2.4.1
This has solved the problems e.g. on a system with glibc-2.3.2 and kernel 2.4.22.
Thanks to Leonardo J. Milano (http://udel.edu/~lmilano/) for part of this info.
1.2.4 I keep getting segmentation faults with ‘start.x’ when compiling with ifort
A: There was/is a number of issues with ifort 8.0. Make sure you have the latest patches
applied to the compiler. A number of things to consider or try are:
- Compile with the the ‘-static -nothreads’ flags.
- Set your stacksize to a large value (but a far too large value may be problematic, too),
limit stacksize 256m ulimit -s 256000
- Set the environment variable KMP˙STACKSIZE to a large value (like 100M)
See also http://softwareforums.intel.com/ids/board/message?board.id=11&message.id=1375
1.2.5 When compiling with MPI on a Linux system, the linker complains:
mpicomm.o: In function ‘mpicomm_mpicomm_init_’:
mpicomm.o(.text+0x36): undefined reference to ‘mpi_init_’
mpicomm.o(.text+0x55): undefined reference to ‘mpi_comm_size_’
mpicomm.o(.text+0x6f): undefined reference to ‘mpi_comm_rank_’ [...]
A: This is the infamous underscore problem. Your MPI libraries have been compiled with G77
without the option ‘-fno-second-underscore’, which makes the MPI symbol names
incompatible with other Fortran compilers.
As a workaround, use
in ‘Makefile.local’. Or, even better, you can set this globally (for the given computer) by
inserting that line into the file ‘~/.adapt-mkfile.inc’ (see perldoc adapt-mkfile for more
1.2.6 Compilation stops with the cryptic error message:
f95 -O3 -u -c .f90.f90 Error : Could not open sourcefile .f90.f90
compilation aborted for .f90.f90 (code 1) make: *** [.f90.o] Error 1
What is the problem?
A: There are two possibilities:
- One of the variables for make has not been set, so make expands it to the empty
string. Most probably you forgot to specify a module in ‘src/Makefile.local’. One
possibility is that you have upgraded from an older version of the code that did not
have some of the modules the new version has.
Compare your ‘src/Makefile.local’ to one of the examples that work.
- One of the variables for make has a space appended to it, e. g. if you use the
(see § 1.2.5) with a trailing blank, you will encounter this error message. Remove the
blank. This problem can also occur if you added a new module (and have an empty
space after the module name in ‘src/Makefile.src’, i.e. CHIRAL=nochiral_),
in which case the compiler will talk about “circular dependence” for the file
1.2.7 The code doesn’t compile,
…there is a problem with mvar:
make start.x run.x f95 -O4 -u -c cdata.f90 Error: cdata.f90, line 71: Implicit type for MVAR
detected at MVAR@) [f95 terminated - errors found by pass 1] make: *** [cdata.o] Error 2
A: Check and make sure that ‘mkcparam’ (directory ‘$PENCIL_HOME/bin’) is in your path. If this
doesn’t help, there may be an empty ‘cparam.inc’ file in your ‘src’ directory. Remove
‘cparam.inc’ and try again (Note that ‘cparam.inc’ is automatically generated from the
1.2.8 Some samples don’t even compile,
as you can see on the web, http://www.nordita.org/software/pencil-code/tests.html.
samples/helical-MHDturb: Compiling.. not ok: make start.x run.x read_videofiles.x
make: Entering directory ‘/home/dobler/f90/pencil-code/samples/helical-MHDturb/src’
/usr/lib/lam/bin/mpif95 -O3 -c initcond.f90 /usr/lib/lam/bin/mpif95 -O3 -c density.f90
use Gravity, only: gravz, nu_epicycle ^
Error 208 at (467:density.f90) : No such entity in the module
Error 355 : In procedure INIT_LNRHO variable NU_EPICYCLE has not been given a type
Error 355 : In procedure POLYTROPIC_LNRHO_DISC variable NU_EPICYCLE has not been given a type
3 Errors compilation aborted for density.f90 (code 1) make: *** [density.o] Error 1
make: Leaving directory ‘/home/dobler/f90/pencil-code/samples/helical-MHDturb/src’
make: *** [code] Error 2
A: Somebody may have checked in something without having run auto-test beforehand. The
problem here is that something has been added in one module, but not in the corresponding
no-module. You can of course check with svn who it was…
1.2.9 Internal compiler error with Compaq/Dec F90
The Dec Fortran optimizer has occasional problems with ‘nompicomm.f90’:
make start.x run.x read_videofiles.x f90 -fast -O5 -tune ev6 -arch ev6 -c cparam.f90
[...] f90 -fast -O5 -tune ev6 -arch ev6 -c nompicomm.f90
otal vm 2755568 otal vm 2765296 otal vm 2775024 otal vm 2784752 otal...
Assertion failure: Compiler internal error - please submit problem r...
GEM ASSERTION, Compiler internal error - please submit problem report
Fatal error in: /usr/lib/cmplrs/fort90_540/decfort90 Terminated *** Exit 3
Stop. *** Exit 1 Stop.
A: The occurrence of this problem depends upon the grid size; and the problem never seems
to occur with ‘mpicomm.f90’, except when ncpus=1. The problem can be avoided by
switching off the loop transformation optimization (part of the ‘-O5’ optimization),
#OPTFLAGS=-fast -O5 -notransform_loops
This is currently the default compiler setting in ‘Makefile’, although it has a measurable
performance impact (some 8% slowdown).
1.2.10 Assertion failure under SunOS
Under SunOS, I get an error message like
user@sun> f90 -c param_io.f90 Assertion failed: at_handle_table[at_idx].tag == VAR_TAG,
file ../srcfw/FWcvrt.c, line 4018 f90: Fatal error in f90comp: Abort
A: This is a compiler bug that we find at least with Sun’s WorkShop Compiler version ‘5.0
00/05/17 FORTRAN 90 2.0 Patch 107356-05’. Upgrade the compiler version (and possibly also
the operating system): we find that the code compiles and works with version ‘Sun WorkShop
6 update 2 Fortran 95 6.2 Patch 111690-05 2002/01/17’ under SunOS version ‘5.8
1.2.11 After some dirty tricks I got pencil code to compile with MPI, ...
> Before that i installed lam-7.1.4 from source.
Goodness gracious me, you shouldn’t have to compile your own MPI library.
A: Then don’t use the old LAM-MPI. It is long superseded by open-mpi now. Open-mpi doesn’t
need a daemon to be running. I am using the version that ships with Ubuntu (e.g.
frenesi:~> aptitude -w 210 search openmpi | grep ’^i’
i libopenmpi-dev - high performance message passing library -- header files
i A libopenmpi1 - high performance message passing library -- shared library
i openmpi-bin - high performance message passing library -- binaries
i A openmpi-common - high performance message passing library -- common files
i openmpi-doc - high performance message passing library -- man pages
Install that and keep your configuration (Makefile.src and getconf.csh) close to that for ‘frenesi’
or ‘norlx50’. That should work.
1.2.12 Error: Symbol ’mpi˙comm˙world’ at (1) has no IMPLICIT type
I installed the pencil code on Ubuntu system and tested "run.csh"
in ...\samples\conv-slab. Here the code worked pretty well.
Nevertheless, running (auto-test), I found there are some errors. The messages are,
Error: Symbol ’mpi_comm_world’ at (1) has no IMPLICIT type Fatal Error: Error count reached limit of 25.
make: *** [mpicomm_double.o] Error 1 make: Leaving directory
make: *** [code] Error 2 make: Leaving directory
make: *** [default] Error 2 Finally, ### auto-test failed ### Will it be OK? Or, how can I fix this?
A: Thanks for letting me know about the status, and congratulations on your progress! Those
tests that fail are those that use MPI. If your machine is a dual or multi core machine, you
could run faster by running under MPI. But this is probably not crucial for you at this point. (I
just noticed that there is a ToDo listed in the auto-test command to implement the option not
to run the MPI tests, but this hasn’t been done yet. So I guess you can start with the science
1.2.13 Error: Can’t open included file ’mpif.h’
It always worked, but now, after some systems upgrade, I get
gfortran -O3 -o mpicomm.o -c mpicomm.f90 Error: Can’t open included file ’mpif.h’
When I say locate mpif.h I only get things like
But since I use FC=mpif90 I thought I don’t need to worry.
A: Since you use FC=mpif90 there must definitely be something wrong with their setup. Try
mpif90 -showme or mpif90 -show; the ‘-I’ option should say where it looks for ’mpif.h’. If
those directories don’t exist, it’s no wonder that it doesn’t work, and it is time to
1.3 Pencil check
1.3.1 The pencil check complains for no reason.
A: The pencil check only complains for a reason.
1.3.2 The pencil check reports MISSING PENCILS and quits
A: This could point to a serious problem in the code. Check where the missing pencil is used in
the code. Request the right pencils, likely based on input parameters, by adapting one or more
of the pencil_criteria_MODULE subroutines.
1.3.3 The pencil check reports unnecessary pencils
The pencil check reports possible overcalculation... pencil rho ( 43) is requested, but
does not appear to be required!
A: Such warnings show that your simulation is possibly running too slowly because it is
calculating pencils that are not actually needed. Check in the code where the unnecessary
pencils are used and adapt one or more of the pencil_criteria_MODULE subroutines to request
pencils only when they are actually needed.
1.3.4 The pencil check reports that most or all pencils are missing
A: This is typically a thing that can happen when testing new code development for the
first time. It is usually an indication that the reference df changes every time you
call pde. Check whether any newly implemented subroutines or functionality has a
“memory”, i.e. if calling the subroutine twice with the same f gives different output
1.3.5 Running the pencil check triggers mathematical errors in the code
A: The pencil check puts random numbers in f before checking the dependence of df on the
chosen set of pencils. Sometimes these random numbers are inconsistent with the physics and
cause errors. In that case you can set lrandom_f_pencil_check=F in &run_pars in ‘run.in’. The
initial condition may contain many idealized states (zeros or ones) which then do not trigger
pencil check errors when lrandom_f_pencil_check=F, even if pencils are missing. But it does
prevent mathematical inconsistencies.
1.3.6 The pencil check still complains
A: Then you need to look into the how the code and the pencil check operate. Reduce the
problem in size and dimensions to find the smallest problem that makes the pencil check fail
(e.g. 1x1x8 grid points). At the line of ‘pencil_check.f90’ when a difference is found between
df_ref and df, add some debug lines telling you which variable is inconsistent and in what
place. Often you will be surprised that the pencil check has correctly found a problem in the
1.3.7 The pencil check is annoying so I turned it off
A: Then you are taking a major risk. If one or more pencils are not calculated properly, then
the results will be wrong.
1.4.1 Why does ‘start.x’ / ‘start.csh’ write data with periodic boundary conditions?
A: Because you are setting the boundary conditions in ‘run.in’, not in ‘start.in’; see Sect. ??.
There is nothing wrong with the initial data — the ghost-zone values will be re-calculated
during the very first time step.
1.4.2 csh problem?
Q: On some rare occasions we have problems with csh not being supported on other machines.
(We hope to fix this by contacting the responsible person, but may not be that trivial today!)
Oliver says this is a well known bug of some years ago, etc. But maybe in the long run it would
be good to avoid csh.
A: These occasions will become increasingly frequent, and eventually for some architectures,
there may not even be a csh variant that can be installed.
We never pushed people to use pc_run and friends (and to report corresponding bugs and get
them fixed), but if we don’t spend a bit of effort (or annoy users) now, we create a future
emergency, where someone needs to run on some machine, but there is no csh and he or she
just gets stuck.
We don’t have that many csh files, and for years now it should be possible to compile run
without csh (using bin/pc_run) — except that people still fall back on the old way of doing
things. This is both cause and consequence of the ‘new’ way not being tested that much, at
least for the corner cases like ‘RERUN’, ‘NEWDIR’, ‘SCRATCH_DIR’.
1.4.3 ‘run.csh’ doesn’t work:
Invalid character ’’’ in NAMELIST input Program terminated by fatal I/O error Abort
A: The string array for the boundary condition, e.g. bcx or bcz is too long. Make sure it has
exactly as many elements as nvar is big.
1.4.4 Namelist problem under IRIX
Under IRIX, I get
lib-4001 : UNRECOVERABLE library error Encountered during a namelist READ from unit 1
Fortran unit 1 is connected to a sequential formatted text file: "run.in" IOT Trap Abort
A: This is a compiler bug that has been found at least with the MIPSpro F90 compiler version
220.127.116.11m. The problem seems to have been fixed in version 7.4.20m.
The error comes and goes, depending on the configuration (and possibly even the input
parameters) you are using. Until SGI fix their compiler, you can experiment with adding new
variables to the module Param˙IO; this has solved the problem once for us. If this trick does
not help, you will need to turn your namelist input (at least ‘run.in’ into Fortran statements,
include them into a replacement version of ‘param_io.f90’, and recompile each time you make
1.4.5 Code crashes after restarting
> > removing mu_r from the namelist just ‘like that’ makes the code > > backwards incompatible. >
> That means that we can never get rid of a parameter in start.in once we > have introduced it, right?
A: In the current implementation, without a corresponding cleaning procedure, unfortunately
Of course, this does not affect users’ private changes outside the central svn tree.
1.4.6 auto-test gone mad...?
Q: Have you ever seen this before:
giga01:/home/pg/n7026413/cvs-src/pencil-code/samples/conv-slab> auto-test .
/home/pg/n7026413/cvs-src/pencil-code/samples/conv-slab: Compiling.. ok
No data directory; generating data -> /var/tmp/pencil-tmp-25318
Starting.. ok Running.. ok
Validating results..Malformed UTF-8 character (unexpected continuation
byte 0x80, with no preceding start byte) in split at
/home/pg/n7026413/cvs-src/pencil-code/bin/auto-test line 263.
Malformed UTF-8 character (unexpected continuation byte 0x80, with no
preceding start byte) in split at /home/pg/n7026413/cvs-src/pencil-code/bin/auto-test line 263.
A: You are running on a RedHat 8 or 9 system, right?
Set LANG=POSIX in your shell’s startup script and life will be much better.
1.4.7 Can I restart with a different number of cpus?
Q: I am running a simulation of nonhelical turbulence on the cluster using MPI. Suppose if I
am running a 1283 simulation on 32 cpus/cores i.e.
integer, parameter :: ncpus=32,nprocy=2,nprocz=ncpus/nprocy,nprocx=1
integer, parameter :: nxgrid=128,nygrid=nxgrid,nzgrid=nxgrid
And I stop the run after a bit. Is there a way to resume this run with different number of cpus
like this :
integer, parameter :: ncpus=16,nprocy=2,nprocz=ncpus/nprocy,nprocx=1
integer, parameter :: nxgrid=128,nygrid=nxgrid,nzgrid=nxgrid
I understand it has to be so in a new directory but making sure that the run starts from where
I left it off in the previous directory.
A: The answer is no, if you use the standard distributed io. There is also parallel io, but I never
used it. That would write the data in a single file, and then you could use the data for restart
in another processor layout.
1.4.8 Can I restart with a different number of cpus?
Q: Is it right that once the simulation is resumed, pencil-code takes the last data from var.dat
(which is the current snapshot of the fields)? If that is true, then, is it not possible to give that
as the initial condition for the run in the second directory (with changed ”ncpus”)? Is there a
mechanism already in place for that?
A: Yes, the code restarts from the last var.dat. It is written after a successful completion of the
run, but it crashes or you hit a time-out, there will be a var.dat that is overwritten every isave
timesteps. If the system stops during writing, some var.dat files may be corrupt or have the
wrong time. In that case you could restart from a good VAR file, if you have one, using,
where 46 is the number of your VAR file, i.e., VAR46 im this case. To restart in another
directory, you say, from the old run directory,
Hope this helps. Look into pencil-code/bin/restart-new-dir to see what it is doing.
1.4.9 fft_xyz_parallel_3D: nygrid needs to be an integer multiple...
Q: I just got an:
fft_xyz_parallel_3D: nygrid needs to be an integer multiple of nprocy*nprocz
In my case, nygrid=2048, nprocy=32, and nprocz=128, so nprocy*nprocz=4096. In other words,
2048 needs to be a multiple of 4096. But isn’t this the case then?
A: No, because 2048 = 0.5 * 4096 and 0.5 is not an integer. Maybe try either setting nprocz=64
or nprocy=64. You could compensate the change of ncpus with the x-direction. For 20483
simulations, nprocy=32 and nprocz=64 would be good.
1.4.10 Unit-agnostic calculations?
Q: The manual speaks about unit-agnostic calculations, stating that one may choose to
interpret the results in any (consistent) units, depending on the problem that is solved at
hand. So, for example, if I chose to run the ‘2d-tests/battery_term’ simulation for an arbitrary
number of time-steps and then choose to examine the diagnostics, am I correct in assuming the
1) [Brms] = Gauss (as output by unit_magnetic, before the run begins)
2) [t] = s (since the default unit system is left as CGS)
3) [urms] = cm/s (again, as output by unit_velocity, before the run begins)
4) and etc. for the units of the other diagnostics
A: Detailed correspondence on this item can be found on:
https://groups.google.com/forum/?fromgroups#!topic/pencil-code-discuss/zek-uYNbgXI There is also working
material on unit systems under http://www.nordita.org/~brandenb/teach/PencilCode/MixedTopics.html
with a link to http://www.nordita.org/~brandenb/teach/PencilCode/material/AlfvenWave_SIunits/
Below is a pedagogical response from Wlad Lyra:
In the sample battery-term, the sound speed cs0=1 sets the unit of
velocity. Together with the unit of length, that sets your unit of
time. The unit of magnetic field follows from the unit of velocity,
density, and your choice of magnetic permittivity, according to the
definition of the Alfven velocity.
If you are assuming cgs, you are saying that your sound speed cs0=1
actually means [U]=1 cm/s. Your unit of length is equivalently 1 cm,
and therefore the unit of time is [t] = [L]/[U]=1 s. The unit of
density is [rho] = 1 g/cm^3. Since in cgs vA=B/sqrt(4*pi * rho), your
unit of magnetic field is [B] = [U] * sqrt([rho] * 4*pi) ~= 3.5
sqrt(g/cm) / s = 3.5 Gauss.
If instead you are assuming SI, you have cs0=1 assuming that means
[U]=1 m/s and rho0=1 assuming that to mean [rho]=1 kg/m^3. Using [L]=1
m, you have still [t]=1 s, but now what appears as B=1 in your output
is actually [B] = [U] * sqrt (mu * [rho]) = 1 m/s * sqrt(4*pi * 1e-7
N*A-2 1 kg/m^3) ~= 0.0011210 kg/(s^2*A) ~ 11 Gauss.
You can make it more interesting and use units relevant to the
problem. Say you are at the photosphere of the Sun. You may want to
use dimensionless cs0=1 meaning a sound speed of 10 km/s. Your
appropriate length can be a megameter. Now your time unit is
[t]=[L]/[U] = 1e3 km/ 10 km/s = 10^2 s, i.e., roughly 1.5 minute. For
density, assume rho=2x10-4 kg/m^3, typical of the solar photosphere.
Your unit of magnetic field is therefore [B] = [U] * sqrt([rho] *
4*pi) = 1e6 cm/s * sqrt(4*pi * 2e-7 g/cm^3) ~ 1585.33 Gauss.
Notice that for mu0=1 and rho0=1 you simply have vA=B. Then you can
conveniently set the field strength by your choice of plasma beta (=
2*cs^2/vA^2). There’s a reason why we like dimensionless quantities!
1.5.1 ‘start.pro’ doesn’t work:
Reading grid.dat.. Reading param.nml.. \% Expression must be a structure in this context: PAR.
\% Execution halted at: \$MAIN\$ 104
A: You don’t have the subdirectory ‘data’ in your IDL variable !path. Make sure you source
‘sourceme.csh’/‘sourceme.sh’ or set a sufficient IDL path otherwise.
1.5.2 ‘start.pro’ doesn’t work:
Isn’t there some clever (or even trivial) way that one can avoid the annoying error
messages that one gets, when running e.g. ”.r rall” after a new variable has been
introduced in ”idl/varcontent.pro”? Ever so often there’s a new variable that can’t be
found in my param2.nml – this time it was IECR, IGG, and ILNTT that I had to
A: The simplest solution is to invoke ‘NOERASE’, i.e. say
or, alternatively, start_run.csh. What it does is that it reruns src/start.x with a new version
of the code; this then produces all the necessary auxiliary files, but it doesn’t overwrite or erase
the ‘var.dat’ and other ‘VAR’ and ‘slice’ files.
1.5.3 Something about tag name undefined:
Q: In one of my older run directories I can’t read the data with idl anymore. What should I do?
Is says something like
Reading param.nml.. % Tag name LEQUIDIST is undefined for structure <Anonymous>.
% Execution halted at: $MAIN$ 182 /people/disk2/brandenb/pencil-code/idl/start.pro
A: Go into ‘data/param.nml’ and add , LEQUIDIST=T anywhere in the file (but before the last
1.5.4 Something INC in start.pro
Q: start doesn’t even work:
% Compiled module: $MAIN$. nname= 11 Reading grid.dat.. Reading param.nml..
Can’t locate Namelist.pm in INC (INC contains: /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /home/brandenb/pencil-code/bin/nl2idl line 49.
BEGIN failed--compilation aborted at /home/brandenb/pencil-code/bin/nl2idl line 49.
A: Go into ‘$PENCIL_HOME’ and say svn up sourceme.csh and/or svn up sourceme.sh. (They
were just out of date.)
1.5.5 nl2idl problem when reading param2.nml
Q: Does anybody encounter a backward problem with nl2idl? The file param*.nml files are
checked in under ‘pencil-code/axel/couette/SStrat128a_mu0.20_g2’ and the problem is
at /people/disk2/brandenb/pencil-code/bin/nl2idl line 120
HCOND0= 0.0,HCOND1= 1.000000,HCOND2= 1.000000,WIDTHSS= 1.192093E-06,MPOLY0=
^------ HERE at /people/disk2/brandenb/pencil-code/bin/nl2idl line 120
A: The problem is the stupid ifc compiler writing the following into the namelist
’COOL= 0.0,CS2COOL= 0.0,RCOOL= 1.000000,WCOOL= 0.1000000,FBOT= 0.0,CHI_T= 0.0
If you add a comma after the closing quote:
’,COOL= 0.0,CS2COOL= 0.0,RCOOL= 1.000000,WCOOL= 0.1000000,FBOT= 0.0,CHI_T= 0.0
things will work.
Note that ifc cannot even itself read what it is writing here, so if this happened to occur in
param.nml, the code would require manual intervention after each start.csh.
1.5.6 Spurious dots in the time series file
Q: Wolfgang, you explained it to me once, but I forget. How can one remove spurious dots after
the timestep number if the time format overflows?
A: I don’t know whether it exists anywhere, but it’s easy. In Perl you’d say
perl -pe ’s/^(\s*[-0-9]+)\.([-0-9eEdD])/$1 $2/g’
and in sed (but that’s harder to read)
sed ’s/^\( *[-0-9]\+\)\.\([-0-9eEdD]\)/\1 \2/g’
1.6 General questions
1.6.1 “Installation” procedure
Why don’t you use GNU autoconf/automake for installation of the Pencil Code?
A: What do you mean by “installation”? Unlike the applications that normally use autoconf,
the Pencil Code is neither a binary executable, nor a library that you compile once and then
dump somewhere in the system tree. Autoconf is the right tool for these applications, but
not for numerical codes, where the typical compilation and usage pattern is very
You have different directories with different ‘Makefile.local’ settings, recompile after
introducing that shiny new term in your equations, etc. Moreover, you want to sometimes
switch to a different compiler (but just for that run directory) or another MPI implementation.
Our adapt-mkfile approach gives you this flexibility in a reasonably convenient way, while
doing the same thing with autoconf would be using that system against most of its design
Besides, it would really get on my (WD’s) nerves if I had to wait two minutes for autoconf to
finish before I can start compiling (or maybe 5–10 minutes if I worked on a NEC
Finally, if you have ever tried to figure out what a ‘configure’ script does, you will appreciate a
comprehensible configuration system.
1.6.2 Small numbers in the code
What is actually the difference between epsi, tini and tiny?
F90 has two functions epsilon() and tiny(), with
epsilon(x) = 1.1920929e-07
tiny(x) = 1.1754944e-38
(and then there is huge(x) = 3.4028235e+38)
for a single-precision number x.
epsilon(x) is the smallest number that satisfies
1+epsilon(1.) /= 1 ,
while tiny(x) is the smallest number that can be represented without
In the code we have variants hereof,
that have added safety margins, so we don’t have to think about doing
things like 1/tini.
So in sub.f90,
- evr = evr / spread(r_mn+epsi,2,3)
did (minimally) affect the result for r_mn=O(1), while the correct version
+ evr = evr / spread(r_mn+tini,2,3)
only avoids overflow.
1.6.3 Why do we need a /lphysics/ namelist in the first place?
Wolfgang answered on 29 July 2010: “‘cdata.f90’ has the explanation”
! Constant ’parameters’ cannot occur in namelists, so in order to get the
! now constant module logicals into the lphysics name list...
! We have some proxies that are used to initialize private local variables
! called lhydro etc, in the lphysics namelist!
So the situation is this: we want to write parameters like ldensity to param.nml
so IDL (and potentially octave, python, etc.) can know whether density was on or
not. To avoid confusion, we want them to have exactly their original names. But
we cannot assemble the original ldensity etc. constants in a namelist, so we have
to define a local ldensity variable. And to provide it with the value of the original
cdata.ldensity, we need to transfer the value via ldensity˙var. That’s pretty scary, although
it seems to work fine. I can track the code back to the big eos˙merger commit, so
it may originate from that branch. One obvious problem is that you have to add
code in a number of places (the ldensity → ldensity˙var assignment and the local
definition of ldensity) to really get what you need. And when adding a new boolean of
that sort to ‘cdata.f90’, you may not even have a clue that you need all the other
There may be a cleaner solution involving generated code. Maybe something like
logical :: ldensity ! INCLUDE_IN_LPHYSICS
could later generate code (in some param˙io˙extra.inc file) that looks like this:
write(unit, *) ’ldensity = ’, ldensity
i.e. we can manually write in namelist format. But maybe there are even simpler
1.6.4 Can I run the code on a Mac?
A: Macs work well for Linux stuff, except that the file structure is slightly different. Problems
when following Linux installs can usually be traced to the PATH. For general reference, if you
need to set an environment variable for an entire OS-X login session, google environment.plist.
That won’t be needed here.
For a Mac install, the following should work:
- Install Dev Tools (an optional install on the MacOS install disks). Unfortunately,
last time I checked the svn version that comes with DevTools is obsolete. So:
- Install MacPorts (download from web). Note that MacPorts installs to a
non-standard location, and will need to be sourced. The installation normally drops
an appropriate line in .profile. If it does so, make sure that that line gets sourced.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH export MANPATH=/opt/local/share/man:$MANPATH
- Install g95 (download from web). Make sure it is linked in /bin.
- execute macports svn install
- download the pencil-code and enjoy.
Note: the above way to get svn works. It takes a while however, so there are certainly faster
ways out there. If you already have a non-obsolete svn version, use that instead.
1.6.5 Pencil Code discussion forum
Do I just need to send an email somewhere to subscribe or what?
A” The answer is yes; just go to:
1.6.6 The manual
It would be a good idea to add this useful information in the manual, no?
A: When you have added new stuff to the code, don’t forget to mention this in the
Again, the answer is yes; just go to:
cd pencil-code/doc/ vi manual.tex svn ci -m "explanations about a new module in the code"