Here are my notes on compiling Delft3D on a fresh Ubuntu install. Lines beginning with "$" indicate commands entered on command line. Of course, don't enter the $ part.
To look at your newly modeled testcase data, I suggest using quickplot. It took me a while to figure out how to access it. I copied the quickplot directory from src/tools_lgpl/matlab in the Delft3D repo checked out in the steps above from the Linux modeling machine to my Windows workstation, which has Matlab installed (R2012A at the time of writing). In Matlab, I changed to the relevant directory and ran make_d3dmatlab on a whim, and to my amazement it created a new delft3d_matlab directory. I then ran d3d_qp and got a nice GUI that popped up and allowed me to open and examine output files from the 01_standard testcase.
Quickplot is also available in the Delft3D GUI, described below.
For a first attempt, I used Delft Dashboard, which is part of OpenEarthTools, for generating input files. I followed these instructions, because the packaged files available on the Delft3D website didn't work for me (they require an older version of Matlab Compiler Runtime, and I already have full-fledged Matlab on my workstation anyway). I did the svn checkout on my Linux box and copied the files over to my Windows workstation so I didn't have to mess with installing TortoiseSVN on Windows. Note: if you checkout the entire openearthtools directory structure, which is recommended, it's a 1.3 GB download.
$ svn checkout https://svn.oss.deltares.nl/repos/openearthtools/trunk/ oet
Then copy the oet directory to the computer you have Matlab installed on. Start Matlab, change to that directory, and run oetsettings. Then, within Matlab, go in to applications/DelftDashBoard, and type ddb at the command line to start Delft Dashboard. From here, follow this tutorial to get started with making your own model.
I found Delft Dashboard to be pretty limiting and wanted to be able to create my own bathymetry, grids, and input files. For this, you want to use the Delft3D GUI, which is available only in binary form from the Deltares website.
Note: I have switched to using the GUI on Windows as described below.
You'll have to request the GUI binaries from Deltares by sending an email following the instructions here, under "temporary extra service." You will get access to the RPMs via an FTP site. Because this is Ubuntu, not Red Hat, and also because I wanted control over where the files were placed, I extracted the RPM to the local directory. I originally was going to convert the RPM to a .deb using the alien package, but that produced errors regarding 32-bit/64-bit incompatibility, so I did the following:$ rpm2cpio Delft3D-openhydromorpho-4.00.01-02.i386.rpm | cpio -idmv
This will produce the appropriate directory structure in the current directory. I moved opt/delft3d into /opt/delft3d in case any directories were hard-coded. Because this is a 64-bit system, you must install 32-bit libraries with
sudo apt-get install ia32-libs
You will also need to install the 32-bit libjpeg libraries:sudo apt-get install libjpeg62:i386
Now follow the instructions on the Deltares website to change the 5.0 directory structure to 4.0 directory structure and move the binaries as directed into /opt/delft3d (scroll down to "Using the GUI menu").
Finally, go into etc/profile.d (from the RPM you extracted) and edit delft3d.sh to point to the correct Delft3D locations. As in the official instructions, dot the profile so your environment variables are set up correctly.. etc/profile.d/delft3d.sh
Now change to delft3d/intel and run ./delft3d-menu. If all has gone well, you should be looking at the GUI screen! I had to set up a local X server on my Windows workstation and run the GUI on the Ubuntu modeling machine, tunneling X over SSH. If you are working locally on the Ubuntu machine, you won't have to do this.
Getting RGFGRID and other modules to run requires some editing of config files as described in this forum post.
You will also need to execute sudo apt-get install tcl8.4:i386 tk8.4:i386 for some of the menus to work properly in the GUI.
After a day or so of using the GUI to run the tutorials under Linux, I decided it was too buggy and gave the Windows GUI a try. This was a sanity-saving move. The Linux GUI kept crashing without warning when performing simple tasks in, for example, QUICKIN. Luckily, you can download the Windows binaries using the same username and password you got for the Linux GUI download, and use the same license file to run it. So far, I've found the Windows GUI to be much more stable. In practice, I generate all the input files (grid, bathymetry, MDF, etc) using the Windows GUI, and then I actually run the model on my Linux machine. I set up Samba on my Linux machine and mount the shared directory as a network drive on my Windows workstation. In this way I can access, modify, and save all the input files in the shared directory from the Windows GUI and then start the model from an SSH session on my Linux box. Then, I can analyze the output from within Windows (again, via Samba) where I have the latest Matlab and other tools installed.
This gives me the best of both worlds--relative ease of model compilation on Linux (no dealing with the horrors of compiling Windows executables) and relative ease of use and stability with the Windows GUI. If you have access to both operating systems, this would be my (admittedly beginner's) suggestion.
I haven't gotten any of the mpd/mpich parallelizing features of Delft3D to work. I have, however, implemented a kind of parallelizing queue to take advantage of the two cores on my modeling machine. I can run up to two simultaneous model runs at a time, and also have several runs waiting in the queue to run as soon as a core is freed up.
The system is very simple and is based off the supremely handy Task Spooler. The main thing to do is first run ts -S <num> with the number of cores/processors you have. Then you can add model runs (I keep input files for each run in separate directories) with ts -L <runid> ./run_flow2d3d_xml.sh. The -L <runid> is optional but helps with identifying the runs in the queue, which can be displayed with ts.
Alternatively, you could use make's -j option to specify the number of jobs to run simultaneously (inspired by this post). This is simpler in that it doesn't require installing any additional packages like ts above, but more limiting in that you must specify all the runs at the beginning, and can't add jobs at will.
Dan Nowacki firstname.lastname@example.org. Last updated January 2015.