Search
We are repeating the very successful course on Graphics and Visualization - Techniques and Tools. ll1is will be held at the University of Leeds the week commencing the 10th January 1994. The course will be staffed by Ken Brodlie (University of Leeds), Terry Hewitt (University of Manchester), John Lansdown (Middlesex University) and Phil Willis (University of Bath). This is a course for students of all disciplines. Last year we had to turn people away as it was oversubscribed. To ensure that you get an application form and further details, please send me a postal address.
As reported in the last newsletter, AGOCG are to run a workshop at the end of November on the requirements for multimedia in the UK Higher Education Community. This will lead to a strategic report. If you have not already indicated an interest then please do so soon to ensure you receive the call for papers.
We are hoping to carry out some form of evaluation of the hardware available in this area. We are interested to know what people are doing with desktop video at the moment:
If you would be prepared to answer a brief questionnaire on what you are doing then please let me know.
These are due out in early September to support the ERDAS and VISILOG deals. If you would like to ensure you get an order form (and have not already requested one) please let me have a postal address.
AGOCG are hoping to run a workshop on design issues for scientific visualization and to bring together scientists, graphic designers and artists. Are you interested in this? Could you contribute? Let me know.
AGOCG welcome proposals to carry out work on behalf of the community. If you have any ideas of work you would like to carry out then do contact me.
Work on the SERC/AGOCG-funded PHIGS Toolkit project at the University of Manchester has recently been completed, and the final version of the software is available. The PHIGS Toolkit is a suite of applications tools for PHIGS programmers, developers, researchers and educators, and is based on the experience of the developers who have been active PHIGS programmers for several years and were also involved in the ISO technical review of PHIGS and PHIGS PLUS.
There are two versions of the Toolkit available, 2.0 and 3.2, which offer the following support:
PTK 2.0: SunPHIGS 1.x on SunOS DEC PHIGS 2.3A on VAX VMS PTK 3.2: SunPHIGS 2.0 on SunOS HP PHIGS 2.2 on HP-UX IBM graPHIGS 1.02 on AIX PEX-SI on SunOS
Version 4.0, including support for PHIGS PLUS, is now available which supports SunPHIGS 2.0, HP PHIGS 2.2/2.3, IBM graPHIGS 1.02 and MIT's PEX-SI. The PHIGS PLUS extensions include an environments library, lighting editor and reflectance properties editor. They are available with the SunPHIGS 2.0 and HP PHIGS 2.2/ 2.3 versions of PTK only. A C binding to the Fortran PHIGS PLUS functions of HP PHIGS is also provided.
The software is freely available for non-commercial use, and for further information or instructions on obtaining the software by anonymous ftp, email or magnetic tape, please contact us.
Did you know there is a free electronic mail advisory service for PHIGS and PHIGS PLUS users in the UK academic community? Instigated in 1992 under the auspices of the Advisory Group for Computer Graphics, the intention of the service is to offer general advice about the PHIGS and PHIGS PLUS standards.
We should stress, however, that it is not a program debugging service! In fact the service operates according to the following ground rules:
Please note that the maintainers of the service, their institutions, AGOCG, and SERC will not accept any liability for information supplied, and a statement to this effect will be included with every response.
The service is hosted by the mailbase service at Newcastle, and operates as follows. To ask a question, send an email message to
chest-phigs@uk.ac.mailbase
Questions will be forwarded to support staff who will reply by email. For general information about the facilities provided by the mailbase service, send an email message to:
mailbase@uk.ac.mailbase,
containing the message help.
Did you know that you can produce very high quality colour film hardcopy from AVS using ULCC's Dicomed film recorder? ULCC has a high precision film recorder based around a Dicomed D148C, it uses 24 bit colour and can exceed the resolution limits of the film.
For some time now a specially developed dicomed avs output module has been available to AVS users at ULCC. This can be connected to the image output port of an AVS network and will generate Dicomed specific code under the full control of the user. The film subsequently plotted and processed is then sent back to the users specified address.
At the time of writing, film output is normally free to registered users although there are plans to introduce cost recovery charges some time in 1993. Every effort will be made by ULCC to keep costs to a reasonable level.
The dicomed module has been extensively used by ULCC AVS users but other AVS users may not have realised that they have the potential to access it quite simply using the AVS Remote Module facilities.
Details of how to access the dicomed module are given below.
The dicomed module is available on both pluto (Convex C3240) and neptune (Convex C3850) mainframes at ULCC. It is located in the directory: /ulcc/public/avs. It is also included in the /ulcc_public AVS library.
(For maintenance reasons, ULCC keeps AVS modules in various different places. Default location for standard ConvexAVS modules is /usr/avs/avs_library. ULCC supported modules (includes dicomed) is /ulcc/public/avs. Modules being tested before going into public are at /ulcc/trial/avs.
Modules that are provided as is i.e. very little support - usually AVS public domain modules are at /ulcc/other/avs. If you are using AVS on the ULCC machines, then to access the dicomed module simply follow this recipe:
The dicomed module can then be connectcd into your AVS network via its imagc port.
If you are using AVS on your own local machine then you should be able to access the dicomed module remotely, providcd that you are registered to use ULCC's services and can execute a remote process on the ULCC machine. For example, a quick test to see if you can access ULCC might be to execute a command something like the following:
/usr/ucb/rsh pluto.ulcc.ac.uk -n ls -1 /ulcc/public/avs
which should return you a list of ULCC public AVS files.
(You may also need to set up an appropriate .rhost file to get proper host authorisation - see your local documentation.)
For information about registration to use ULCC services, please ask your local computer centre or contact the Allocation and Control office at ULCC.
What follows is a brief summary of how to use a remote AVS module (see AVS documentation for a full description).
AVS uses a hosts file to find a remote module. This may either be your systems default hosts file (ours is /usr/avs/runtime/hosts) or you can create your own personal version (usually it is best to start with a copy of the default hosts file). If you have your own hosts file then you should also have your own .avsrc file that points to it. Your .avsrc file can be copied from your systems default .avsrc file (ours is /usr/avs/runtime/avsrc) and should be edited to include the location of your personal hosts file eg your .avsrc file might include a line like:
Hosts /home/username/avsstuff/hosts
The hosts file is an ASCII file that includes a line for each remote host specification; each line comprises four fields or columns. This is best shown by example:
Example hosts file entries:
pluto "/usr/ucb/rsh pluto.ulcc.ac.uk -n" /usr/avs/avs_library /usr/avs/data pluto_public "/usr/ucb/rsh pluto.ulcc.ac.uk -n" /usr/public/avs /usr/avs/data pluto_other "/usr/ucb/rsh pluto.ulcc.ac.uk -n" /usr/other/avs /usr/avs/data neptune "/usr/ucb/rsh neptune.ulcc.ac.uk -n" /usr/avs/avs_library /usr/avs/data neptune_public "/usr/ucb/rsh neptune.ulcc.ac.uk -n" /usr/public/avs /usr/avs/data
The four fields are as follows:
Once you have the hosts file set up, you should be able to start up your version of AVS and access the remote modules as follows:
The dicomed module can then be connected into your AVS network using its image port as before.
To understand fully the behaviour of the dicomed module it is important to understand the principles on which it operates. This background information should clarify what follows.
The dicomed module uses the Dimfilm library to generate a file of Dicomed-specific code. This file is opened when a film device is opened; calls to Dimfilm routines then write to the file until the device is closed (each film format is considered to be a separate graphics device). The file is stacked and plotted only if the device is correctly closed. So, if the process (or AVS module) that is using Dimfilm terminates while a film device is still open then the whole thing is lost.
The dicomed module automatically handles opening and closing of film devices for you. However, if the system should crash then the automatic film closing mechanism may fail. Manual film closing is therefore provided to guard against system crashes.
The module is very simple to use. There is a pair of radio buttons (two mutually exclusive buttons) for choosing between colour and black and white film and a button for taking snapshots - the Shutter Button. Sounds easy, but you need to know a little bit more.
A film device is opened when the Shutter Button is first pressed (but only if an image has been supplied to the module). The device remains open until one of four things happens:
When a film device is closed an entry is made in the file dicomed_log in your home directory, containing the date, time, number of frames and plot identifier (which appears on the banner and trailer frames of each film job).
A text-block at the top of the module's control panel provides some useful information, such as a running total of the frames processed in each film job (frame sequence). In addition, the status bar at the top of the control panel indicates progress with the processing of each frame.
There is one point which must be stressed here - if the system crashes while you are using dicomed you will lose the current film job. Therefore, when you are finished with this module it is wise to take one of the following actions:
The following parameters are initially invisible. Before using them you need to know what you are doing and why. To use them you need to assign a widget to the relevant parameter by using the Module Editor panel:
There is a right and a wrong way to use the dicomed module to process output from the render geometry module (aka Geometry Viewer). The render geometry module has two output ports - one in pixmap format and one in image format. Unless you are using a 24-bit colour X-server, the only way to get proper 24-bit images from render geometry is via the image format output port. The dicomed module only accepts image format data. Therefore always connect directly to render geometry rather than via the pixmap to image module. It is necessary to activate the Output Image button on the render geometry control panel (not the Geometry Viewer panel) otherwise no image format data is generated and the dicomed module does nothing.
It is important to note that the view seen in the display pixmap window is not necessarily the same size and shape as that produced at the image output port. Often an object that appears to fit in the pixmap window will extend beyond the edges of the image area. To check how the image will appear on film you need to view the image output with a module such as display image.
The image shape and resolution is controlled by the module creating the image. For example to change the width and height of the output image from the "render geometry" module you first need to make the width and height widgets visible by selecting them from the Module Editor panel (this is obtained by clicking with the middle mouse button on the small square at the right side of the render geometry module). The defaults of width 640 and height 484 can then be overridden, for example higher values increase the effective resolution although AVS appears to have an upper limit of 1280 by 1024 at present.
The relationship between the width and height gives the aspect ratio and thus a landscape or portrait image shape. The default action for the dicomed module is to orient the image on film so as to maximise the plot size as defined by the width and height parameters. For a portrait shaped image this means it will rotate the image 90 degrees anticlockwise on the film. If you really don't want this behaviour you can override it using the orientation parameters obtainable from the Module Editor panel.
The Dicomed module was initially written by Gideon Amos at ULCC and is now maintained by Matthew Wheeler.
As this software is new, it is still evolving. Please send any comments to me.
(Re: "Review of PostScript Previewers" in G&V issue 28)
I was interested to see the publication of a review of PostScript previewers. As with all reviews they become out of date all too quickly.
The latest version of Ghostscript is 2.6 and is notably better over the much older 2.4 version reviewed. There are also two different full X interfaces to Ghostscript not mentioned in the review, gspreview and ghostview, which both provide a similar level of functionality to that of the DEC previewer reviewed. This functionality includes the ability to view pages at various scale factors, move backwards and forwards through documents page by page and rotate pages.
Due to the use of the Ghostscript rendering engine both gspreview and ghostview can be used with any terminal/workstation running X unlike Sun's PageView and DEC's PostScript Previewer which require vendor specific X server extensions.
gspreview and ghostview are both available from the UNIX HENSA archive (unix.hensa.ac.uk) under the /uunet/pub/window-sys/X/contrib and /uunet/systems/gnu directories respectively.
FEUSERS is a mailbase-list serving the researchers, teachers and groups active in using and developing FINITE ELEMENTS and FINITE DIFFERENCE software. Code developers and vendors of finite element and finite difference packages are particularly encouraged to be involved in FEUSERS. Users and developers of graphical pre- and post-processing systems (with solid modelling) and CAD/CAM interfaces for finite elements and finite difference applications software are also encouraged to participate. Industries and industrial participants with a solutions approach would be highly appreciated at this forum.
The FEUSERS forum aims to encourage discussion and free exchange of ideas amongst the members of the list. As a list member, you are free to raise a topic and express your views on it, invite other views and even summarise them. You can also respond to a topic currently under discussion.
All postings to the group are distributed to all the list-members, and the list will not initially be moderated.
Discussion topics on finite element and finite difference applications areas such as structural and mechanical engineering, analysis and design, aerospace engineering, electronics and electrical engineering, computational fluid dynamics, heat and thermal analysis, impact analysis, chemical engineering, nuclear and solid state physics, etc. are highly desirable. Specific suggestions and questions on various packages (e.g. ideas, patran, abaqus, nastran, lusas, emas, fidap, phoenics, etc) could be beneficial for many finite element and finite difference users and developers.
The forum encourages notices and discussion on finite element and finite difference references, books, journals, publications, information, projects, collaborations, proposals, funding, hardware, software, organisations, visits, shows, standards, education, research, development, jobs, conferences, surveys, etc.
To join the list and become a list-member of feusers, E-mail the following line:
join feusers <YOUR_Firstname> <Your_Surname>
to mailbase@uk.ac.mailbase. To send in your contribution to the list, E-mail the item to: feusers@uk.ac.mailbase.
