After completing a first implementation of the stereo renderer, our group reviewed its mechanics and found that it was not very intuitive. The main problem was with the convergence controller, which is used to adjust the parallax of the scene. Negative values of convergence would put objects in front of the screen, and positive values would cast them behind it. However there was a problem with values close to zero, which would cause users eyes to become crossed and induce strain. The suggested next step was for Scott to write a sandbox application that used the same stereo setup commands, in order to see if this user­ unfriendly behavior was due to NVIDIA’s implementation, or something else happening in VAPOR’s rendering code. This sandbox application was written and exhibited the same behavior that was seen in VAPOR.

This lead Scott to continue researching other methods of stereo rendering, for which there were many. The best implementation that Scott found was by a scientist named Paul Bourke, who has published a series of papers on stereo rendering over the past 10 years. Paul’s technique did away with the glTranslate(separation) command that was being used by NVIDIA, which eliminated the cross-­eyed behavior that was caused by near-­zero values of convergence.

Scott also successfully implemented screen capturing for stereo rendering so that animations could be produced using this technique.

Scott was able to successfully implement vertical quadratic interpolation for layered and stretched grids in VAPOR. Originally this interpolation was written in the LayeredGrid and StretchedGrid classes. Scott decided to refactor the code and write it in the RegularGrid class to reduce code repetition and help with future code maintenance.Testing and verification was done using WRF and POP data. NCO was used for further verification, by using its ncrcat tool to downsample vertical levels in the data. With even slices removed from data files, the quadratic interpolation method was compared to the linearaly interpolated data that had full vertical resolution. The differences between the two were evident but very subtle

The next attempt at providing a transparent ocean map to KISTI was done using a product called Natural Earth. The Natural Earth image had very high resolution, which resulted in multiple versions of GIMP and Adobe Photoshop being unable to load the file. Scott corresponded with Matt Rehme of VETS on this issue, who noted that his group was getting a new Photoshop license and offered to see if it could load the large image. This proved successful and Matt applied an ocean mask to achieve a transparent ocean mask. Scott then converted this image into the GeoTiff format, however Vapor was unable to read the image, indicating that the extents were too large. Scott attempted conversions using the Tiff2GeoTiff tool distributed with vapor, libgeotiff, and GDAL. Eventually John indicated that this file needed to be tiled, which fixed the problem.

JinHee Yuk from KISTI was able to test the parallel data conversion script that Scott had written in September. However Tachyon2 (the KISTI supercomputer) was failing to launch the jobs she had submitted. These errors did not occurr on Irfan’s HPCFLab, which was supposed to have a nearly identical version of the Sun Grid Engine running on it. Scott  was able to replicate the reported behavior. Scott found that Tachyon2 required environment variables to be set that were not necessary on the HPCFLab, which made for a straightforward fix. Scott applied these variables in a new script called vaporTachyon.py and then ran performance tests on the scripts that could be reported to KISTI.

John wrote a progress report on the year's efforts at the request of KISTI. John also prepared his talk for the Korean Supercomputing Conference in Seoul.

A draft proposal for year 6 activities was submitted to KISTI for discussion.

Scott added error handling to certain GRIB functions that were exiting when being used with the recommended GRIB_CHECK error handler.

Alan has been fixing a number of bugs and other code changes in preparation for the 2.5 release.

Further re-factoring of the MPAS reader (DataMgrMPAS) was required. The original code was not correctly interpolating the unstructured grid. John re-wrote the code to take advantage of the Voronoi - Delauny duality, performing cell inside/outside tests, and interpolation using Barycentric coordinates (Waschpress for higher degree cells). The reader now supports both vertex and cell-centered data from MPAS-A and MPAS-O. However, support for edge centered data (e.g. w component of velocity) has not been implemented yet.

Scott met with Joanie Kleypass from CGD and had the opportunity to give her a demo of VAPOR in the VisLab. She was very excited about VAPOR’s flow rendering capabilities and was interested in seeing what Scott could do with her ROMS data. Scott made some visualizations of her product and plans on meeting with her for a further discussion of her data and what she would like to illustrate with it.