Is www the ideal support for scientific visualization

Is WWW the ideal support for scientific visualization?

Giuseppe Zito : Giuseppe.Zito@cern.ch


Abstract:

I report here on the use of hypertext written in html to document my research work in the scientific visualization field with subsequent use of www to communicate my work to colleagues, and to "publish" it.

Index

Introduction

Scientific visualization is about new ways of doing and communicating scientific research. Beyond the visualization tools is a rich visual world made from hundreds of images, animations, etc. As everyone working in this field, I have dreamed of writing the perfect scientific visualization paper...

Before www I had the following alternatives:

In the end the only way to communicate your research to colleagues, was to show the images directly on the screen of your computer. But in the last year some technical advances i.e.: have made the use use of www+html a feasible alternative.

How to publish the perfect scientific visualization paper

Hypertext written in the html language can now be used to document the individual research work in the visualization field. Then Internet with www can be used to communicate it. We can now at last publish the perfect paper with tons of images and we get for free some outstanding advantages: The last one is the bigger benefit, at least from the point of view of the researcher that can now be busy full time producing new images and make them instantly available to Internet by posting the information on the URL to the relevant newsgroup or sending it by mail to colleagues.

In the following sections I will consider more in detail some aspects of my experience with writing and publishing scientific visualization hypertexts.

The private hypertext

When you start working with hypertext, you discover very soon that from the point of view of the developer, there is only one hypertext, where all your knowledge is contained. This is what I call the "private hypertext". This is like the old fashioned research logbook where you note everything you do, so you can recover it lately. Here you glue images or their electronic equivalent. Here you try different ways to explain your research in words. This hypertext will support your project in every phase of its development cycle, from design to prototype building, to development,test and maintenance of the final code.

In my case I have developed tools to allow the fast scanning of scientific data put in graphical form. The research itself was presented with a paper on: "Scanning huge numbers of events" to the conference Computers in High Energy Physics 94 (CHEP94) .

A lot of code has been developed and tested with a large data set. Many hundreds of thousand of images have been produced. A small subset of them has been stored on disk. Its size including external documents is around 1 Gbyte.

The development of this hypertext was done using Mosaic and the usual set of external viewers on a DEC Alpha Openvms workstation. There is no www server on the cluster so to publish the hypertext I use another computer . This is a good thing in terms of security since it keeps your private hypertext secure from hacker attacks.

The publishing process of the public hypertext is performed by extracting and copying part of the private hypertext to the node with the server. After the copy the public hypertext is linked to the private hypertext becoming a integral part of the latter.

Write on the world your knowledge of the world

The hypertext format has the following outstanding advantage over a logbook : you can not only write the information,but you can put it to work just by clicking on a hyperlink pointing to that chunk of information. In the private hypertext, I have linked not only the whole data base of documents(text,images,animations) but also the procedures used,i.e. the "actions" needed to perform all the tasks .

This technique makes easier the development of software since now you write your knowledge of the complex world connected to programming exactly in the place where it is needed. It is like pasting the instructions on how to open a (difficult to open) door directly on the door itself, so you don't have to keep them in your head. But on the computer you have the added advantage that you can click on the instructions to get them carried out, and you can also link in the same place the result of your action in the form of printouts or images.

Not always you are able to execute the procedures by clicking on them,but they can guide you the next time you perform the same task. This happens for example with tasks where you have to process information on computers outside the local network. For security reasons these action links(indicated in the hypertext as local files) can be activated only locally.

The public hypertext

The communication of this work to the conference and to my colleagues was a formidable task: the material (mostly pictures) needed to document it properly is at least 10 Mbytes of pictures but the report to be published in the proceedings of the conference was limited to 3 pages! The solution found was a hierarchy of documents with the printed document pointing through a URL to a public hypertext ,which was extracted from my private hypertext. The public hypertext takes around 30 Mbytes of disc space and is spread on two different Internet nodes. The space on one of the two has been kindly offered by people interested to my work.

For security reasons and to keep the maintenance easier, the public hypertext has no "action" links but only links pointing to files containing images or text. The animation (done with a action link in the private hypertext) could have been shown in the public one by encoding the pictures with a MPEG encoder,but I settled in the end on showing the animation frames in groups of 30 in subsequent JPEG images. This gives a good idea of the original animation, since each image shows around one second of the original animation.

Maintenance issues

Although the creation of the hypertext with a text editor is trivial, its maintenance creates many problems. For example the extraction of part of the hypertext and its copy to another node although not difficult is rather clumsy if done by hand.

The test of the hypertext to check for example for the presence of dead leaves would benefit from the use of some automatic tool. The same thing can be said about the "hard copy" of the hypertext to produce transparencies or printouts to be sent to colleagues with no Internet access.

Conclusion

This experience has prompted some interesting questions: Will this be in the future, our usual way to document,communicate and publish our research? Should the printed final document be suppressed and perhaps replaced by hypertext published on cd-roms? How reliable is the "public" document published by giving the URL? Should it be considered at the same level as the printed document? How much time should the public hypertext kept on the server? Am I allowed to change it after it has been "published"?

Bibliography