When LAS Starts it writes out a collection of Ferret journal files which are used as to initialize each data set when it is served by F-TDS. These files are written to $TOMCAT_HOME/content/las/conf/server/data.
And when LAS builds a dynamic data set to regrid a variable to to create a user defined variable, it will create new files an a subdirectory called "dynamic". LAS will attempt to create both of these directories when it starts. The Tomcat process must have write permission on the directory If the process of creating these directories fails, you'll see a message in the catalina.out log file.
The automatic configuration script will also attempt to create these directories for you. You will only run into trouble if you decide you want to use different directories after you have run the configure script or if there is a mismatch in how you configured F-TDS.
The information entered during the configuration process shows up in the FerretBackendConfig.xml file for LAS. For example:
http_base_url = "http://server.noaa.gov/las/output"
opendap_base_url = "http://server.noaa.gov/thredds/dodsC/output"/>
The three relevant attributes are las_ftds_data_dir where LAS writes the journal files, iosp_temp_dir where F-TDS writes the temporary files and iosp_data_dire where F-TDS writes any dynamic data set files for user defined variables or automatic regridding. The next section talks about how F-TDS uses this information.
In the LAS installation instructions you were asked to choose a directory for the LAS/F-TDS data set journal files. The directory must also be included as a dataScan element in the catalog.xml file which is used to configure the data sets to be served by TDS. For example:
<datasetScan name="Data From LAS" path="las" location="/home/las/conf/server/data" serviceName="gridded">
Because F-TDS is designed so that it can be installed independently of LAS, it has it's own FerretConfig.xml file. However, when installed in conjunction with LAS this file is a copy of the FerretBackendConfig.xml file used by LAS. If you're having trouble with your LAS, F-TDS and user defined variables check that these files are the same. Once you've verified your servers are properly configured, you can try a few more things to see where the problems lies.
Testing F-TDS in the browser
When an operation that depends on F-TDS fails, the first thing to check is to see whether or not the F-TDS URL works in the browser with the OPeNDAP HTML interface. Look at the debug file in the LAS output directory, or just resubmit the request with the &debug=debug appended to the end of the URL. Find the URL which fails, and paste it into a browser's navigation window and append ".html" to the end.
If the HTML interface appears, check to see the the newly defined variable (as defined by the symbol data_0_var) is listed in the variables for this data set. That's half the battle. The HTML interface means that the metadata is being generated properly. Now you can try to extract some data. Select one of the variables using the check box and click the "ASCII" button. You should see one data point from the data set or perhaps an error message from OPeNDAP.
If it fails, remove the "_expr_ and everything that appears after it and try again. If that succeeds where the previous did not, there might be a problem with the directory where the dynamic data files are written. You can also try extracting data from this URL by checking a variable and clicking the ASCII button. Look in that directory ($LAS_HOME/conf/server/data/dynamic by default) and see if any new files have been recently written to this directory.
The Debugging Logs
Both LAS and the F-TDS will write generous amounts of debugging information to the logs if you request that debugging be turned on. Here is the information for doing this in LAS. For F-TDS, you can turn on the debugging by following these instructions