krj@na.toronto.edu (Ken Jackson) (04/10/89)
NA Digest Sunday, April 9, 1989 Volume 89 : Issue 14 Today's Editor: Cleve Moler Today's Topics: Vectorized Cyclic Reduction Routines Registration Fee at Computational ODE Conference Formation of Numerical C Extensions Group (NCEG) Mini-Conference on Preconditioned Conjugate Gradient Methods Wanted: Scientific Images and Image Sequences Extended Precision Inner Products on MC168881 ------------------------------------------------------- From: Michael Page <munnari!monu1.cc.monash.oz.au!apm388p@uunet.UU.NET> Date: Mon, 3 Apr 89 12:43:13 EST Subject: Vectorized Cyclic Reduction Routines Vectorised Cyclic Reduction Routines I am currently moving some fluid dynamics code from a VAX to a Cray X-MP/1 and would like to know of the availability of any public-domain (or cheap) vectorised code for solving Poisson's equation directly using cyclic reduction. Equivalently, I am after a routine to solve a block-triadiagonal matrix of the form a(i)x(i-1,j) + b(i)x(i,j) + c(i)x(i+1,j) + d(j)x(i,j-1) + e(j)x(i,j) + f(j)x(i,j+1) = g(i,j), which is vectorised for a Cray. I am aware of the BLKTRI routine, from the NCAR library, but do not have access to a vectorised version (also, I'm told there is a bug deep within it which leads to slightly inaccurate results). Any assistance or suggestions would be appreciated, to save me from reinventing the wheel. Please mail responses to apm388p@monu1.oz.AU (or apm388p%monu1.oz.AU@uunet.uu.NET if .AU isn't defined) but *please* don't send code before checking with me first. Michael Page Department of Mathematics, Monash University, Melbourne, Australia. ------------------------------ From: Hans J. Stetter <E115N06%AWITUW01.BITNET@Forsythe.Stanford.EDU> Date: 04 APR 89 16:18:12 Subject: Registration Fee at Computational ODE Conference The Conference on Computational Ordinary Differential Equations, Imperial College, London, 3 - 7 July 1989, has been planned and prepared as the out- standing event in the area for 1989. A wide and representative attendance is to be expected. Recently, the registration forms for the conference have been sent out; accordingly, the conference fee for the event is 185 British pounds, i.e. approximately 320 US dollars or nearly 600 DM. It is true that this includes refreshments and lunches during the conference; but not everybody will wish to have a set lunch anyway. For members of the IMA there is a discount, for late registrants there are fines. This registration fee is an order of magnitude above that of previous Numerical ODE Conferences, it is more than four times the fee charged at this year's Dundee Conference, and about twice what has been and will be charged at huge international conferences like ICIAM. This fee will seriously limit participation of interested scientists from Europe; in my department, it will halve the number of people that can attend. I believe that the NA community should not accept this outrageous fee without protest as it may set an example for further meetings. ( Note also that the conference will be held on university premises.) I am looking forward to receiving comments and suggestions for proper action. Hans J. Stetter, E115N06@AWITUW01.bitnet ------------------------------ From: Rex Jaeschke <aussie!rex@uunet.uu.net> Date: 5 Apr 89 03:16:38 GMT Subject: Formation of Numerical C Extensions Group (NCEG) Recently, I formed a Numerical C Extensions Group (NCEG) to add extra support to the C language and library for numerical applications. Quite a few of the major players in this area have agreed to attend the first meeting to be hosted by Cray Research on May 10-11. I would appreciate any feedback on the proposal below. Thanks. This proposal was mailed to all ANSI/ISO C Standard members, about 10 days ago. Please respond via private mail. Rex Jaeschke Numerical C Extensions Group Formation Introduction ============ As some of you know, for some time I have had an interest in standardizing extensions outside of X3J11. Thus far, my role has been to convene an extensions meeting one evening during each X3J11 meeting week. And while each extensions meeting was well attended, only the two or three regular presenters really participated. In September, we at X3J11 decided we had done the best job we could and voted to forward the standard to X3 for final approval. And although that has not yet happened, all indications are that it will without further committee deliberation. As a result, the X3J11 meetings will be held less regularly and for shorter periods. That coupled with the fact that many (most?) of the regular X3J11 attendees have little or no interest in the numerical marketplace at this time, makes X3J11 an inappropriate forum for efforts to standardize extensions, at least in the numerical direction. Certainly, any effort to standardize extensions must be done with X3J11's stated goal and future directions in mind. One of the principle reasons complex and the like are not in the first version of the standard is the lack of prior art and in some cases, the lack of consistent prior art. Only once an extensions group can form consensus within their own ranks can they reasonably expect a formal standards body to consider adopting their extensions. The First Step ============== As a result of my involvement in X3J11, my writing and teaching interests, and of my starting The Journal of C Language Translation, I have formed an extensions group. The name of that group is ``The Numerical C Extensions Group'' (NCEG) and its broad purpose will be to standardize extensions to the preprocessor, language and/or library as appropriate to sell to and/or satisfy the increasing interest in C being shown by the numerical community. Who am I to start such a group? -- What I lack in implementation details I make up for in enthusiasm. Besides, there are plenty of competent people out there who can provide the technical details. -- I have no commercial interest in the outcome of such extensions and can therefore, provide some unbiased leadership. -- If others are really interested in making it work I have the time and resources to commit. -- I offer the services of The Journal for ongoing publicity of the groups' decisions and activities. At the very least, Tom MacDonald of Cray Research (and The Journal's Numerical Editor) will provide regular coverage. -- If I don't start something will you? (I don't mind sharing the ``glory'' and the work.) Getting Together ================ We are already at the point where more than a few companies are interested in the idea of NCEG. However, unless something formal happens soon their interest will wane and they will ``do their own thing'' anyway, or at best, sound off a few ideas with others via e-mail. Cray Research has agreed to host an inaugural NCEG meeting at their Mendota Heights facility in suburban Minneapolis, Minnesota on May 10--11. That gives you time enough to decide on your level of participation, if any. The meeting needs to take place before the summer break when many of you may be vacationing, plus one or more of the participating vendors may well be shipping product containing numerical extensions by the end of the year. The longer we leave it to get started the harder the task will be. Inaugural Meeting Format ======================== I propose a 1 1/2 day format for the following reasons: -- It will take quite some time to address administrative issues before even looking at technical solutions. -- Staying overnight gives attendees a chance to get together over dinner and discuss ideas. I find that sleeping on decisions made the previous day can often result in changes and improvements. -- Finishing by lunch the second day gives everyone time to catch a flight out that afternoon. A reasonable format would be to break the day into four formal periods, two each in the morning and afternoon. Have a two hour lunch to get informal discussions going and to have people meet each other. Wed: 9:00 -- 10:30 session 1 10:45 -- 12:15 session 2 12:15 -- 2:15 LUNCH 2:15 -- 3:45 session 3 4:00 -- 5:30 session 4 Thu: 9:00 -- 10:30 session 1 10:45 -- 12:15 session 2 Meeting Agenda ============== It is clear to me that the thing we don't want to do immediately on the first day, is to start producing technical specifications. In fact, if all we achieve in both days is a consensus of what the issues really are, and in which corners each company stands, we will have been wildly successful. I believe a reasonable plan of attack is to: -- Identify any existing prior hardware and software art. -- Identify existing and pending formal and de facto standards and establish a liaison with them. (X/OPEN, OSF, POSIX, X3J11, GKS, and ISO immediately come to mind. Maybe even Fortran 8X.) -- Identify and prioritize the technical issues into the following categories: :-- Must have now or as soon as possible. :-- Can live without for the time being but eventually need/would like. :-- Wishful thinking; ``Gee, wouldn't that be nice stuff''. -- Recognize, accept and rationally deal with the problems created when competing vendors and conflicting commercial interests arise. -- Identify, as soon as possible, those areas that such a group cannot, or chooses not to, standardize. Meeting Rules ============= Although I was not involved with X3J11 at the very beginning, I have attended all but about seven meetings. (X3J11 votes by majority rules.) I have also attended three ISO C meetings where voting is by consensus. As a result, I propose that we remain as informal as possible. In particular, given the specific nature of the task, the small number of participants and the potential commercial conflicting interests, I propose working by consensus rather than simple or two thirds majority vote. It makes no sense for the group as a whole, to have one or two vendors be quite opposed to some idea and go do it their own way anyhow. If such situations cannot be resolved fairly quickly, those issues may have to go into the ``unspecified'' or ``implementation-defined'' bin. Unless someone else wants to arm wrestle me for the role of convener/chair I am happy to serve in that capacity. Apart from that we would need a secretary--perhaps a different person each meeting so the workload can be spread around. Beyond the First Meeting ======================== I would expect that by the end of the first meeting we will have identified most of the ``Must have now or soon'' goals and that we will each have volunteered to be the focal point for, or to actively participate in, one or more interest groups. We will also have exchanged e-mail and postal addresses and phone numbers so that the ``real'' work can get under way. It would probably be useful to identify a date and host for the following meeting. Of course, meeting frequency can be determined as necessary and probably no more than two or three times per year. Once we get organized it would be desirable to schedule them along with X3J11 meetings. Also, we would need a volunteer to do a mailing of minutes, etc., to all companies we have ``registered'' as intending to participate. Meeting attendance must not be necessary for NCEG participation and so there needs to be a way for proposals, etc., to be circulated in paper form. Committee Status ================ As stated earlier, initially NCEG would have no official status. However, it is expected that most, if not all, member companies would also be X3J11 members. If a useful numeric extensions package can be agreed upon, it certainly should be submitted to X3J11 and POSIX for their consideration, however. Regarding the adoption by a formal standards group--it is quite possible that even if we don't violate X3J11, they may not adopt any or all of our proposals simply because the general membership won't want to be forced to implement things their customer base don't need. The only way this might work is if future versions of the standard are defined as ``Base plus optional packages'' as other language standards are. While we certainly don't want to go against established practice, I see the main role of NCEG as defining a de facto standard. If we all agree on the details, our efforts must be successful, by definition. Then, if we have done our homework thoroughly, we'll also have the official (or, perhaps, unofficial) backing of one or more standards groups. What Can You Do? ================ -- Let Tom MacDonald or I know as soon as you can if you are interested in NCEG. This is for your benefit as much as ours so we won't come chasing after you. If less than 8--10 companies commit to attending the first meeting THAT MEETING WILL LIKELY NOT BE HELD. -- Give me constructive feedback on this whole proposal, even if you don't intend to participate in the group now or at all. -- If you want to participate, identify the people in your organization who will likely attend and/or provide input. Even if you cannot attend the meeting, make your submissions anyway so that I can make sure they get a hearing. -- Identify your company's numerical needs and categorize them into the three groups named earlier. Make sure you have a good idea about which things you are prepared to ``go to the wall on'' and which you are not. (Nothing useful will likely result without compromise.) -- Offer to become the focal point for a particular topic. (I'm sure Tom MacDonald would LOVE to handle complex since that's his top priority.) -- Tell anyone who might be remotely interested in what I am proposing. Technical Issues ================ I have identified the following possible issues. (I'm sure there are many more.) They are in no particular order. -- complex -- IEEE issues including infinity and not-a-number handling -- float.h -- need for something like {__NCE__} predefined conformance macro -- validation suite -- matherr and errno -- vector/parallel processing (including array syntax) -- aliasing -- variably dimensioned arrays -- Fortran interface -- issues with existing math library -- numeric applications libraries What Happens Next? ================== I announced the group's existence in the free sample issue of The Journal which was mailed in Mid-March. (About 1500 copies were distributed world-wide.) We'll schedule the meeting and if your level of commitment is reasonable, we'll hold it; if it is not, we'll cancel it. And depending on our understanding of the problem we'll either reschedule it or drop the whole idea. If you want to discuss this proposal or related issues, contact Tom MacDonald or myself as follows: Rex Jaeschke, The Journal of C Language Translation, 1810 Michael Faraday Drive, Suite 101, Reston, VA 22090, (703) 860-0091, uunet!aussie!jct. Tom MacDonald, Cray Research, Inc., 1345 Northland Drive, Mendota Heights, MN 55120, (612) 681-5818, tam@cray.com, uunet!cray!hall!tam. Hotel and Meeting Details ========================= The meeting will be held at Cray's facility located at: Cray Research 1345 Northland Drive Mendota Heights, MN 55120 If you wish to provide handouts of technical submissions, etc., please bring 30--40 copies since on-site duplication facilities will be limited. (At the time of writing, the number of people who have indicated their interest in attending is at least 15--20.) Accommodation is available within walking distance at: Mariott Courtyard 1352 Northland Drive Mendota Heights, MN 55120 (800) 321-2211 (612) 452-2000 Their standard room rate is $62 per night. You may get a corporate rate if you ask. A block of rooms has NOT been reserved; each of you must take care of your own reservations. The hotel has an indoor pool, whirlpool and small exercise room, and a reasonable restaurant. Airport limo service is available on demand from 6:30 AM till 11PM, free of charge. (The hotel is only 10--15 minutes from the airport.) If you rent a car at the airport, take 494E to the Pilot Knob exit. You can see the hotel from the freeway and you make your way to the local service road to get to it. Mendota Heights is about 15 minutes from downtown St. Paul and 25 minutes from downtown Minneapolis. Please advise either Tom or I if you plan to attend the meeting so we can arrange for an appropriate size room and refreshments. Rex Rex Jaeschke | C Users Journal | Journal of C Language Translation (703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101 uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA ------------------------------ From: Victor Eijkhout <U641000%HNYKUN11.BITNET@Forsythe.Stanford.EDU> Date: Fri, 07 Apr 89 18:30:24 MET Subject: Mini-Conference on Preconditioned Conjugate Gradient Methods MINI CONFERENCE ON PRECONDITIONED CONJUGATE GRADIENT METHODS To celebrate the 13th, the 17th, 31st, and 37th birthdays of the Preconditioned Conjugate Gradient Method a miniconference (workshop) will be held at the University of Nijmegen, the Netherlands, on June 19-21, 1989. The preconditioned conjugate gradient method has undergone rapid developments and found wider applications in recent years. The method has been generalized to nonsymmetric and indefinite problems, preconditioning methods of optimal order of computational complexity have been found, new areas of applications (such as for spectral methods) have been seen, and the method has been quite successfully adapted to parallel and vector computers. The aim of the conference is to report on these and similar topics and to offer the possibility of discussing the topics in the presence of many specialists. The conference will have a number of invited talks, as well as contributed talks. The deadline for submitting abstracts (one to two pages) for contributed talks is May 10, 1989. Notification of acceptance will be given by June 1, 1989. Each participant to the conference should make his own hotel reservation. A list of convenient hotels is included in the information leaflet. Please indicate your interest in attending or contributing a paper as soon as possible. The conference fee is f150, which includes refreshments at coffeebreaks, and conference proceedings. (The present exchange rate is US$1=f2.13.) For the organizing committee, Owe Axelsson. Organizing committee: O.Axelsson, B.Layton, L.Kolotilina, V.Eijkhout, J.Maubach, B.Polman. Honorary member: David M. Young. REQUEST FOR INFORMATION Yes, I am interested in attending the miniconference on PCG methods. Send me more information. I do/don't plan to submit an abstract for a contributed talk. Name: Adress: email: send to: V. Eijkhout u641000@hnykun11.Bitnet or: V. Eijkhout Faculty of Mathematics and Computer Science University of Nijmegen Toernooiveld 5, NL 6525 ED Nijmegen the Netherlands ------------------------------ From: Martin Knapp-Cordes <martink@ncsa.uiuc.edu> Date: Fri, 7 Apr 89 18:28:32 CDT Subject: Wanted: Scientific Images and Image Sequences Wanted: Scientific Images and Image Sequences The National Center for Supercomputing Applications and Apple Computer, Inc. are making preparations to cut a compact disk to be distributed at AUC in July and at ACM SIGGRAPH '89. The Apple Science '89 CD will contain the NCSA Scientific Software Suite for the Macintosh (NCSA Image, NCSA DataScope, NCSA PalEdit, NCSA Layout). In addition to these programs, we will include approximately 300MB of images and animation sequences from researchers around the world. All images used will be fully credited. NCSA is seeking examples of images that you have used in your research. FIRST PRIORITY WILL BE GIVEN TO IMAGES GENERATED FROM SCIENCE AND ENGINEERING CALCULATIONS AND THE DISPLAY OF SCIENTIFIC DATA. Here are the details. 1. TYPE - Raster images and/or numerical data to produce raster images ONLY. 2. BITS OF COLOR/GRAYSCALE - HIGHEST PRIORITY TO 8 BIT. SOME 24 BIT IMAGES ARE TO BE PUT ON THE CD. However, the NCSA tools cannot deal with 24 bit images currently. If your 24 bit images can stand it convert them to 8 bit before submitting. That will increase your chances of getting on the CD. 3. DEADLINE - First priority will be given to those that arrive by April 21 at NCSA. Our absolute production deadline is around May 15. 4. CATEGORIES - you may submit in any or all categories. Please submit only what you think are your best. Don't send us volumes, because our review process can't handle it and they may be ignored. 4.1 single - standalone image of unusal value. 4.2 group - sets of images that may be related but not intended to be animated. 4.3 animation - sets of images which are intended to be played in sequence for example by NCSA Image. 5. CREDIT - For EACH example in EACH category you submit please include a textfile with the following information. BE AS CONCISE AS POSSIBLE! Title: (Give some name or title for the image(s) - SHORT!) Description: (Describe the science and the content of the image(s). Please include the size and the # bits of color or grayscale.) Generation: (Software/hardware used to generate and/or display the image) Author(s):(name and address. E-Mail and Telephone numbers are optional) Reference(s): (optional list of references) 6. Format - We prefer to deal in one of five formats 1. raw raster - (8 bit) (bytes in row order, left to right, top to bottom). NO HEADERS OR TRAILERS! (24 bit) (RGB format) (red bytes in row order, left to right, top to bottom, followed by Green, and then Blue) NO HEADERS OR TRAILERS! 2. raw palette - (8 bit) (RGB format - 256 bytes of red, followed by Green, and Blue) NO HEADERS OR TRAILERS! 3. Sun raw raster - Sun users will know about these. 8 or 24 bit. 4. NCSA HDF - NCSA Hierarchical Data Format - Familiar to some NCSA users. People using the current version of NCSA Image or NCSA DataScope will know about these. 5. ASCII data - if numerical data sets for example to use with NCSA DataScope supply the data as follows: (2-D data sets ONLY!) nrows ncols max_value min_value row1 row2 . . . col1 col2 . . . data1 data2 . . . . . . Note: 1. Only the order is important. Otherwise free format. Arbitrary white space and newlines can separate each floating point number or integer. 2. Max and min define the range of number values in the range of interest. 3. row and column values define the values of the two independent variables. 4. the data or dependent variable is ordered in row order, left to right, top to bottom. 6. How to send - Use one of the following means. 1. Mail MAC disk(s) 2. Mail a UNIX tar formatted 1/4" cartridge or 1/2" real tape (large files or animations) 3. ONLY AS A LAST RESORT SEND SMALL FILES (<=.25 MB) VIA E-MAIL. THEY MUST BE in binhex/SuffIt format! TO: Susan Goode - Science '89 CD Project NCSA - Software Development Group 269 Computing Applications Building 605 East Springfield Avenue Champaign, Illinois 61820 sgoode@ncsa.uiuc.edu We believe that it is the intent of Apple Computer, Inc. to make available to each successful contributor a free copy of the Apple Science 89' CD. Best Regards Martin Knapp-Cordes martink@ncsa.uiuc.edu (217) 244-0704 ------------------------------ From: Ian Cavers <cavers@cs.ubc.ca> Date: 6 Apr 89 21:01:52 GMT Subject: Extended Precision Inner Products on MC168881 Hi. We want to accumulate inner products in extended precision on a Sun 3/50 (SunOS 3.2 or 4.0) with a MC68881 coprocessor. In other words we want to take the inner product of two floating point vectors without rounding the product of each pair of elements to double precision before adding it to the sum. Once the sum of the products has been accumulated in extended precision it will be rounded to double precision. I believe that the only way to ensure such inner products are actually executed entirely in extended precision is to use assembler language to control the MC68881. (The Sun Fortran compiler only supports single and double precision, not extended precision.) If anyone can help me with this problem I would appreciate it. I would like to avoid the effort of writing an inner product routine in assembler myself if I can. Thanks in advance for any help. Ian Cavers (email: cavers@cs.ubc.ca) UBC Department of Computer Science, Vancouver, B.C., Canada ------------------------------ End of NA Digest ************************** ------- Reposted by -- Kenneth R. Jackson, krj@na.toronto.edu (on Internet, CSNet, Computer Science Dept., ARPAnet, BITNET) University of Toronto, krj@na.utoronto.ca (CDNnet and other Toronto, Canada M5S 1A4 X.400 nets (Europe)) (Phone: 416-978-7075) ...!{uunet,pyramid,watmath,ubc-cs}!utai!krj