Known problems and some solutions

TODO: This should only be technical problems. E.g. not problems with a particular setup or switch of prodimo.

Compilation problems

It doesn't compile

Check your makefile against other versions of working versions makefile.myhost in ProDiMo/src_develop. In particular, look into makefile.prodimo, which is the makefile on my desktop, which should work for every new ProDiMo release. Unfortunately, all makefiles are machine-dependent, compiler-dependent, and compiler-version-dependent, so we cannot guarantee that one of our makefiles works for you. You possibly have to experiment a bit yourself.

You can also type make -f makefile.prodimo realclean and make -f makefile.prodimo to recompile to modules.

Know compilation issues with ifort (10)

If you get the following message,

relocation truncated to fit: R_X86_64_32S against `.bss' Error

it is that your Makefile does not contain the flag -mcmodel=medium The reason for this error is the size of data that you are using. This happens when the program requires more than 2GB of static data (not dynamically allocated). Please add the flag in the ProDiMo Makefile AND in the cfitsio Makefile

CC     =        gcc
CFLAGS =    -g -mcmodel=medium -O2 -Dg77Fortran -fPIC

Compilation problems with cfitsio on MAC OS X

There seems to be a problem with the most recent cfitsio version (3.420) and MAC OS X (at least for MAC OS X 10.11.x). When you compile ProDiMo (after installing cfitsio) you might get such an error

Undefined symbols for architecture x86_64:
  "_curl_easy_cleanup", referenced from:
      _https_open_network in libcfitsio.a(drvrnet.o)
  .....

A workaround to this problem is to install an older cfitsio version instead. For example one of the 3.0xx versions (can be found here: [[https://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/]]).

Problems with running ProDiMo

Problems with chemistry/heating/cooling at the first grid point

If you get an error message like this (in the log file)

CHEMISTRY AND ENERGY BALANCE ...


 *** could not bracket Tg in POINT_CHEM_EBALANCE           1          60
 *** T1,T2=   31031.119312381103        40000.000000000000     
 *** Q1,Q2=   6.3855086112142971E-017   6.3675577270311217E-017
 *** bad heating/cooling balance   96.979744998371373     
     at            1          60  Tg=   40000.000000000000     
 heat/cool-quality =  9.7E+01
 --  37: X-ray Coulomb heating                       6.4318E-17
 --  46: HI bb & bf heating                          1.1652E-20
 --  46: OIII line cooling                           5.2830E-19
 --  49: NeIII line cooling                          1.1409E-19

it is not necessarely a problem if the code recovers (i.e. the error message goes away at some point). However, sometimes it does not and it might even crash. In both cases it is worth to try setting

.true.   ! Xray_workaround   : workaround for the problem in the X-ray chemistry when H+,He+ >> H,H2,He

in case you use X-rays in your model. It can also help to set:

.false.   ! el_is_sp         : treat electron as a "normal" species

We emphasise that these are not general solutions, such an error message can have many (possible unknown) reasons.

Segmentation fault

If you get an error when running ProDiMo (in particular larger models) it could be because of a Segmentation fault. See here Segment_fault_and_Stacksize_problem. If that does not work see also below.

TODO: The stuff below is outdated I guess (ifort on Mac os X). The ulimit stuff is included in the page above. I never had to use a compile option for MAC os X. I think setting ulimit is kind of a requirement, and should be done already during installation. Also the OMP_STACKSIZE needs to be set (as parallel mode is kind of default).

From the Intel support page:

The Intel® Fortran Compilers 8.0 or higher allocate more temporaries on the stack than previous Intel Fortran compilers. Temporaries include automatic arrays and array sub-sections corresponding to actual arguments. If the program is not afforded adequate stack space at runtime relative to the total size of the temporaries, the program will terminate with a segmentation fault on Linux and Mac OS X or Signal 11 on Windows*.

On Linux*, the stack space can be increased using:

ulimit -s unlimited

for bash shell, or

limit stacksize unlimited

for csh shell

On Mac OS* X Leopard: simply use the -stack_size option to the linker ifort -Wl,-stack_size,0x10000000 foo.f or ld -stack_size 0x10000000 -o foo foo.o

For Intel® Fortran Compilers 10.0 and above, all platforms: The -heap-arrays compiler option directs the compiler to put the automatic arrays and arrays created for temporary computations on the heap instead of the stack.

Notes:

  • Linux: The size of "unlimited" varies by Linux configuration, so you may need to specify a larger, specific number to ulimit (for example, 999999999). On Linux also note that many 32bit Linux distributions ship with a pthread static library (libpthread.a) that at runtime will fix the stacksize to 2093056 bytes regardless of the ulimit setting. To avoid this problem do not link with the -static option or the -fast option. Instead of -fast, use options: -ipo -O3 -no-prec-div -xP . This only affects the 32bit Linux distributions and does not apply to the 64bit Linux distributions.

  • Mac OS X: stack "unlimiting" of the shell environment on Mac OS X is not possible. The OS sets a ceiling for the maximum stack size, typically 64K. Use the linker options shown above to increase stacksize.

Heap and Stack are two kinds of memory:

  • stack: fast memory for automatic allocation when a subroutine/function is called. The size is set before the run.
  • heap: reserved for dynamic memory allocation. The size can be increased as needed. Heap memory is slower than stack memory.

The RT takes ages or doesn't converge

TODO: also outdated -> diffusion solver

The continuum radiative transfer in massive disks is a difficult physical problem! And the ProDiMo continuum radiative transfer module is a pretty simple tool. How large is the midplane optical depth at 1mic in your model (your stdout should state it)? The RT tool should converge for optical depths up to 103 to 104. For 105 and higher, ProDiMo uses tricks to make it converge better, but it is getting more and more complicated. 106 is an absolute limit. The RT will simply not converge for such disks. Try to start with low-resolution, low-mass disk models and wait until they are converged, then increase disk mass and finally disk resolution.

The global iteration does not converge

Unfortunately, this is true for most models! A model usually convergences from the midplane upwards, but the upper regions of some columns do not converge properly, e.g. keep on flipping back and forth during the iterations, possibly related to some physical instability. I have no cure against this behavior, but I think that it shouldn't have much of an effect on the emission lines in most cases. Check the effect on the spectral lines by doing two Ratran simulations with output from two successive iterations at a late stage. Are they any different? Increasing the grid resolution sometimes helps. How patient have you been? If you are running 100x100 grid resolution, about 100 iterations is normal to achieve (some kind of) convergence. Better start small and increase resolution later. ProDiMo uses quite a sophisticated criterion for the judgement of convergence, including number of converged grid points, maximum and mean relative density changes. But still, this does not always give the right answer. Look at the stdout. You can find a visualisation of the convergence process on the grid-points for the sound speed cT and the resulting density/pressure where

  • "." = converged (changes < 5%)
  • "+" = increased
  • "-" = decreased
  • "L" = strongly increased, limited
  • "l" = strongly decreased, limited
  • "#" = worst grid point
  • "f" = frozen

Looking at this output, you can decide when it's "finished".

If you think it's alright, just press , elegant, isn't it? An alternative is to set maxit or maxtime in Parameter.in. Warning: if you use write_pop=.true. and press during the chemistry, the pop-files will be incomplete! So, rather press during the radiative transfer, or use maxit/maxtime.

See more under How_to_run_a_full_model.

ProDiMo with the soft-edge option cannot handle narow ring structures

The problem occurs when Rout-Rin is too small, for example Rin=60 AU, Rout=70 AU.

Idl post-processing

prodimo.pro shows error message concerning myloadct

If you see an idl error message like % Attempt to call undefined procedure/function: 'MYLOADCT'., you have to link myloadct.pro to you current working folder

> ln -s ../idl/myloadct.pro .

Problems with prodimo.pro

prodimo.pro requires the astronomy library from NASA [http://idlastro.gsfc.nasa.gov/]. Please ensure that you have the library and a IDL path in the .profile or .tcsh file to the library exists (IDL_PATH)

Running ProDiMo in gdb

If you run ProDiMo in gdb with

exec-file prodimo
run prodimo

you probably get an error message similar to this one

Reading additional Paramterfile: prodimo

At line 558 of file read_parameter.f (unit = 12, file = '')
Fortran runtime error: Text file busy

The problem is that if ProDiMo is called with run prodimo, the code takes prodimo as the first command line argument and assumes it is an additional parameter file. To avoid this problem you should only use run in gdb (so without prodimo). To do this you can call gdb this way

gdb prodimo
and than type run in gdb. Or launch gdb and set the executable file:

exec-file prodimo
run
This seems to work only if run prodimo was never used in the current gdb instance.