See the main installation instructions for details of how to install splash
At the graphics device prompt, choose /png. This will produce a series of files:
splash_0000.png splash_0001.png splash_0002.png ...
There are then many procedures for getting from these files to an animation. The best ways I have found are as follows:
sudo apt-get install ffmpeg
With ffmpeg installed, you can use the script provided in splash/scripts/movie.sh, e.g.:
This should produce a movie called movie.mp4 from your splash_*.png files. The contents of this script are just some options for ffmpeg that produce a nice movie:
#!/bin/bash # # script to make an mpeg4 movie from splash_*.png files # requires ffmpeg utility # # DJP, Feb 2014 # opts='-r 10 -vb 50M -bt 100M -vcodec mpeg4 -vf setpts=4.*PTS' ffmpeg -i splash_%04d.png $opts movie.mp4
The main options to play with are the bitrate (-bt 100M) that controls the quality and the "-vf setpts=4.*PTS" which controls how fast the movie plays (setpts=1.*PTS gives 10 frames per second, this is usually too fast so we slow it down).
On a Mac:
Use Graphic Converter (shareware, although the full version is cheap to buy and well worth it). The steps are:
Use Frame-by-Frame (a free download). Will import a sequence of images and write in Quicktime format. Older versions had problems with more than 1000 files, but for simple things this does the job.
The best compression codec in my experience on the Mac is the H.264 MPEG codec which gives a nice small movie that is still good quality. The best way to reduce the movie size further is to restrict the data rate.
See ffmpeg, above. Another option is to produce an animated gif using the `convert' utility that comes with the ImageMagick package. As an example (kindly provided by John Mansour), use
convert -delay 10 -loop 0 splash_*.png animatedgif.gifwhere delay gives a delay in ms between frames, and loop determines whether the animated gif will loop (0= infinite, 1=1 loop, etc). The problem with an animated GIF is that they are quite slow unless you have *lots* of memory. However it is quite easy to convert an animated GIF into many other movie formats.
It is also possible to produce MPEG movies directly with `convert' (Thanks to Florian Buerzle):
convert -delay 10 -loop 0 splash_*.png animation.mpgHowever, this relies on a recent copy of imagemagick, which use ffmpeg as the backend anyway. So use ffmpeg
This is a command line tool and not as convenient to use as ImageMagick. However, there is a frontend called Vive, maintained at sourceforge (which I haven't managed to install myself, due to dependency problems...but maybe someone is more lucky).
sudo apt-get install ffmpeg
Then, ffmpeg can be used according to the documentation. For example:
ffmpeg -i splash_%04d.png -r 25 -b 2048k animation.mp4but that requires some experimentation with the parameter settings. The image files' names have to be strictly in numerical order for this method to work properly, and the %04d is used similar to the formatted output in C's printf function. But see the very nice page here.
mencoder is a utility which comes with the famous MPlayer. As mencode is also based on ffmpeg, the requirements mentioned above should also apply here. An example command line for mencoder (contributed by Sander Valcke) is given by
mencoder "mf://*.png" -mf fps=5 -o output.avi -ovc lavc -lavcopts vcodec=msmpeg4v2:vhq:vbitrate=3000:mbd=1where the frame rate (-fps=5) can be adjusted as required.
gfortran -O3 -Wall -frecord-marker=4 -c write_pixmap.f90 -o write_pixmap.o In file write_pixmap.f90:241 real, intent(out), dimension(:,:), allocatable :: datpix 1 Error: ALLOCATABLE attribute conflicts with DUMMY attribute at (1) In file write_pixmap.f90:338 allocate(datpix(npixx,npixy),stat=ierr) 1 Error: Syntax error in ALLOCATE statement at (1) In file write_pixmap.f90:238 subroutine readpixmap(datpix,npixx,npixy,dumpfile,label,icol,time,istep,xsec,ie 1 Error: Symbol 'datpix' at (1) has no IMPLICIT type make: *** [write_pixmap.o] Error 1
The problem is that you are using an old version of gfortran (use
gfortran -vto check the version) which does not compile SPLASH. I recommend downloading a more recent version.
SPLASH compiles and runs, but half way through reading my data file/plotting/making coffee it mysteriously crashes with a segmentation fault.
This could be a stacksize issue (particularly with large data reads). Try:
ulimit -s unlimited
if you are using the bash shell, or the equivalent in tcsh:
limit stacksize unlimited
before invoking splash.
Unformatted (binary) dumps of data are designed for fast read/write access, not necessarily portability. The primary difference is usually the ENDIAN-ness of the file, which refers to the byte-ordering of the data. This can vary between machines, being either BIG or LITTLE endian. Most compilers have an option to change the default behaviour (for both read and write) at run time using an environment variable (full details given in the userguide). On other compilers where the option is specified at compile time, you can compile SPLASH this way using:
Some compilers, bizarrely, change things related to unformatted files when compiling Fortran codes in 64-bit as opposed to 32-bit. For example the gfortran compiler changes the length of the header placed by Fortran before and after every record written to the unformatted file from 4 bytes to 8 bytes. The fix for this (in gfortran) is to add -frecord-marker=4 as a compile-time flag which forces the record marker to be 4-bytes in length regardless of the 32/64 bit nature of the system (thanks go to Giuseppe Lodato for working out this one). Other compilers (e.g. g95) change the default integer size to int*8 instead of int*4 which can also mess up compatibility between 32 bit and 64 bit files .
Could it be that the dumps are read in double precision when they are actually single or vice versa?
At the graphics device prompt,
Graphics device/type (? to see list, default /xw): /epschoose /eps. This will write the output to a file called splash.eps in the current directory. Alternatively you can specify the filename explicitly by typing "myfile.eps". The file can be incorporated directly into LaTeX documents.
This is a bug related to the way the pixman library (a dependency of cairo) distributed with OS/X Lion is compiled. The solution is to either install and compile your own version of cairo/pixman (e.g. using the install-cairo.sh script in the root level splash directory), or to compile against the MacPorts cairo library, where the bug is fixed. To specifically link SPLASH/giza to the MacPorts cairo library, compile splash as follows (or just use MacPorts to install splash):
make X11DIR=/opt/local PREFIX=/opt/local
This appears to be a bug in the xlib routines in earlier cairo versions. It is fixed in cairo 1.12.2, so you should update your cairo version to 1.12.2 or later.
Send me an image (any sensible format will do) containing a colour bar using the scheme you want to rip off and I will add it into splash.
Urrmmm... it has SPH in it and it sounded good. I thought of:
"Some Pretty Little Application for Smoothed (particle) Hydrodynamics"
"Smoothed Particles Look Amazingly Stunning Here"
"So People Love Analysing Simulations of Hydrodynamics"
"Simulating Particles Like A Superfast Horse"
Your suggestions on a postcard please.
At the moment I am accepting donations in the form of citations to the SPLASH paper (Price, 2007, PASA, 24, 159-173). Just like sending cash, only... not. This may change if I am flooded with requests from people wanting to send large sums of money.