David C. Rankin wrote:
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.
Hi David, Thanks for the reply, sorry I'm late in reply to yours! I've been really busy these days. The data stored at each element describes the transmission loss between the two points. Sound propagation through a body of water is anything but uniform. Temperature differences give you density differences, also affected by salinity in ocean water, and you end up with a very complicated sound field. I'm fairly sure the data will be calculated in advance based on models.
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.
I think the researchers are already doing this, good observation!
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.
Agree on the database overhead. There are apparently HPC projects that specialize in this kind of problem. I think they come as libraries that would be called by FORTRAN code. The HDF5 project is an example of this kind of library, but I have zero experience with them.
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??
Har! I actually laughed out loud when I read this! Actually no, this has nothing to do with submarines. I'm not sure if the principal investigator wants me to tell more at this point, I'll ask. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org