User Tools

Site Tools



IPP complains during compiling

The linking lines for IPP have changed between versions. What we have put by default in the setup.bash and setup.csh files is appropriate for the latest IPP versions. If compilation of any DiFX components fails complaining about any IPP libraries, edit setup.[bash/csh] and try uncommenting/changing the IPPLIB32/64 lines as directed by the inline comments.

If this doesn't fix the problem, please note the error message and try to fix the lines in setup.[bash/csh] appropriately. Once you have fixed the problem (or given up in confusion) please email difx-users and let us know.

Running DiFX

DIFX runs giving very little output

DIFX runs and just gives a crpytic error message

Probably DIFX is configured to send all log messages via muticast broadcast but you do not have any program running to capture the messages. Either disable muticast logging in DIFXIO but unseting the enviroment variables DIFX_MESSAGE_GROUP, DIFX_MESSAGE_PORT, DIFX_BINARY_GROUP and DIFX_BINARY_PORT. These are probably set in setup.csh or setup.bash. Alternatively run


Which will capture and display the error messages

Shared library problems

DiFX runs and gives errors such as

error while loading shared libraries: cannot open shared object file: No such file or directory

You have a problem with your unix setup, probably setting up the environment on remote hosts. One the machine you are running difx from try

ldd $DIFXROOT/bin/mpifxcorr

The output should be something like =>  (0x00007fffaeffe000) => /home/vlbi/difx/lib/ (0x00007f34a6a0c000) => /opt/intel/ipp/ (0x00007f34a6cf1000) => /opt/intel/ipp/ (0x00007f34a68a4000) => /opt/intel/ipp/ (0x00007f34a678d000) => /opt/intel/ipp/ (0x00007f34a6620000) => /opt/intel/ipp/ (0x00007f34a6514000) => /usr/lib/ (0x00007f34a6239000) => /home/vlbi/difx/lib/ (0x00007f34a6031000) => /lib/ (0x00007f34a5e15000) => /lib/ (0x00007f34a5c0c000) => /usr/lib/ (0x00007f34a5900000) => /lib/ (0x00007f34a567d000) => /lib/ (0x00007f34a5466000) => /lib/ (0x00007f34a5113000) => /lib/ (0x00007f34a4f0f000) => /usr/lib/ (0x00007f34a4ce6000)
/lib64/ (0x00007f34a6c50000)

If any libraries say “not found” you probably have to fix your LD_LIBRARY_PATH.

If this works try some of the following to track down where the problem is. The exact commands you run will depend on your specific setup (e.g. rsh vs ssh, path to mpifxcorr)

  • ssh into one of the remote hosts and rerun “ldd $DIFXROOT/bin/mpifxcorr”
  • ssh localhost ldd $DIFX/bin/mpifxcorr
  • ssh <REMHOST> ldd $DIFX/bin/mpifx

Python programs die due to Non-ASCII characters

Within the difx project many source files are endowed with comment lines that get updated when files are checked out to reflect version and date information. Python, by default, expects only 7-bit ASCII characters (hence no accented or otherwise non-American characters) even in comments. A problem can happen in cases such as checking out a file in a Spanish locale with a Saturday date being added to the comment field. The error message in this instance would be:

SyntaxError: Non-ASCII character '\xe1' in file on line 3, but no encoding declared; see for details

Quick fix Edit the file in question (e.g.,, simply removing the line of text referenced in the error message (assuming this is a comment line)

Long term fix Being investigated…

RPC service unavailable

This error may occur if you are running the old calcserver program to generate the correlator delay model. In most current installations this is replaced by difxcalc which does not require communication by xml-rpc. You should consider adopting difxcalc.

If an RPC error is encountered when starting the calcserver program, it is possible that the portmap service is either not installed or not running. Please consult your OS distribution documentation for rectifying this. In the case of Debian or Ubuntu Linux, the solution may be as simple as:

apt-get install portmap
difx/troubleshooting.txt · Last modified: 2021/08/12 18:22 by cormac