Bernhard wrote: >You are right, since it is a commercial program, >i don´t publish exactly what i am doing, but i >hope the information i gave here is at least >more than nothing. Well, actually, what you've given doesn't do anything to describe the model which is the basis of your software. You've merely listed some mathematical devices used in generating equations and solving them. There seems to be some confusion here between model concepts (physical representation), their mathematical representation, solution methods, and software development, which are all different and can be described independently. A lot more of these details need to be revealed before a model can be considered a serious design tool, as opposed to something akin to a "sim-city" computer game. This is not say it is the latter, just that without the information we're in the dark. The onus is on the seller of a commercial design tool to convince the customer, and that cannot be done with smoke and mirrors. >The model is derived by higher order >differentials, solved with usual difference >schemes. All what is necessary to build such a >model can be found in Klaus Jürgen Bathe´s book >"Finite Element Methods". FEM is simply a generic technique for continuous systems. Giving that as the basis for a model is like saying you've used Newton's equations of motion to solve a dynamics problem, or Snell's Law to solve an optics problem. Not very informative. In order to communicate what's actually been done in the model you have to explain how these techniques have been used to represent the physics, what assumptions have been made, how the parameters have been derived, how the results are tested, and so on. Actually, how long does the model take to do one run? If FEM is used as the computational basis it must take quite a while to analyse even one scenario, unless the software model just picks from a library of results of a few days worth of pre-generated FEM simulations. FEM models run real slow if they are complex enough to be realistic. >Hysteresis is not a phenomene discovered by >Stulov, it is relatively common used in finite >element models. Of course hysteresis wasn't discovered by Stulov. It's a fundamental physical phenomenon. And it has nothing to do with FEM or any other modelling technique. Stulov was (one of) the first to include hysteresis in a hammer model. >But have you ever seen Yamaha open their black >boxes when using physical modeling in their >synthesizers or Bill Gates giving the source >code for his Windows Kernel? This analogy is not valid. The success of Yamaha's physical modelling can be determined by the end result. Does the customer like the synthesized tones? That's what they're buying. They could care less how those tones are generated in order to assess the value of the product. Ditto source code. Either software works properly and efficiently or it doesn't. Again the results can be used directly for assessment. In the case of an applied model that is supposed to predict the real behaviour of a physical system customer assessment must be based on a validation process for which transparency is essential. I'm not convinced that you've been through this lengthy process, or else you would not hestitate to reveal the results and use them in the advertising, even if you choose for whatever reason not to publish the model details themselves for critical scientific assessment by experts. Anything less than that and the model is essentially useless and its commercial distribution is simply a software marketing exercise. The $ value/worth of a predictive model is derived from confidence in the predictions and how they are derived. This can be explained without revealing source code or exact details of every equation. There is always room to conceal some of the critical information that's needed to reproduce a model, thereby protecting commercial interests. [This I know from long experience with commerical models.] As I said last time, if the model is really capable of accurate predictions of the factors claimed, then it is new and valuable. The details behind it would be interesting and should be published, along with the results of your testing. Stephen -- Dr Stephen Birkett, Associate Professor Department of Systems Design Engineering University of Waterloo, Waterloo ON Canada N2L 3G1 Director, Waterloo Piano Systems Group Associate Member, Piano Technician's Guild E3 Room 3158 tel: 519-888-4567 Ext. 3792 fax: 519-746-4791 PianoTech Lab Room E3-3160 Ext. 7115 mailto: sbirkett[at]real.uwaterloo.ca http://real.uwaterloo.ca/~sbirkett
This PTG archive page provided courtesy of Moy Piano Service, LLC