Lew Wolfgang wrote:
Hi Folks,
I've got, at this point, a rather ill-defined requirement that I thought I'd run by you. I thought about posting on the off-topic list, but this is a real world task that I hope SuSE is up to.
The problem takes a volume of water that can be represented as a three-axis array. The X and Y directions have a modulus of 500, the Z 20. We then need to access this volume by specifying any two X,Y,Z points to extract data that represents acoustic transmission loss between the specified points. The data returned would be a vector of sound amplitudes and time delays. An array of frequency vs transmission loss might also be required for each point.
Lew For an ill-defined requirement, an equally ill-defined guess at a solution. First, what information is held at each array address? My first thought was, "if nothing more than coordinates are held in the array, why store the information at all?" Sound loss through water seems like nothing more than a 3-dimensional space problem with decrease in signal amplitude resulting from propagation through a known medium being the answer. If that were the case, there would be no storage requirement at all. The response would be based on a pure computation of acoustic decay at or between points A and B with the source at point C. Second ill-defined guess would be, "is it really necessary to maintain a data array with that "fine-grained" a data set, or can we have less points within the array and then interpolate between the known points on a computational basis to provided the needed answers?" Perhaps cutting down by several orders of magnitude the size of the number behind the E. From a code stand point, if you do need an array that large, then you will need whatever you write it in to access some type of "directory structure" to access the data with little or no computational overhead. A pure transactional database approach seems computationally expensive for accessing data that isn't changing. Hopefully FORTRAN has improved many times over in its data interfacing and has something more to offer than "common-block" access that was always a hindrance. Both FORTRAN and C are computationally efficient with a number of good open source math libraries readily available. However, how you access that much data in an efficient manner seems like it would drive the choice of what you write it in. What are you doing anyway? Russian Submarine Tracking?? -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org