A transient solution is presented which models the fluid-solid interaction of a thin elastic prolate spheroidal shell loaded end-on by a nonconservative acoustic shock wave. Solutions to the Lagrangian equations of motion are provided for the normal and tangential shell displacement fields, as well as for the incident, scattered and radiated fluid pressure fields. The explicit analytic solutions converge uniformly and absolutely to the exact solution of the actual coupled differential equations over the entire temporal and spatial domains both in the structure and in the fluid. Numerical results for the free vibrations and for the transient fluid-solid interactions of a fluid-loaded prolate spheroidal shell are presented. As in the case for the spherical geometry, the fluid loading is shown to down shift the frequencies and to introduce additional proliferant structural frequencies. Insights into the qualitative and quantitative effects of the fluid on the structural response are revealed. DOE-MACSYMA was used extensively to develop and verify the solutions.
The Lawrence Livermore National Laboratory (LLNL) developed an efficient, numerical, general purpose, time domain, structural acoustics simulation code called PING. The design of the code was guided using the fundamental understanding of fluid-solid interaction develped while completing the aforementioned analysis. PING is the marriage of the implicit structural response NIKE3D code with an explicit DYNA3D-like scalar acoustic fluid field module. The purpose of this work is the verification of the PING code for the study of transient coupled fluid-solid interaction problems. Both the time history response of the shell structure and the propagation of acoustic energy into/from the surrounding medium are considered. A spherical case study is presented. The approach employed was to calculate the exact analytic solution using the symbolic algebra code called PARAMAX, compute the finite element solution using PING, and compare the time history plots for shell displacements and accelerations and for the fluid pressure at the fluid-solid interface. The frequency content of the analytic and finite element solutions is also compared and discussed. Excellent agreement between the PING results and the 16 mode analytic results is demonstrated.
Java's floating-point arithmetic is blighted by five gratuitous mistakes:
Linguistically legislated exact reproducibility is at best mere wishful thinking.
Of two traditional policies for mixed precision evaluation, Java chose the worse.
Infinities and NaNs unleashed without the protection of floating-point traps and flags mandated by IEEE Standards 754/854 belie Java's claim to robustness.
Every programmer's prospects for success are diminished by Java's refusal to grant access to capabilities built into 95% of today's floating-point hardware.
Java has rejected even mildly disciplined infix operator overloading, without which extensions to arithmetic with everyday mathematical types like complex numbers, matrices, geometrical objects, intervals, arbitrarily high precision, and decimal strings become extremely inconvenient.
To leave these mistakes uncorrected would be a tragic sixth mistake. But Sun's latest proposal dated May 1998 would make a worse seventh mistake. To offset performance degradation imposed upon Intel-based PCs and clones by Java's first mistake, this new proposal would so relax the language's requirements as to render floating-point arithmetic on these popular machines more unpredictable and capricious than it used to be on the old Sun III computers whose compilers notoriously abused the otherwise excellent arithmetic in their Motorola 68020-68881/2.
Fortunately, there is a fair chance that this misbegotten proposal will be withdrawn if Sun receives sufficiently many knowledgeable protests from the computing community. Experts in the development of portable numerical software learned long ago how to get around the inadequacies in Java's floating-point since these were widely to be found in the programming languages and hardware of the 1960s and 1970s. Now hardware is much better, and so is our understanding of the way computers ought to support the use of floating-point arithmetic by programmers whose expertise lies elsewhere; but Java reflects none of that understanding, as if the considerable floating-point expertise now available within Sun had been disregarded when Java was designed. Only if the community of software users and producers becomes aware of what is now missing in Java, and then lets the arbiters of taste and fashion in the world of programming languages know what our community needs, can we expect Java to get better instead of merely faster.
The subject of the talk is the design of an algorithm to compute the geodetic latitude and altitude of a point (spacecraft or submarine) above or sightly under the surface of an oblate-spheroidal planet, with a priori proven estimates of accuracy (taking into account the mathematical approximation of the algorithm and the rounding errors from the computer). For the current version of the algorithm, my current estimates guarantee a millionth of a degree for the latitude and one millimeter in the altitude, for any point from the deepest ocean to the edge of the galaxy. (There is an "exact" solution by solving a quartic equation, but apparently no upper bounds on the errors caused by rounding.)
This poster paper will discuss the use of object-oriented software design principles to create a reactor safety analysis tool that will combine the capabilities of thermal-hydraulic and structural analysis codes. This combination of capabilities will allow the simulation of reactor accidents to proceed past the point when structural damage begins to change the geometry of the flow network. The paper will discuss the use of evolutionary development of the program architecture and the use of component abstraction that maintains architectural flexibility and preserves numerical efficiency.
A critical area that must be addressed when numerically solving PDEs when using discrete methods is mesh generation. This is especially true with complex geometries that have a large variation in feature sizes that must be faithfully captured by a discrete computable mesh. Typically, the method used to numerically integrate the set of PDEs of interest defines the type of mesh that is required. The types of meshes that I deal with are structured and unstructured meshes of the finite element, finite volume, Delaunay, or Voronoi types. The elements that I use to generate meshes cover the range from the degenerate finite elements set (hexahedra, prisms, pyramids, and tetrahedra) to general polyhedra (Median and Voronoi elements). In this talk I will present my procedure for automating the generation of large complex hybrid meshes. In addition I will present the solutions that I have incorporated into my mesh generator for partitioning meshes for parallel computer applications and time-dependent mesh generation by using AMR (adaptive mesh refinement) algorithms.